15 minute read

Post Quantum Cryptography Logo

Post Quantum Cryptography

Introduction

The arrival of cryptographically relevant quantum computers (CRQCs) is no longer a question of if but when. When that threshold is crossed, RSA, ECC, Diffie-Hellman, and every protocol that depends on them — TLS, SSH, IPsec, S/MIME, code signing — will be broken in polynomial time by Shor’s algorithm.

Migration to post-quantum cryptography (PQC) is the most consequential infrastructure transition since the move from DES to AES, but orders of magnitude broader in scope. Unlike a cipher swap, PQC migration touches every layer of the stack: certificates, key management, firmware, hardware accelerators, compliance regimes, and supply-chain contracts.

This post provides a structured, actionable guide for planning and executing that migration.

1. Why Migrate Now?

1.1 The Quantum Timeline Is Irrelevant — The Data Timeline Is Not

The critical insight is that an adversary does not need a quantum computer today to exploit quantum-vulnerable cryptography today. The Harvest Now, Decrypt Later (HNDL) attack model makes the threat immediate.

TIME TODAY CRQC ARRIVES Adversary harvests encrypted traffic Bulk decryption Data sensitivity window (e.g. 10–30 years) ⚠ If sensitivity window > time to CRQC → data is already at risk HARVEST NOW, DECRYPT LATER (HNDL) THREAT MODEL
Fig 1. The HNDL attack model. An adversary captures encrypted data today and stores it until a CRQC becomes available. If the data's sensitivity window exceeds the time until CRQC availability, the data is effectively compromised now.

Any data with a confidentiality requirement exceeding 10 years — health records, state secrets, financial contracts, intellectual property — is already at risk if it traverses a quantum-vulnerable channel today.

1.2 Migration Lead Times

Cryptographic migration is not instantaneous. Historical precedents reveal sobering timelines:

Transition Announced Broadly Deployed Lead Time
DES → AES 1997 ~2005 ~8 years
SHA-1 → SHA-2 2005 ~2017 ~12 years
MD5 removal 2004 ~2015 ~11 years
RSA-1024 → RSA-2048 2010 ~2018 ~8 years

PQC migration is more complex than any of these: it involves new key sizes, different performance tradeoffs, protocol changes, and hardware updates. A realistic enterprise migration will take 5–10 years.

MOSCA'S THEOREM — MIGRATION URGENCY X = Data sensitivity lifetime (years remaining) Y = Migration duration (years to fully transition) Z = Time until CRQC available (years) Migration is urgent when: X + Y > Z Even with optimistic CRQC estimates (15–20 years), organizations with X ≥ 10 and Y ≥ 5 already satisfy X + Y > Z. Migration planning should begin immediately.
Fig 2. Mosca's theorem formalizes the urgency calculation. When the sum of data sensitivity lifetime and migration duration exceeds the time until CRQCs appear, migration should already be underway.

1.3 Regulatory and Compliance Pressure

The regulatory landscape is accelerating:

  • NSA CNSA 2.0 (2022): Mandates PQC adoption for National Security Systems by 2035
  • White House NSM-10 (2022): Directs federal agencies to inventory quantum-vulnerable cryptography
  • NIST SP 800-227 (2025): Initial Public Draft — Recommendations for Transition to Post-Quantum Cryptography Migration
  • CISA/NSA Quantum-Readiness (2023): Joint advisory to critical infrastructure operators
  • EU Recommendation (2024): European Commission recommendation on PQC migration roadmaps
  • DORA / NIS2: Financial and critical infrastructure regulations increasingly referencing cryptographic agility

Organizations that delay migration face compounding risk: technical debt, compliance gaps, and exposure to HNDL attacks.

2. Threat Model and Risk Analysis

2.1 What Breaks

Shor’s algorithm provides exponential speedups against the mathematical problems underlying classical public-key cryptography. Grover’s algorithm weakens symmetric ciphers, but only quadratically — manageable by doubling key lengths.

