Scope - What This Guide Covers
This guide helps you build a cryptography asset inventory before quantum computers make your current encryption obsolete. You'll map cryptographic implementations across your infrastructure, identify which algorithms protect what data types, and establish ownership for quantum-safe migration planning. The focus is on pre-migration discovery, not post-quantum algorithm selection.
If you're looking for guidance on implementing specific post-quantum cryptographic standards, bookmark this for later and start a different project. You can't migrate what you haven't found.
Key Concepts and Definitions
Cryptographic asset: Any component that performs encryption, decryption, key generation, digital signing, or cryptographic hashing. This includes TLS certificates, database encryption modules, API authentication tokens, VPN configurations, and code-signing keys.
Data at rest vs. data in transit: Data at rest (stored files, databases, backups) faces different quantum risks than data in transit (network communications, API calls). An attacker who harvests encrypted traffic today can decrypt it later once quantum computers become capable, a threat model called "harvest now, decrypt later."
Cryptographic agility: Your ability to swap one algorithm for another without rewriting applications or reconfiguring systems. Most enterprises have low agility because cryptography was embedded years ago by vendors, not chosen deliberately by your security team.
Quantum-safe migration deadline: Global regulatory frameworks are converging on 2030 as the target date for completing transitions to post-quantum cryptographic standards. This is becoming a compliance requirement.
Requirements Breakdown
Discovery Phase Requirements
You need four inventories running in parallel:
Application-layer cryptography: Identify where your applications call cryptographic libraries. This includes authentication flows, session management, data serialization, and file encryption. Your developers often don't know which libraries they're using because frameworks abstract the details.
Infrastructure cryptography: Document TLS configurations on load balancers, VPN concentrators, storage array encryption, database transparent data encryption, and hardware security modules. Your infrastructure team knows these exist but probably hasn't documented algorithm versions.
Third-party and vendor cryptography: Include SaaS platforms, cloud provider encryption services, managed security tools, and embedded firmware in IoT devices. You don't control these implementations, but you're accountable for the risk.
Key management infrastructure: Track where keys are generated, stored, rotated, and destroyed. This includes certificate authorities, key management services, secrets management platforms, and that Excel file someone created in 2019.
Classification Requirements
For each cryptographic asset, document:
- Algorithm family: RSA, ECC, AES, SHA-family
- Key length: 2048-bit RSA vs. 4096-bit matters for quantum risk
- Data sensitivity: What classification level does this algorithm protect?
- Owner: Not "IT" -- a specific person who can authorize changes
- Dependencies: What breaks if you change this algorithm?
- Compliance scope: Does this encryption support SOC 2 controls, HIPAA Security Rule safeguards, or General Data Protection Regulation requirements?
Implementation Guidance
Start With High-Value Targets
Don't try to inventory everything at once. Begin with systems that handle your most sensitive data or face the strictest regulatory requirements. If you're in healthcare, start with systems processing protected health information. Financial services should prioritize systems supporting GLBA Safeguards Rule requirements.
Your first 20% of effort should cover 80% of your quantum risk.
Use Automated Discovery Tools
Manual documentation fails because cryptography changes faster than spreadsheets update. You need tools that continuously scan for:
- TLS certificate configurations and cipher suites
- Cryptographic API calls in application code
- Encryption settings in database configurations
- Key storage locations across cloud and on-premises environments
IBM Quantum Safe offers discovery capabilities, but don't wait for a perfect tool. Start with network scanning tools you already own and augment with code analysis.
Establish Ownership Boundaries
Cryptography often stays invisible because no one owns it. Application teams think infrastructure handles it. Infrastructure teams think developers choose it. Security teams discover it only during audits.
Create a RACI matrix that assigns:
- Responsible: Team that implements cryptographic changes
- Accountable: Executive who accepts the quantum risk
- Consulted: Security architecture, compliance, vendors
- Informed: Audit committee, regulators, customers
Document Migration Complexity
For each asset, rate migration difficulty on a three-point scale:
Low complexity: Configuration change only, no code modifications, vendor supports quantum-safe algorithms
Medium complexity: Requires application updates, testing in staging environment, coordinated deployment window
High complexity: Embedded in hardware, requires vendor roadmap commitment, may need system replacement
This complexity rating determines your migration timeline. High-complexity assets need to start planning now to meet 2030 deadlines.
Common Pitfalls
Assuming cloud providers handle everything: Your cloud provider encrypts data by default, but you're still responsible for key management and algorithm selection. Read your shared responsibility model carefully.
Ignoring legacy systems: That AS/400 running your core banking platform? It uses cryptography too, and it's probably the hardest system to migrate. Don't discover this in 2029.
Treating this as a one-time project: Cryptographic assets change every time you deploy new code, adopt a new SaaS platform, or refresh infrastructure. Your inventory needs continuous updates, not an annual refresh.
Forgetting about backups: Encrypted backups from 2024 will still need decryption in 2034. If you migrate to quantum-safe algorithms but your backup restoration process depends on deprecated keys, you've created a recovery gap.
Skipping the "why it's used" documentation: Knowing you have RSA-2048 in your payment gateway matters less than understanding whether it's there for PCI DSS compliance, vendor integration requirements, or a developer's default choice. The "why" determines your migration options.
Quick Reference Table
| Asset Category | Discovery Method | Typical Owner | Migration Complexity | Regulatory Driver |
|---|---|---|---|---|
| TLS certificates | Certificate transparency logs, network scanning | Infrastructure/NetOps | Low | General Data Protection Regulation, HIPAA Security Rule |
| Database encryption | Configuration audits, query analysis | Database administration | Medium | SOC 2, GLBA Safeguards Rule |
| Application crypto libraries | Static code analysis, dependency scanning | Development | Medium-High | Varies by application scope |
| API authentication | API gateway configs, token inspection | Application/Platform | Medium | SOC 2, NIST Cybersecurity Framework |
| VPN configurations | Device configs, connection logs | Network security | Low-Medium | NIST SP 800-53 |
| Code signing | Certificate inventories, build pipelines | DevOps/Release | Low | NIST SP 800-171 |
| HSM-stored keys | HSM audit logs, key ceremony records | Security operations | High | PCI DSS, FIPS 140-3 |
| IoT device firmware | Device inventories, vendor documentation | OT/IoT team | High | ANSI/ISA-62443 |
Next step: Schedule a 90-day sprint to inventory your top 10 most critical systems. You don't need perfect coverage to start planning. You need enough visibility to know where quantum risk concentrates and which migrations will take years, not months.
The 2030 deadline isn't moving. Your inventory timeline shouldn't either.
