Your encryption is already obsolete, you just don't know which systems are vulnerable yet.
Quantum computing isn't a distant problem. Adversaries are harvesting encrypted data today, storing it, and waiting for quantum systems capable of breaking current encryption standards. If your organization holds data with confidentiality requirements extending beyond 2030, you're already exposed to this "harvest-now-decrypt-later" threat.
The solution isn't just quantum-resistant algorithms. It's crypto agility, the ability to identify, update, and replace cryptographic implementations across your entire infrastructure when standards change. And that starts with knowing what you have.
What You Need Before Starting
Before you inventory a single certificate or key, establish these prerequisites:
Scope definition. Document which systems process, store, or transmit regulated data. For banks, this includes your Cardholder Data Environment (CDE), systems handling wire transfer authentication, and any platform storing customer PII beyond transactional retention periods. Your quantum exposure correlates directly with data sensitivity and retention requirements.
Stakeholder access. You'll need read access to certificate stores, HSM configurations, application codebases, and infrastructure-as-code repositories. Secure sign-off from application owners, infrastructure teams, and compliance before you start scanning production systems.
Tooling budget. Plan for certificate discovery tools (open-source options like SSLyze or commercial platforms), network scanning capabilities, and static code analysis tools that can identify cryptographic library usage. You don't need a comprehensive TLS inspection platform on day one, but you do need visibility into what's listening on your network.
Baseline documentation. Pull your current key management policy, certificate lifecycle procedures, and any existing cryptographic standards. You're about to find gaps between policy and reality, document the starting point.
Step-by-Step Implementation
Week 1: Network-Level Discovery
Start with what's externally visible and work inward.
Run certificate enumeration against all internet-facing endpoints. Use nmap with SSL scripts or a dedicated TLS scanner:
nmap --script ssl-cert,ssl-enum-ciphers -p 443,8443 [target-range]
Document every certificate: issuing CA, expiration date, key algorithm, key length, and cipher suites supported. Flag anything using RSA-1024, SHA-1, or deprecated TLS versions (1.0, 1.1).
Scan internal network segments next. Your payment switches, core banking systems, and HSM management interfaces aren't internet-facing, but they're cryptographically critical. Many banks discover that internal PKI hierarchies haven't been rotated in a decade.
Week 2: Application-Level Inventory
Cryptographic dependencies hide in application code, not just infrastructure.
Run Software Composition Analysis (SCA) against application repositories. You're looking for:
- OpenSSL, BoringSSL, or other TLS libraries (note versions)
- Java KeyStore and TrustStore references
- Cryptographic provider configurations (JCE, .NET Crypto, Python cryptography)
- Hardcoded cipher suite selections
Interview application teams about custom cryptographic implementations. Payment processing systems often include proprietary PIN block encryption, MAC generation for ISO 8583 messages, or custom key derivation functions. These won't show up in automated scans.
Document every instance where your code explicitly calls cryptographic functions. You need this granularity because quantum-resistant algorithm migration will require code changes, not just certificate replacement.
Week 3: Key Management Infrastructure
Map your key hierarchy from root to leaf.
For each HSM, document:
- Key Encryption Keys (KEKs) protecting stored keys
- Data Encryption Keys (DEKs) used for actual encryption operations
- Key generation algorithms and parameters
- Key rotation schedules (actual, not policy)
- Split Knowledge procedures for sensitive key access
Audit certificate authority infrastructure. If you operate internal CAs, document the root and intermediate certificate validity periods, key algorithms, and issuance policies. Your quantum migration will require new CA hierarchies, you need to know what you're replacing.
Identify key escrow and backup procedures. Quantum-resistant algorithms will require larger key sizes and different backup strategies. If your current backup process assumes 2048-bit RSA keys fit on specific HSM backup tokens, that assumption breaks with post-quantum cryptography.
Week 4: Dependency and Risk Mapping
Connect cryptographic assets to business functions.
Build a matrix: cryptographic component → dependent systems → data classification → regulatory requirement. This tells you which cryptographic changes will trigger PCI DSS revalidation, which will require customer notification under breach disclosure laws, and which create operational risk during migration windows.
Prioritize based on three factors:
- Data sensitivity and retention. Systems protecting data with 10+ year retention requirements face the highest quantum risk.
- Change difficulty. Embedded systems, legacy mainframes, and vendor-managed platforms take longest to update.
- Regulatory exposure. Components in scope for PCI DSS, SOC 2, or FedRAMP audits require documented migration plans.
Flag any system where you don't control the cryptographic implementation. Third-party payment processors, cloud HSM services, and SaaS platforms will migrate on their own timelines, you need contingency plans.
Validation: How to Verify It Works
Your inventory is complete when you can answer these questions in under five minutes:
- Which systems will fail if you distrust a specific certificate authority tomorrow?
- How many applications use TLS 1.2 with RSA key exchange (versus ECDHE)?
- What's the oldest certificate expiration date in your infrastructure?
- Which HSMs support algorithm agility (can load new cryptographic modules)?
Test your documentation by running a tabletop exercise: "We need to rotate all RSA-2048 keys to RSA-4096 within 90 days." Can you identify every affected system, estimate downtime, and sequence the changes to avoid breaking dependencies?
If you can't, your inventory isn't detailed enough.
Maintenance and Ongoing Tasks
Crypto agility requires continuous inventory management, not annual audits.
Automated discovery. Schedule weekly certificate scans and monthly code repository analysis. New services deploy constantly, your inventory decays the moment you finish building it.
Change integration. Require cryptographic component documentation in deployment pipelines. Every new service should register its certificates, key usage, and algorithm dependencies before reaching production.
Compliance synchronization. When certificate validity periods drop (currently trending toward 90 days), your inventory becomes your migration project plan. Shorter certificate lifespans mean more frequent rotations, you need automated tracking.
Vendor monitoring. Track cryptographic roadmaps for every third-party platform you depend on. When NIST finalizes post-quantum algorithm standards, you need to know which vendors will support them and on what timeline.
The Cryptographic Reset isn't a single event, it's a permanent state. Organizations that build crypto agility now will handle quantum migration as a scheduled maintenance window. Those that don't will face an emergency cryptographic retrofit under regulatory deadline pressure.
Start your inventory today. You can't replace what you can't see.