QUANTUM IMPACT ON CRYPTOGRAPHIC PRIMITIVES ALGORITHM PURPOSE QUANTUM ATTACK POST-QUANTUM STATUS RSA Key exchange, signatures Shor's — polynomial ⛔ BROKEN ECDSA / ECDH Signatures, key agreement Shor's — polynomial ⛔ BROKEN Diffie-Hellman Key agreement Shor's — polynomial ⛔ BROKEN DSA Signatures Shor's — polynomial ⛔ BROKEN AES-128 Symmetric encryption Grover's — √ speedup ⚠ WEAKENED (use 256) SHA-256 Hashing Grover's — √ speedup ✅ SAFE (≥ 128-bit PQ) AES-256 Symmetric encryption Grover's — √ speedup ✅ SAFE (128-bit PQ)
Fig 3. Quantum impact assessment by primitive. All public-key schemes based on integer factorization or discrete logarithms are completely broken by Shor's algorithm. Symmetric and hash primitives require key-length adjustments only.

2.2 Attack Surface Mapping

The threat extends far beyond TLS. Every protocol and artifact using public-key cryptography is vulnerable:

QUANTUM-VULNERABLE ATTACK SURFACE SHOR'S ALGORITHM Factor / DLOG in poly time NETWORK PROTOCOLS TLS 1.2/1.3 handshake SSH key exchange IPsec IKEv2 IDENTITY & PKI X.509 certificates CA hierarchies OCSP / CRL signatures SOFTWARE SUPPLY CHAIN Code signing Package verification Firmware updates DATA PROTECTION S/MIME, PGP email Encrypted backups Document signatures FINANCIAL SYSTEMS EMV / card authentication HSM key hierarchies IoT & EMBEDDED Device attestation Secure boot chains
Fig 4. The quantum-vulnerable attack surface spans every domain that relies on public-key cryptography — from network handshakes to PKI hierarchies, code signing, financial systems, and IoT device attestation.

2.3 Risk Categories

A structured risk taxonomy helps prioritize migration efforts:

Risk Category Description Priority
HNDL exposure Data with long confidentiality requirements already transiting quantum-vulnerable channels CRITICAL — migrate key exchange first
Authentication bypass Future CRQC can forge signatures, impersonate servers/CAs HIGH — migrate signatures with protocol upgrades
Supply chain compromise Code signing forgery enables malware injection HIGH — dual-sign during transition
Certificate hierarchy collapse Root CA key compromise invalidates all issued certificates HIGH — prepare PQ CA infrastructure
Regulatory non-compliance Failure to meet PQC mandates (CNSA 2.0, NSM-10, DORA) MEDIUM — track requirements, begin planning
Performance degradation PQC algorithms have larger keys and signatures MEDIUM — benchmark and optimize

3. The NIST Perspective

3.1 Standardized Algorithms

NIST finalized three post-quantum standards in August 2024 (FIPS 203, 204, 205) after an 8-year evaluation process:

NIST POST-QUANTUM STANDARDS (2024) FIPS 203 ML-KEM (formerly CRYSTALS-Kyber) Key Encapsulation Lattice-based (Module-LWE) PK: 800–1568 B CT: 768–1568 B ✓ Primary KEM standard ✓ Fast encaps/decaps ✓ Compact keys FIPS 204 ML-DSA (formerly CRYSTALS-Dilithium) Digital Signatures Lattice-based (Module-LWE) PK: 1312–2592 B Sig: 2420–4627 B ✓ Primary signature std ✓ Fast verify ✓ Deterministic signing FIPS 205 SLH-DSA (formerly SPHINCS+) Digital Signatures Hash-based (stateless) PK: 32–64 B Sig: 7856–49856 B ✓ Conservative security ✓ Minimal assumptions ✓ Hash-only security
Fig 5. The three NIST post-quantum standards: ML-KEM for key establishment, ML-DSA as the primary digital signature algorithm, and SLH-DSA as a conservative hash-based signature alternative.

