Framework
Five-Phase Migration Model
Every successful PQC migration follows roughly the same arc. The phases are not strictly sequential — you will run several in parallel — but each unlocks the next.
Inventory — Cryptographic Bill of Materials (CBOM)
You cannot migrate what you cannot see. Build a Cryptographic Bill of Materials: a complete enumeration of every cryptographic algorithm, key, certificate, protocol, library, and dependency in your environment.
- Scan application code and dependencies (OpenSSL version, BouncyCastle, Java JCA providers)
- Enumerate TLS certificates (expiry, algorithm, key size) — use crt.sh, Shodan, or internal PKI reports
- Audit HSMs, TPMs, and smartcard key types
- Map third-party integrations and APIs that use asymmetric crypto
- Review SSH authorized keys and host keys (ED25519 is still vulnerable to Shor's)
- Identify long-lived data (classified, medical, financial) subject to HNDL risk
Tools: CBOM scanners, openssl s_client, Trivy/Grype for SBOMs, internal PKI platforms (EJBCA, AWS Private CA reporting), commercial cryptographic inventory tools (Crypto4A, Entrust, Cryptosense).
Risk Assessment — Mosca Triage
Apply Mosca's inequality (X + Y > Z → at risk) to each asset class identified in the CBOM. Prioritize by:
- Data sensitivity & longevity (X) — classified, PII, IP, financial records with >10-year retention are highest priority
- Migration complexity (Y) — embedded systems, HSMs, third-party-locked APIs, and legacy mainframe crypto are hardest
- Reachability — internet-facing TLS endpoints are actively harvested; internal-only systems have more time
Output: a risk-ranked migration backlog. Focus first on HNDL-exposed long-lived data, then internet-facing signing infrastructure, then internal systems.
Crypto Agility — Pluggable Cipher Design
Crypto agility means your systems can swap cryptographic algorithms without major re-engineering. It is the most important architectural change you can make regardless of PQC timeline.
- Centralize crypto operations into dedicated libraries / services rather than inlining algorithm calls
- Parameterize algorithm choices (e.g., cipher suite lists in TLS, SSH KEX algorithms) rather than hard-coding
- Design key stores and HSM slots to support multiple key types simultaneously
- Audit for hard-coded key sizes or algorithm OIDs in serialization formats
SIKE taught us agility matters
When SIKE was broken in 2022, deployments using hard-coded SIKE had to ship emergency patches. Agile deployments changed one configuration line. Design for algorithm replacement from the start.
Hybrid Rollout — Classical + PQC Defense-in-Depth
A hybrid scheme combines a classical algorithm and a PQC algorithm so that security holds if either is unbroken. This is the recommended transition approach for internet-facing protocols.
- For TLS key exchange:
X25519MLKEM768(X25519 + ML-KEM-768). Already deployed by Chrome, Firefox, Cloudflare, AWS. - For X.509 certificates: dual-signature certificates (classical + ML-DSA composite); IETF LAMPS is standardizing composite certificate formats.
- For SSH:
mlkem768x25519-sha256KEX (OpenSSH 9.x, enabled by default in 9.9) - For code signing: issue dual-signed artifacts (SHA-256 ECDSA + SHA-384 ML-DSA) during transition
Hybrid adds overhead but provides insurance: if the PQC algorithm turns out to have an unexpected classical vulnerability, the classical component still protects you. NIST and CISA both recommend hybrid as the transition approach.
Pure PQC — Full Transition
Once CRQC risk is imminent (or on a regulatory deadline), cut over to PQC-only. By this stage:
- All TLS certificates reissued with ML-DSA or FN-DSA public keys
- All code-signing certificates using ML-DSA or SLH-DSA
- All SSH host keys and authorized keys replaced with PQC alternatives
- All VPN tunnels using PQC IKEv2
- CA hierarchies rebuilt with PQC root and intermediate CAs
- HSMs and TPMs supporting PQC algorithms (requires hardware refresh for older devices)
Protocol-by-protocol
Migration Guidance by Protocol
TLS 1.3
Enable hybrid key exchange as the first step. Major TLS libraries support it:
- OpenSSL 3.x + OQS provider — liboqs integration; supports X25519MLKEM768 as a group
- BoringSSL / Chrome — shipped X25519MLKEM768 since Chrome 124 (May 2024)
- AWS s2n-tls — ML-KEM hybrid in production for Amazon.com
- Cloudflare — X25519MLKEM768 on all TLS endpoints since 2024
- nginx / Apache — requires compiling against OQS-OpenSSL or waiting for upstream support
Certificate migration (signature algorithm) is a separate step; it requires CAs to issue ML-DSA certificates. Most public CAs have not yet done so; expect 2025–2027 for widespread availability. Meanwhile, hybrid certificates remain the transition vehicle.
SSH
- OpenSSH 9.0+ supports
[email protected](NTRU hybrid); enabled by default since 9.0 (2022) - OpenSSH 9.9 (Oct 2024):
mlkem768x25519-sha256added and set as preferred KEX algorithm - Rotate host keys: add PQC host key types once library support is available
- Rotate authorized_keys: generate PQC user keys once supported by common SSH clients (in progress)
VPN / IPsec / IKEv2
- RFC 8784 — Mixing Pre-Shared Keys (PSK) with IKEv2 to provide PQ resistance without algorithm changes. Available in strongSwan, Libreswan today.
- RFC 9370 — Multiple Key Exchanges in IKEv2. Allows layering ML-KEM alongside classical ECDH in IKEv2 SA negotiation. Requires updated VPN software (strongSwan 5.9.12+).
- WireGuard: the protocol is not natively hybrid-capable; proposals exist but no IETF standard. Use PSK workaround as interim measure.
Code and firmware signing
- Use LMS or XMSS (NIST SP 800-208) for firmware images today — these are ready standards with library support (pycryptodome, hashsig.js, Bouncy Castle)
- For PKI-based code signing (Authenticode, macOS notarization, RPM/DEB package signing): transition to ML-DSA when CA support is available
- Key management: LMS/XMSS require stateful key tracking; deploy in HSMs that support state management (Thales Luna, AWS CloudHSM)
Secure messaging
- Signal PQXDH (2023) — Extended Triple Diffie-Hellman upgraded to use ML-KEM-1024 in the initial key establishment phase. Provides post-quantum forward secrecy against HNDL.
- Apple iMessage PQ3 (2024) — periodic re-keying with ML-KEM to achieve post-compromise security at Level 3 (their classification). Rolling ratchet provides post-quantum forward secrecy.
- These deployments demonstrate that end-to-end encrypted messaging can achieve real post-quantum protection at scale today.
Email (S/MIME & OpenPGP)
Less urgent than TLS (email typically has shorter sensitive lifetime) but relevant for long-term archival. IETF LAMPS WG is specifying ML-KEM and ML-DSA for CMS (RFC 5652), S/MIME, and OpenPGP extension drafts. Await RFC finalization and CA/mail client support; plan for 2026+ practical deployment.
Ecosystem snapshot
Vendor & Platform Readiness
| Vendor / Product | PQC status | Algorithm deployed / supported |
|---|---|---|
| Google Chrome | ✓ Deployed | X25519MLKEM768 (TLS 1.3 KEX, since v124) |
| Mozilla Firefox | ✓ Deployed | X25519MLKEM768 (since v132) |
| Apple Safari | ⚠ In progress | Hybrid KEM in Technology Preview |
| Cloudflare | ✓ Deployed | X25519MLKEM768 on all TLS, Kyber in Workers KV |
| AWS (S2N-TLS) | ✓ Deployed | ML-KEM hybrid in S2N-TLS, CloudFront, API Gateway |
| AWS KMS | ⚠ Preview | ML-KEM wrapping key preview (2024) |
| Google Cloud | ⚠ Preview | Hybrid KEM in Cloud KMS preview |
| Azure | ⚠ In progress | Quantum-safe crypto roadmap; FIPS 203/204 planned |
| OpenSSH 9.9 | ✓ Deployed | mlkem768x25519-sha256 default KEX |
| strongSwan 5.9.12+ | ✓ Available | ML-KEM via liboqs plugin; RFC 9370 |
| Signal | ✓ Deployed | PQXDH with ML-KEM-1024 (2023) |
| Apple iMessage | ✓ Deployed | PQ3: ML-KEM ratchet (2024) |
| Thales Luna HSM | ⚠ Preview | ML-KEM/ML-DSA in Luna 7.8+ firmware |
| Entrust nShield | ⚠ Preview | PQC codeSafe modules in preview |
| DigiCert | ⚠ In progress | TrustCore PQC: ML-DSA certificate issuance planned |
Common pitfalls
What Goes Wrong in PQC Migrations
Certificate chain bloat
An X.509 certificate chain using ML-DSA can be 5–10× larger than an ECDSA chain. A root + two intermediates + leaf in ML-DSA-65 exceeds 30 KB. TLS ClientHello size and Certificate message size can exceed TCP initial window (~14 KB), causing an extra round trip and degrading TLS performance significantly. Test with openssl s_time and measure time-to-first-byte.
MTU fragmentation in TLS 1.3 with hybrid KEM
ML-KEM ciphertexts (~1088 bytes) combined with TLS record overhead can push ClientHello above common MTU sizes (1500 bytes Ethernet, 1280 bytes IPv6 minimum). Path MTU Discovery (PMTUD) may black-hole connections on misconfigured networks. Test with MTU-constrained environments and enable TCP MSS clamping on edge routers.
Performance on constrained devices
IoT devices, embedded systems, and older smartphones may lack hardware acceleration for NTT (Number Theoretic Transform) operations used in ML-KEM/ML-DSA. A Cortex-M4 at 64 MHz needs ~50 ms for ML-KEM-768 encapsulation; a Cortex-M0 may need 300+ ms. Test on representative hardware before committing to algorithm choices for constrained environments.
Stateful signature key management
LMS and XMSS are one-time-use per leaf node. Using the same leaf twice destroys the security guarantee entirely. Deploy only in HSMs with hardware-enforced state management. Never use LMS/XMSS in software-only environments without a robust distributed state-tracking solution.
Regulatory timelines
Migration Deadlines by Jurisdiction
United States
| Directive / Standard | Deadline | Scope |
|---|---|---|
| NSM-10 (National Security Memorandum) | 2022 (issued) | Mandates federal agencies begin PQC migration planning immediately |
| CNSA 2.0 — Software / firmware signing | 2025 | National Security Systems (NSS): must support PQC for software signing |
| CNSA 2.0 — Web / cloud services | 2026 | NSS: PQC for internet-accessible systems (ML-KEM + ML-DSA in TLS) |
| CNSA 2.0 — Networking & PKI | 2030 | All NSS networking equipment; PKI migration |
| CNSA 2.0 — Full transition | 2033–2035 | All NSS; legacy classical algorithms deprecated |
| CISA Quantum Readiness Roadmap | 2024–2035 | Federal civilian agencies; mirrors NSM-10 with sector-specific guidance |
European Union & Germany
- ENISA (2023): "Organizations should begin PQC migration planning immediately"; sector-specific guidance for telecoms, finance, health.
- BSI TR-02102-1 (2024): approves ML-KEM and ML-DSA for new deployments; recommends AES-256 and SHA-384 for symmetric systems.
- NIS2 Directive: "appropriate technical measures" for cryptography; regulators expected to reference ENISA PQC guidance from 2025 onwards.
- eIDAS 2.0 / EUDIW: European Digital Identity Wallet; BSI and ENISA working on PQC requirements for the wallet trust framework.
UK
NCSC (National Cyber Security Centre) published Preparing for quantum-safe cryptography (2020, updated 2023): recommends a four-stage approach aligned with NIST/IETF; encourages beginning inventories and planning now. No hard deadlines yet for private sector.
China
OSCCA SM-series transition: SM2 is vulnerable to Shor's. CSTC is developing PQC standards; domestic enterprises should include SM2 in migration scope and monitor OSCCA guidance for PQC SM-series equivalents.
Need a Migration Roadmap?
Qifei Li provides cryptographic architecture reviews, PQC readiness assessments, CBOM development, and migration roadmaps tailored to your technology stack and regulatory environment.