Your cryptographic inventory is incomplete. You know it, your CISO knows it, and the regulatory deadlines approaching 2030 don't care.
The quantum computing threat isn't theoretical anymore. Quantum computers could break current cryptographic algorithms within the next decade, and your enterprise likely can't answer a basic question: where does cryptography actually live in your infrastructure? Not at the policy level. At the implementation level, inside applications, cloud platforms, network devices, and hardware security modules.
This decision tree helps you choose the right quantum-safe migration path based on your current cryptographic visibility, regulatory obligations, and operational constraints.
The Decision You're Facing
You need to transition to quantum-safe cryptographic standards, but you're choosing between three fundamentally different approaches:
Path A: Comprehensive cryptographic discovery followed by phased migration
Path B: Risk-based prioritization with partial visibility
Path C: Regulatory-minimum compliance targeting specific systems
The path you choose determines your timeline, resource allocation, and exposure window. Choose wrong, and you'll either waste budget mapping systems that don't matter or miss critical cryptographic implementations until an audit finds them.
Key Factors That Affect Your Choice
Cryptographic ownership structure: Does a single team own your cryptographic inventory, or is it distributed across application teams, infrastructure, and third-party platforms? If no one owns the complete picture, you're starting from zero visibility.
Data classification mix: What percentage of your cryptographic implementations protect data at rest versus data in transit? Data in transit (TLS sessions, API calls, payment authorization flows) faces different quantum risks than encrypted databases or archived transaction records.
Regulatory exposure: Are you subject to specific quantum-safe migration deadlines? Global regulatory frameworks are targeting 2030 for quantum-safe compliance. If you're in scope, your choice narrows.
Technical debt in legacy systems: How much of your cryptography lives in applications you can't easily modify? Mainframe payment processors, embedded hardware devices, and vendor-controlled platforms limit your migration options.
Path A: Full Discovery and Phased Migration
Choose this path if:
- You have regulatory obligations with hard quantum-safe deadlines
- Your organization processes high-value transactions where "harvest now, decrypt later" attacks pose material risk
- You can allocate dedicated resources to cryptographic inventory work over 12-18 months
- You need defensible documentation for examiners and auditors
How it works:
Start with automated discovery tools that scan network traffic, application binaries, and configuration files for cryptographic implementations. You're looking for algorithm identifiers (RSA key exchange, ECDSA signatures), key lengths, and the data those implementations protect.
Map every finding to a business process. Which cryptographic implementation protects cardholder data during authorization? Which one signs your ACH file transfers? Which one encrypts your customer database backups?
Prioritize migration based on data sensitivity and exposure duration. Encrypted data in transit matters less than encrypted archives you'll store for seven years. Quantum computers don't need to break today's TLS sessions, but they will eventually break the encryption protecting your long-term storage.
Migrate to NIST-standardized post-quantum algorithms for key exchange (ML-KEM) and digital signatures (ML-DSA, SLH-DSA). Test interoperability before you deploy. Your payment processors, core banking platform, and third-party APIs all need to support the same post-quantum standards, or you'll create integration failures.
The tradeoff: This path takes time and money. You'll find cryptographic implementations in places you didn't expect, inside container orchestration layers, buried in legacy code, hardcoded in vendor appliances. Budget for surprises.
Path B: Risk-Based Prioritization with Partial Visibility
Choose this path if:
- You don't face immediate regulatory deadlines but recognize the quantum threat
- You can identify your highest-risk cryptographic implementations without comprehensive discovery
- You need to show progress while building a business case for full migration
- Your organization has limited security engineering capacity
How it works:
Identify the cryptographic implementations you already know about, your HSMs, your TLS termination points, your database encryption layers, your code-signing infrastructure. Focus on systems that protect regulated data or support critical payment flows.
Assess quantum risk by asking: how long does this data need protection? Payment Cardholder Data stored for PCI DSS compliance requirements faces a different risk profile than session tokens that expire in minutes.
Migrate high-risk systems first. Your cardholder data environment, your key management infrastructure, your long-term transaction archives, these systems justify immediate quantum-safe upgrades even without complete visibility.
Document what you haven't mapped yet. When you eventually face regulatory requirements or audit questions, you need a defensible explanation for why certain systems weren't prioritized.
The tradeoff: You'll miss things. Cryptographic implementations you don't know about won't get migrated. If an examiner or incident response team discovers unmapped cryptography later, you're explaining why your risk assessment failed.
Path C: Regulatory-Minimum Compliance
Choose this path if:
- You face specific regulatory requirements that define quantum-safe scope narrowly
- Your organization treats security as a compliance function, not a risk management function
- You have budget constraints that prevent broader migration
- You're willing to accept residual quantum risk outside regulatory scope
How it works:
Wait for regulatory guidance that specifies which systems require quantum-safe cryptography. When those requirements arrive, migrate only the systems explicitly in scope.
Focus on attestation and documentation. Regulators will want evidence that in-scope systems use approved post-quantum algorithms. Build your compliance artifacts first, policies, procedures, testing records.
Plan for scope expansion. Initial regulatory requirements will likely focus on the most critical systems (payment processing, customer data protection), but expect broader requirements over time.
The tradeoff: You're betting that quantum computing advances slowly enough that regulatory timelines give you adequate warning. If quantum capabilities arrive faster than expected, or if threat actors begin "harvest now, decrypt later" attacks before regulations expand, you're exposed.
Summary Matrix
| Factor | Path A (Full Discovery) | Path B (Risk-Based) | Path C (Regulatory-Minimum) |
|---|---|---|---|
| Timeline to start | 2-3 months (discovery phase) | Immediate (known systems) | Wait for regulatory guidance |
| Resource requirement | High (dedicated team) | Moderate (existing security team) | Low (compliance-driven) |
| Regulatory defensibility | Strong (complete documentation) | Moderate (risk assessment) | Minimum (in-scope only) |
| Residual quantum risk | Lowest | Moderate | Highest |
| Budget justification | Requires executive buy-in | Can start with existing budget | Minimal until required |
The practical reality: Most banks will end up combining paths. You'll start with Path B, migrating the systems you know matter, while building the business case for Path A's comprehensive approach. Path C isn't really a choice; it's what happens when you run out of time.
The question isn't whether you'll migrate to quantum-safe cryptography. The question is whether you'll do it on your timeline or the regulator's.