3.2 NIST Transition Guidance (SP 800-227)

In November 2025, NIST released the Initial Public Draft of SP 800-227 — Recommendations for Transition to Post-Quantum Cryptography Migration. The key recommendations include:

  1. Deprecation timeline: RSA and ECDSA to be disallowed for new applications from 2030; fully deprecated by 2035
  2. Hybrid approaches: Endorsed during transition — combining classical and PQ algorithms provides defense-in-depth
  3. Cryptographic agility: Systems must be designed to swap algorithms without architectural changes
  4. Inventory first: Organizations must catalog all cryptographic dependencies before migration
  5. Prioritize key exchange: HNDL threat makes key encapsulation the highest-priority migration target

3.3 CNSA 2.0 Timeline

The NSA’s Commercial National Security Algorithm Suite 2.0 sets concrete deadlines for National Security Systems:

CNSA 2.0 ADOPTION TIMELINE 2025 Begin adopting ML-KEM for key establishment 2027 Prefer ML-KEM-768+ Begin ML-DSA for software/firmware sig 2030 Disallow RSA/ECDSA for new applications PQ-only for key estab. 2033 PQ signatures required for all new systems 2035 Classical crypto fully deprecated
Fig 6. CNSA 2.0 timeline. Key establishment migration begins immediately; signature migration follows. All classical public-key cryptography is deprecated by 2035.

4. Existing Migration Frameworks

Several authoritative frameworks provide structured guidance for PQC migration. While each has a different focus and audience, they converge on common principles: inventory, prioritize, test, deploy in phases.

4.1 Framework Comparison

PQC MIGRATION FRAMEWORKS — COMPARATIVE OVERVIEW NIST SP 800-227 (2025) U.S. Federal / Industry-wide • Algorithm deprecation timelines • Hybrid mode recommendations • Cryptographic agility requirements • Inventory-first methodology • Risk-based prioritization NSA/CISA Quantum Readiness (2023) Critical Infrastructure / DoD • Quantum-vulnerable crypto inventory • Supply chain vendor engagement • Testing and validation guidance • Incident preparedness planning • CNSA 2.0 compliance roadmap ETSI TR 103 619 (2024) European Telecom / Enterprise • Migration decision framework • Hybrid key exchange profiles • Protocol-specific guidance (TLS, IKE) • Performance impact analysis • Composite certificate strategies IETF PQ Standards Track (ongoing) Internet Protocol Standards • RFC 9180 HPKE PQ extensions • TLS 1.3 PQ key agreement drafts • X.509 composite signatures • DNSSEC PQ considerations • SSH PQ key exchange (RFC 9592)
Fig 7. Comparison of major PQC migration frameworks. Each addresses a different scope but shares common principles: inventory, prioritize, hybrid transition, and validation.

4.2 Common Principles Across Frameworks

Despite different audiences, all frameworks converge on five pillars:

  1. Discovery — Inventory all cryptographic assets, dependencies, and data flows
  2. Assessment — Classify assets by quantum vulnerability and data sensitivity
  3. Planning — Develop a phased migration roadmap with clear milestones
  4. Execution — Deploy PQ algorithms, starting with hybrid modes
  5. Validation — Continuous testing, monitoring, and compliance verification

5. Migration Strategy

5.1 Phased Migration Architecture

Migration should proceed in distinct, verifiable phases. Attempting a “big bang” cutover is unrealistic and dangerous — the transition must be gradual, hybrid-first, and backward-compatible at each step.

