The question organizations were asking about quantum computing three years ago “when will this actually matter?” has been answered. In August 2024, NIST published its first finalized Post-Quantum Cryptography (PQC) standards: FIPS 203, FIPS 204, and FIPS 205. OMB Memorandum M-23-02 directed US federal agencies to begin migration inventories. The EU’s Cyber Resilience Act and NIS2 Directive are incorporating quantum-readiness expectations. The transition from when to how is underway.
The challenge is not philosophical but both architectural and operational: most enterprise environments have cryptographic dependencies embedded across thousands of systems, third-party integrations, and long-running data storage operations. There is no single-click upgrade path from classical to quantum-resistant cryptography.
This guide provides a structured, six-phase readiness roadmap that enterprise security leaders can use to design, prioritize, and execute a PQC migration program, at a pace that matches their risk exposure, regulatory obligations, and operational capacity.
Why is the clock already running? State-sponsored adversaries are actively collecting encrypted data today with the intention of decrypting it once quantum computers reach cryptographic relevance. This “harvest now, decrypt later” (HNDL) strategy means that data encrypted right now with RSA, ECC, or Diffie-Hellman key exchange may be decryptable within 5–15 years. For any organization holding data with long-term confidentiality requirements, health records, financial data, government communications, intellectual property, the migration window is open now.
What Is Post-Quantum Cryptography and Why Does Your Enterprise Need a Roadmap?
Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical and quantum computers. Unlike Quantum Key Distribution (QKD), which uses quantum physics to secure key exchange, PQC runs on existing classical infrastructure and requires no specialized hardware. It replaces vulnerable mathematical foundations (integer factorization in RSA, discrete logarithm in ECC and DH) with problems believed to be hard for quantum computers: lattice problems, hash-based constructions, and code-based mathematics.
The reason a roadmap matters, rather than a point migration, is that cryptographic dependencies in large enterprises are not centralized. They are distributed across:
- TLS/SSL certificates in every externally and internally facing service.
- VPN and remote access infrastructure using DH and ECDH key exchange.
- Code signing certificates validating software integrity across the supply chain.
- Hardware security modules (HSMs) with firmware-level algorithm constraints.
- Long-lived encrypted data archives with sensitivity windows extending decades.
- Third-party and vendor integrations with their own cryptographic dependencies.
- PKI hierarchies including root CAs, intermediate CAs, and issued certificates.
A roadmap coordinates discovery, prioritization, architecture redesign, piloting, and migration across these surfaces, without disrupting operations or creating security gaps during the transition period.
Understanding the NIST PQC Standards Your Roadmap Must Align To
The first step in any enterprise PQC roadmap is understanding what you are migrating to. NIST’s finalized standards provide the authoritative algorithm baseline:
| Standard | Algorithm | Type | Primary Use Case |
| FIPS 203 | CRYSTALS-Kyber | Key Encapsulation Mechanism (KEM) | Key establishment, TLS handshake replacement, session key exchange |
| FIPS 204 | CRYSTALS-Dilithium | Digital signature algorithm | Code signing, certificate authorities, document authentication |
| FIPS 205 | SPHINCS+ | Hash-based signature scheme | Long-term signatures, high-assurance signing where statelessness is required |
| FIPS 206 | FALCON | Lattice-based digital signature | High-performance signature use cases; smaller signature size than Dilithium |
NIST also maintains a second category of algorithms under evaluation, including BIKE and HQC (code-based KEMs), intended to provide algorithm diversity. Organizations should design their roadmaps to support algorithm agility, the ability to swap cryptographic algorithms without redesigning dependent systems, rather than hard coding a single PQC algorithm into every implementation.
For organizations in US federal supply chains, OMB M-23-02 mandates a cryptographic inventory by September 2023 (already past) and establishes migration timelines. UK NCSC, ENISA, and BSI Germany have issued parallel guidance. Regulatory pressure will increase, not decrease, over the next 24 months.
The 6-Phase PQC Readiness Roadmap for Enterprise
The following framework maps the full scope of a structured enterprise PQC migration program. Phases are sequential but can be executed in parallel for independent system domains. Phases 1 and 2 should begin immediately regardless of where other phases fall in the planning timeline.
Phase 1: How Do You Build a Cryptographic Inventory?
The cryptographic inventory is the foundation the entire roadmap rests on. Without knowing what cryptographic assets exist and where they operate, it is impossible to prioritize migration, assess risk, or demonstrate regulatory compliance.
A complete cryptographic inventory maps:
- Algorithm types in use: RSA, ECDSA, ECDH, AES, SHA-2, DH, identifying which are quantum-vulnerable (asymmetric key exchange and digital signatures) versus quantum-resistant (AES-256, SHA-384 are considered quantum-adequate).
- Key sizes and certificate lifetimes: Short-lived TLS certificates can be rotated quickly; long-lived code signing or CA certificates require longer lead times.
- Cryptographic library versions: OpenSSL, BoringSSL, NSS, Windows CNG, Java JCE, each has different PQC support timelines and migration paths.
- Third-party and vendor cryptographic surfaces: APIs, SaaS integrations, cloud services, and hardware vendors each have their own migration schedules that your roadmap must account for.
- Data-at-rest encryption: Identify long-lived encrypted stores where HNDL exposure is highest, especially healthcare records, financial data, IP, and government data.
Most organizations lack a centralized cryptographic inventory because cryptography was implemented ad hoc across system development lifecycles. Automated discovery tools, including SBOM-aware scanning, TLS inspection, and PKI auditing tools, are necessary to achieve coverage at enterprise scale. This is a core output of a security architecture review process with a quantum focus.
Phase 2: How Should You Prioritize Your PQC Migration?
Not everything migrates at the same time. Risk-based prioritization determines sequencing. Apply a three-dimension scoring model to each cryptographic asset identified in Phase 1:
Dimension 1: Quantum vulnerability
Assets using RSA, ECDSA, ECDH, or DH for key exchange or digital signatures are quantum vulnerable. AES-256 and SHA-384/512 are considered quantum-adequate at their current key sizes (AES-128 has effectively reduced security against Grover’s algorithm). Score vulnerability based on algorithm type and key size.
Dimension 2: Data sensitivity and longevity
A TLS session established today and discarded in 24 hours carries minimal HNDL risk. A healthcare record encrypted today and required to remain confidential for 25 years carries maximum HNDL risk. HIPAA-covered data, PCI DSS-scoped cardholder records, government classified data, and proprietary intellectual property all fall in the highest HNDL risk category.
Dimension 3: Migration complexity
A web application server’s TLS certificate can be rotated in hours. A hardware security module with firmware-level algorithm constraints may require vendor coordination over 12 months. Scoring migration complexity in parallel with risk ensures that high-complexity, high-risk assets receive early resource allocation rather than being deferred until other migrations are complete.
The output is a risk-weighted migration sequence: high-risk / low-complexity assets migrate first; high-risk / high-complexity assets begin planning and vendor coordination first even if implementation follows later.
What Is Crypto-Agility and Why Is It Central to Your PQC Roadmap?
Crypto-agility is the architectural property that allows an organization to change cryptographic algorithms, key sizes, and protocols without requiring application redesign. It is the difference between a migration that costs months and one that costs weeks.
Crypto-agility is achieved by:
- Decoupling algorithm selection from application logic: Configuration-driven algorithm selection rather than hard-coded algorithm references in application code
- Implementing negotiation layers: TLS 1.3 with hybrid PQC extensions (e.g., X25519Kyber768) allows simultaneous classical and post-quantum key exchange during transition
- Designing for hybrid operation: Running classical and PQC algorithms in parallel (“hybrid mode”) provides protection against both classical and quantum attacks during migration, and guards against the possibility that a newly deployed PQC algorithm has undiscovered weaknesses
- Centralizing PKI management: A well-governed PKI with clear certificate lifecycle policies is dramatically easier to migrate than a fragmented, distributed certificate estate
Organizations that treated past cryptographic implementations as permanent infrastructure, rather than configurable controls, will bear the highest migration costs. Crypto-agility must become a design standard for all future cryptographic implementations, regardless of where the PQC migration currently sits in the roadmap.
How Does PQC Readiness Align with Regulatory and Compliance Requirements?
PQC readiness is not only a security strategy. It is an emerging regulatory compliance requirement:
- OMB M-23-02 (US Federal): Requires federal agencies and contractors to inventory cryptographic systems and begin migration planning. Sets expectations for compliance timelines that flow downstream to vendors and supply chain partners
- NIST IR 8547: Transition guidance for federal agencies, providing specific deprecation timelines for quantum-vulnerable algorithms through 2030 and full deprecation by 2035
- EU Cyber Resilience Act and NIS2 Directive: Incorporate security-by-design requirements that regulators are interpreting to include quantum-readiness for critical infrastructure and essential service operators
- DORA (EU financial services): Operational resilience requirements increasingly interpreted to require cryptographic risk assessment as a component of ICT risk management
- India’s DPDPA: with full enforcement tracking toward 2027 following the DPDP Rules notification, requires encryption as a security safeguard for personal data. As quantum threats mature, encryption adequacy will include algorithm strength, creating an indirect PQC obligation for Data Fiduciaries. See DPDPA compliance guidance
- Cyber insurance: Underwriters are beginning to ask about PQC readiness in renewal questionnaires. Organizations that cannot demonstrate a cryptographic inventory and migration plan may face policy exclusions or premium increases within 2–3 years
Managing Third-Party and Supply Chain PQC Exposure
Your PQC migration does not end at your own infrastructure boundary. Every vendor, cloud provider, SaaS platform, and API integration that handles cryptographic operations represents an extension of your quantum exposure.
Third-party PQC risk management requires:
- Vendor PQC roadmap questionnaires: Assess your critical vendors’ PQC migration timelines, NIST alignment, and crypto-agility capabilities during contract renewal
- Cloud service provider alignment: AWS, Azure, and Google Cloud have all announced or begun deploying hybrid PQC in their TLS and KMS services. Verify which services have migrated and which remain on classical algorithms
- Certificate authority migration: Root CAs and intermediate CAs are beginning to issue post-quantum certificates. Verify your CA’s migration timeline and update your trust stores accordingly
- HSM vendor roadmaps: Hardware Security Modules require firmware updates or hardware replacement to support PQC. Engage HSM vendors early lead times for hardware replacement can be 12–18 months
This is fundamentally a third-party risk management exercise at the cryptographic layer. Organizations with mature TPRM programs and continuous vendor monitoring, through platforms such as Wizard, can track vendor PQC posture changes alongside broader security posture indicators.
The Executive Summary: What CISOs and CROs Need to Know
The quantum threat is not imminent. The migration is.
Cryptographically relevant quantum computers capable of breaking RSA-2048 or ECC-256 are projected to be 5–15 years away, depending on investment trajectories and engineering progress. That timeline sounds comfortable. It is not, for three reasons:
- Enterprise cryptographic migrations at scale take 3–7 years to complete, beginning now creates sufficient runway; beginning in 2028 does not
- HNDL attacks against long-lived data are happening right now, with no waiting for quantum computers to mature
- Regulatory compliance timelines, particularly for federal contractors and EU financial institutions, are not aligned to when quantum computers are ready; they are aligned to when migration inventories and plans are documented
The board conversation should be framed around three questions: Do we know what cryptographic assets we have? Which of them protect data with a sensitivity window beyond 5 years? Do we have a documented migration plan?
Organizations that can answer yes to all three are ahead of the curve. Those that cannot should treat Phase 1, the cryptographic inventory, as an immediate security architecture priority, not a multi-year planning exercise.
| Start Your Post-Quantum Cryptography Readiness Assessment today! Book a PQC Readiness Consultation! |
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