PHASED PQC MIGRATION STRATEGY PHASE 0 DISCOVERY & INVENTORY • Map all cryptographic assets (algorithms, key lengths, protocols, libraries) • Classify data by sensitivity lifetime • Identify HNDL-exposed channels • Assess vendor PQ readiness PHASE 1 HYBRID KEY EXCHANGE • Deploy ML-KEM + ECDH hybrid in TLS 1.3 and SSH • Immediate HNDL protection • No authentication change needed yet • Backward-compatible with classical peers PHASE 2 HYBRID SIGNATURES & PKI • Issue dual certificates (classical + PQ) • Deploy ML-DSA or SLH-DSA for code signing • Upgrade CA infrastructure • Dual-sign firmware and software updates PHASE 3 PQ-PRIMARY OPERATIONS • PQ algorithms become default; classical as fallback • Full PQ certificate chains in production • HSM firmware updated to PQ • Performance baselines established PHASE 4 CLASSICAL DEPRECATION Remove classical algorithms entirely • PQ-only operation
Fig 8. The five-phase migration model. Each phase is designed to be independently verifiable and backward-compatible with the previous state, enabling rollback if issues arise.

5.2 Hybrid Cryptography: The Transition Bridge

Hybrid cryptography combines a classical and a post-quantum algorithm so that security is maintained even if one proves vulnerable. This is the consensus approach for safe transition.

HYBRID KEY EXCHANGE — TLS 1.3 CLIENT SERVER ClientHello: key_share = ECDH-P256 share ‖ ML-KEM-768 encaps key ServerHello: key_share = ECDH-P256 share ‖ ML-KEM-768 ciphertext SHARED SECRET DERIVATION SS = KDF( ECDH_shared ‖ ML-KEM_shared ) Security holds if EITHER ECDH or ML-KEM remains unbroken
Fig 9. Hybrid key exchange in TLS 1.3. The client and server each contribute both an ECDH and an ML-KEM key share. The session key is derived by combining both shared secrets, ensuring security even if one primitive is broken.

Why hybrid?

  • Defense in depth: If a flaw is discovered in a PQ algorithm (as happened with SIKE in 2022), the classical algorithm still provides security
  • Compliance continuity: Many regulations still require FIPS-validated classical algorithms
  • Incremental deployment: Systems can be upgraded component by component
  • Performance tuning: Allows measuring PQ overhead in production before committing fully

5.3 Migration Priority Matrix

Not all systems should be migrated at the same pace. Priority depends on data sensitivity, HNDL exposure, and system replaceability:

MIGRATION PRIORITY MATRIX DATA SENSITIVITY / HNDL RISK → MIGRATION COMPLEXITY → P1 — IMMEDIATE • TLS key exchange (web, API) • VPN / IPsec tunnels • Email encryption (S/MIME) • Secret key distribution High sensitivity + low complexity → Hybrid KEM deployment P2 — PLANNED • PKI / CA hierarchies • HSM key management • Secure boot / firmware signing • Long-lived document signatures High sensitivity + high complexity → Dual-cert / hybrid signature rollout P3 — STANDARD • Internal API authentication • Database connection encryption • Session tokens (short-lived) Lower sensitivity + low complexity → Migrate with platform upgrades P4 — MONITORED • IoT device attestation • Legacy embedded systems • Third-party SaaS integrations Lower sensitivity + high complexity → Vendor-driven, long-term planning
Fig 10. Migration priority matrix. Systems are classified by data sensitivity (HNDL exposure) and migration complexity. P1 systems — key exchange with long-lived data — should begin hybrid migration immediately.

5.4 Cryptographic Inventory: The Foundation

No migration can succeed without a comprehensive Cryptographic Bill of Materials (CBOM). This inventory must capture:

Category What to Catalog Example
Algorithms Every cipher suite, key type, hash function RSA-2048, ECDSA-P256, AES-256-GCM
Protocols Protocol versions and negotiated parameters TLS 1.3, SSH-2, IKEv2, S/MIME
Libraries Cryptographic library name, version, FIPS status OpenSSL 3.2, BoringSSL, Bouncy Castle
Hardware HSMs, TPMs, smart cards, crypto accelerators Thales Luna 7, YubiKey 5, Intel QAT
Certificates All certificates, issuers, validity, key type Let’s Encrypt, internal CA, code signing
Key material Key sizes, rotation schedules, storage locations AWS KMS, Azure Key Vault, on-prem HSM
Data flows Where encrypted data transits and rests API gateways, backup archives, replicas

5.5 Cryptographic Agility

The single most important architectural principle for PQC migration is cryptographic agility — the ability to swap algorithms without re-architecting systems.

CRYPTO-AGILE ARCHITECTURE PATTERN APPLICATION CODE — algorithm-unaware ▼ calls abstract interface CRYPTOGRAPHIC ABSTRACTION LAYER — encrypt() / sign() / kex() ▼ dispatches by policy/config ML-KEM Provider ML-DSA Provider ECDH / ECDSA Provider (legacy) HYBRID Combiner Policy Engine — selects provider by context, compliance rules, and feature flags
Fig 11. Crypto-agile architecture. Applications call abstract interfaces; a policy engine selects the appropriate provider (classical, PQ, or hybrid) based on runtime configuration. This enables seamless algorithm rotation without code changes.

Key design principles for crypto-agility:

  1. Abstraction: Application code never references specific algorithms directly
  2. Configuration-driven: Algorithm selection controlled through policy, not code
  3. Negotiation support: Protocols advertise multiple algorithm suites and negotiate the strongest mutual option
  4. Algorithm metadata: Key material tagged with algorithm identifiers for forward-compatible deserialization
  5. Graceful deprecation: Policy engine can phase out algorithms gradually with monitoring and alerts

6. Post-Quantum Security Lifecycle

PQC migration is not a one-time project — it establishes a new operational model for ongoing cryptographic lifecycle management. The post-quantum era demands continuous assessment, rotation, and adaptation.

6.1 Lifecycle Model

POST-QUANTUM SECURITY LIFECYCLE CRYPTO GOVERNANCE 1. MONITOR Track standards, threats, and algorithm health 2. ASSESS Evaluate impact on deployed infrastructure 3. PLAN Update migration roadmap & priorities 4. DEPLOY Roll out updates, rotate keys, re-sign 5. VALIDATE Test, certify, audit compliance 6. REPORT Dashboard metrics, exec briefings 7. ADAPT Revise policies for new algorithm variants 8. EDUCATE Train teams, update runbooks & procedures
Fig 12. The post-quantum security lifecycle. Cryptographic governance is an ongoing cycle — not a one-time migration. New algorithm variants, emerging attacks, and evolving standards require continuous monitoring and adaptation.

6.2 Lifecycle Activities in Detail

Monitor — Subscribe to NIST, IETF, and ETSI working group updates. Track cryptanalysis advances. Maintain a threat intelligence feed for quantum computing progress (IBM, Google, and other quantum hardware roadmaps).

Assess — When new guidance or attacks emerge, evaluate impact against the CBOM. Determine whether deployed algorithm parameter sets remain at target security levels.

Plan — Update the migration roadmap with new milestones. Adjust priority matrix based on emerging threats or new regulatory requirements.

Deploy — Execute algorithm updates through the crypto-agile infrastructure. Rotate keys, re-issue certificates, update firmware signatures. Use canary deployments and feature flags.

Validate — Run interoperability testing against reference implementations. Verify FIPS 140-3 compliance for new algorithm modules. Penetration test with PQ-aware tooling.

Report — Publish migration progress dashboards. Provide executive-level risk briefings. Report compliance status against CNSA 2.0, NIST SP 800-227, and applicable sector regulations.

Adapt — Incorporate lessons learned. Adapt policies for new algorithm families (e.g., if NIST adds new signature schemes from the ongoing additional signatures project).

Educate — Update training materials for development, operations, and security teams. Revise incident response playbooks to cover quantum-related scenarios.

6.3 Key Performance Indicators

Track migration progress with quantifiable metrics:

KPI Description Target
CBOM coverage % of cryptographic assets inventoried 100%
HNDL exposure # of high-sensitivity channels still using classical-only key exchange 0
Hybrid adoption % of TLS endpoints supporting hybrid key exchange 100% by Phase 1 end
PQ signature coverage % of code signing and certificates using dual or PQ-only signatures 100% by Phase 2 end
Crypto-agility score % of systems using abstracted crypto interfaces ≥ 90%
Vendor PQ readiness % of critical vendors with published PQ roadmaps ≥ 80%
Mean time to rotate Average time to deploy a new algorithm across the estate < 30 days

7. Implementation Considerations

7.1 Performance Impact

PQC algorithms have different performance characteristics than their classical counterparts. Key sizes and computation costs vary significantly:

Algorithm Public Key Ciphertext/Sig Keygen Encaps/Sign Decaps/Verify
ECDH-P256 64 B 64 B 0.1 ms 0.1 ms 0.1 ms
ML-KEM-768 1184 B 1088 B 0.03 ms 0.04 ms 0.03 ms
ECDSA-P256 64 B 64 B 0.1 ms 0.1 ms 0.1 ms
ML-DSA-65 1952 B 3309 B 0.1 ms 0.3 ms 0.1 ms
SLH-DSA-128s 32 B 7856 B 3.0 ms 60 ms 3.0 ms

The computation overhead of ML-KEM and ML-DSA is comparable to classical algorithms. The primary impact is bandwidth: larger keys and ciphertexts/signatures affect:

  • TLS handshake size (additional ~2–3 KB per hybrid handshake)
  • Certificate chain transmission (especially with ML-DSA certificates)
  • IoT and constrained device scenarios where bandwidth is limited
  • DNS records (DNSSEC with PQ signatures is an unsolved challenge)

7.2 Testing Strategy

A robust testing strategy must validate both correctness and compatibility:

  1. Algorithm validation: Run NIST Known Answer Tests (KATs) for all PQ implementations
  2. Interoperability testing: Verify hybrid handshakes across different library implementations (OpenSSL, BoringSSL, liboqs)
  3. Performance benchmarking: Measure latency impact at P50, P95, P99 under production traffic patterns
  4. Rollback testing: Verify that disabling PQ algorithms cleanly falls back to classical-only operation
  5. Fuzzing: Run PQ-specific fuzz testing on KEM and signature parsers (key/ciphertext/signature format validation)

7.3 Vendor and Supply Chain Readiness

Engage vendors early with specific PQ readiness questions:

  • When will your product support ML-KEM / ML-DSA?
  • Do your HSMs support PQ key generation and operations?
  • Can your load balancers / CDNs negotiate hybrid cipher suites?
  • What is your FIPS 140-3 certification timeline for PQ modules?
  • Do you support crypto-agile configuration (algorithm selection by policy)?

8. Conclusion

Post-quantum cryptographic migration is the most significant infrastructure security transition of this decade. The HNDL threat makes it urgent today, not at some future date when CRQCs materialize. The path forward is clear:

  1. Start with inventory — You cannot migrate what you cannot see
  2. Deploy hybrid key exchange now — Immediate HNDL protection with minimal risk
  3. Build crypto-agility — Future-proof your architecture for ongoing algorithm evolution
  4. Follow the frameworks — NIST, NSA/CISA, and ETSI provide actionable, validated guidance
  5. Treat migration as a lifecycle — Not a project with an end date, but an operational capability

The standards are finalized. The frameworks exist. The tools are maturing. The only risk is delay.

References

Reference Description
NIST FIPS 203 ML-KEM standard specification
NIST FIPS 204 ML-DSA standard specification
NIST FIPS 205 SLH-DSA standard specification
NIST SP 800-227 (IPD) Recommendations for Transition to Post-Quantum Cryptography Migration
NSA CNSA 2.0 Commercial National Security Algorithm Suite 2.0
CISA Quantum Readiness Quantum readiness guidance for critical infrastructure
ETSI TR 103 619 Migration strategies for post-quantum cryptography
Mosca’s Theorem Quantum threat timeline analysis
RFC 9592 SSH PQ key exchange

You May Also Enjoy