Post-Quantum Cryptography Migration Guide: Crypto Inventory and Agility

Moving an organisation off RSA and elliptic curve cryptography is a multi-year programme, and most of the work is finding the cryptography, not swapping the algorithm. The standards exist, hybrid key exchange is on by default in major browsers and TLS libraries, and governments have set deadlines, yet few organisations know where every quantum-vulnerable key, certificate and protocol lives. This guide is the practical programme: inventory and CBOM, prioritisation, algorithm choices, hybrid TLS and SSH, PKI and code signing, vendor readiness, rollout, metrics and framework mapping. It builds on the Post-Quantum Readiness Guide and is for security architects, PKI owners and programme leads. Status statements carry an "as of" date because this area changes monthly.

Key takeaways

• Key exchange first, signatures on a deadline. Harvest-now-decrypt-later makes key exchange urgent today; signatures must be replaced before forgery is possible, and trust anchors take longest.
• The inventory is the programme. A machine-readable CBOM drives prioritisation, vendor engagement and reporting; a one-off spreadsheet does not.
• Hybrid TLS is the cheapest early win. X25519MLKEM768 is the default in current browsers, OpenSSL 3.5, Go and OpenSSH 10, so much of the work is upgrading what terminates TLS.
• Plan to defensible dates. NCSC (2028, 2031, 2035), the EU roadmap (2026, 2030), draft NIST IR 8547 (2030, 2035) and CNSA 2.0 agree: discover now, migrate priority systems this decade, finish by 2035.
• Crypto agility is the lasting outcome. HQC, FN-DSA and new signature schemes are still arriving, so algorithms must change by configuration.

The threat model and how to set urgency

A cryptographically relevant quantum computer (CRQC) running Shor's algorithm would recover private keys from RSA, Diffie-Hellman and elliptic curve public keys. Nobody can date that "Q-day" (or "Y2Q") with confidence. Two attacks follow, with different deadlines:

• Harvest now, decrypt later: traffic recorded today (ATT&CK T1040 Network Sniffing, or bulk collection) is decrypted once a CRQC exists. Anything protected only by ECDHE or RSA key transport is exposed, including credentials and tokens inside the session.
• Future forgery: derived private keys let an attacker mint certificates, sign code and forge tokens. Old signatures leak nothing, but any signing key or trust anchor still accepted on that day is compromised. As the OpenSSH project says, the only urgency for signatures is retiring classical keys before a CRQC arrives.
• Symmetric cryptography and hashes are far less affected: IR 8547 does not schedule AES-128 for withdrawal, although CNSA 2.0 requires AES-256 and SHA-384 or SHA-512.

Mosca's inequality

Michele Mosca's triage test: if x (how long data must stay confidential) plus y (migration time) exceeds z (time to a CRQC), the data is already at risk. IR 8547 notes past migrations took over a decade and expects this one to take at least as long, so y is large for everyone. Apply it per data class: health, government, legal and identity data with a 10 to 25 year shelf life fails today; session data does not. See the Data Classification Guide for setting retention and sensitivity labels that feed x.

Standards and deadlines as of October 2026

IR 8547 is a draft, so cite it as a proposal, though its dates match NSM-10's 2035 target. CNSA 2.0 states NSA will not require hybrid products, while commercial TLS and SSH defaults are hybrid; suppliers to both markets must support both.

Discovery and the cryptographic bill of materials

The NCSC expects discovery across systems, software, network, mobile and endpoint devices, IoT and ICS, and tokens, combining top-down analysis of core services with bottom-up analysis of cryptographic calls. No single tool sees all of it:

• Network observation: passive TLS, SSH and IKE handshake analysis shows negotiated groups and certificate algorithms, but misses data at rest and unused code paths.
• Certificate and key stores: CA databases, CLM platforms, cloud KMS, HSM partitions, Java keystores and Windows certificate stores. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Code and binaries: static analysis for crypto API calls, hard-coded algorithm names, key sizes and OIDs, plus the crypto library versions in each build.
• Configuration: TLS terminators, VPN concentrators, SSH daemons, identity provider token signing (RS256, ES256) and database encryption.
• Suppliers: managed service providers and SaaS vendors should assess what they run for you.

Recording it as a CBOM

CycloneDX 1.6 incorporated the cryptography bill of materials (CBOM) work originally published by IBM, so cryptographic assets sit in the same format as an SBOM and link to the components that use them. The cryptoProperties object takes an assetType of algorithm, certificate, protocol or relatedCryptoMaterial, with fields such as primitive, oid, certificationLevel and nistQuantumSecurityLevel. Generate CBOMs in the build pipeline and merge observed and supplier data; keep them versioned and owned per system. See the AI Supply Chain and AI-BOM Guide.

For each finding record owner, data shelf life, protocol, algorithm, providing library or module, whether it is configurable, and one NCSC option: migrate in place, re-platform, retire, run to end of life, or tolerate the risk.

Choosing algorithms and parameters

An RSA-2048 signature is 256 bytes and ECDSA P-256 about 64. Size is the main performance cost: ML-KEM is computationally cheap, but an ML-DSA-65 chain adds kilobytes to every full handshake.

Terms you will meet in vendor material

• Encapsulation and decapsulation keys: FIPS 203's names for the KEM public and private keys.
• Fujisaki-Okamoto transform: how ML-KEM achieves chosen-ciphertext security, with proofs in the quantum-accessible random oracle model (QROM). The re-encryption check must run in constant time.
• Number theoretic transform (NTT): the polynomial multiplication inside ML-KEM and ML-DSA, and the focus of hardware acceleration and side-channel hardening.
• Lattice hardness: estimates rest on the shortest vector and shortest independent vector problems (SVP, SIVP), costed against reduction algorithms such as Block Korkine-Zolotarev (BKZ). Module learning with rounding (MLWR, used by the unselected Saber) is a deterministic MLWE variant.
• Hash-based internals: SLH-DSA and XMSS use WOTS+ (Winternitz one-time signature plus); LMS uses LM-OTS, and HSS (hierarchical signature system) and XMSS^MT are their multi-tree forms. Reusing a one-time key is catastrophic, hence IR 8547's "not intended for general use".
• Code-based KEMs: HQC (Hamming Quasi-Cyclic) was selected over BIKE (Bit Flipping Key Encapsulation, on quasi-cyclic moderate density parity check codes).
• Isogenies: SIKE, built on supersingular isogeny Diffie-Hellman (SIDH), fell to a classical attack in 2022, the standing argument for hybrid deployment.
• Additional signatures: NIST's second-round candidates include multivariate UOV (unbalanced oil and vinegar) and MAYO, isogeny-based SQIsign, LESS (linear equivalence problem), FAEST (VOLE-in-the-head) and MPC-in-the-head designs based on syndrome decoding. None is a standard as of October 2026.

Hybrid key exchange in TLS, SSH and VPNs

Hybrid key exchange derives the session key from a classical and a post-quantum exchange together, so it holds unless both break. IR 8547 notes that SP 800-56C's composite mode already allows a FIPS 203 secret to be combined with a classical one; that derivation is the "key combiner".

The X25519MLKEM768 client share is 1,216 bytes against 32 for X25519, pushing the ClientHello past one packet. Proxies and old load balancers that assume a one-packet ClientHello can drop the connection; Chrome's PostQuantumKeyAgreementEnabled enterprise policy is a temporary escape hatch. Test inspection devices first. See the TLS Inspection Guide.

Post-quantum pre-shared keys (RFC 8784) mix a symmetric key into IKEv2 derivation where a peer cannot do ML-KEM. They carry every distribution and rotation cost of shared secrets, so keep them to fixed site-to-site links.

PKI, certificates and code signing

Signatures are harder than key exchange because every relying party must understand the new algorithm before you issue with it:

• Parallel PQC hierarchy: a new ML-DSA root and issuing CAs beside the existing PKI, or cross-signing the old root with a new PQC root; the NCSC lists both. Simple to reason about, but doubles operations for a period.
• Composite certificates: draft-ietf-lamps-pq-composite-sigs (RFC Editor queue as of October 2026) pairs ML-DSA with RSA, ECDSA, Ed25519 or Ed448 in one key and signature, so an unchanged PKIX stack carries a hybrid. Confirm your CA, HSM and relying parties support the exact OIDs.
• Pure ML-DSA: RFC 9881 allows only pure ML-DSA in X.509 and prohibits HashML-DSA in certificates and CRLs.
• Public web PKI: post-quantum authentication for public websites is still in development as of October 2026 (Cloudflare documents visitor-side PQ authentication as under development). Start with internal PKI, mTLS and service mesh, where you control both ends.
• Code and firmware signing: the top signature priority, because devices verify against roots fixed at manufacture for a decade or more. CNSA 2.0 expects exclusive PQC signing by 2030, with LMS or XMSS for firmware. Dual-sign releases while verifiers catch up. See the Firmware and Boot Security Guide.
• Token signing: publish new identity provider keys in JWKS beside old ones so JWT and SAML clients can move gradually once ML-DSA profiles settle.

Where identity fits

Most quantum-vulnerable keys belong to machines: workload TLS and mTLS certificates, SSH keys, code signing keys, device certificates, SPIFFE identities and the keys signing every OAuth token. The PQC programme is therefore a machine identity programme, and the certificate inventory, automated issuance and short lifetimes you need anyway (public TLS certificates fall to 47 days by 2029) are what make an algorithm change survivable. Use the key inventory and HSM controls in the Cryptographic Key Management Guide, and track SSH keys separately with the SSH Key Management Guide, because classical SSH user keys never expire on their own.

Running the migration

1. Govern (months 0 to 3): name an accountable owner, fund a programme, publish an approved-algorithm standard, and add PQC clauses to procurement so new purchases do not extend the tail.
2. Discover (by 2028 at the latest): build the CBOM, starting with internet-facing services and long-lived data, and score each item with Mosca's inequality.
3. Quick wins: upgrade TLS terminators, CDNs, proxies and SSH to versions that negotiate hybrid by default, then internal service-to-service TLS. Pilot in rings: test environment, one internal service, then a small share of external traffic.
4. Trust anchors and signing: design the PQC or composite hierarchy, test certificate sizes on constrained devices and smart cards, and start dual-signing releases.
5. High-priority systems (by 2031): migrate what fails the Mosca test; re-platform or retire what cannot change.
6. Long tail (by 2035): OT, embedded, legacy and partner integrations. Some become tolerated risks with compensating controls such as isolated networks.

Testing and rollback: keep classical groups enabled beside hybrid ones so failed negotiation falls back rather than breaks, keep the group list a one-change configuration value, and watch handshake failures and latency for a week per ring. Keep classical chains valid until every relying party validates the new one. Rolling back key exchange is cheap; rolling back a revoked root is not, so revoke last.

Decision guidance

• Hybrid or pure PQC: hybrid for general key exchange, as insurance against a flaw in a young algorithm; pure ML-KEM-1024 and ML-DSA-87 where CNSA 2.0 or a certification demands standardised algorithms only.
• ML-DSA or SLH-DSA: ML-DSA for frequent signing and handshakes; SLH-DSA where signatures are rare, keys live for decades and you want hash-only assumptions.
• Stateful hash-based: LMS or XMSS only in an HSM or signing service that guarantees state is never reused, including across backups and failover.
• Small organisations: most exposure sits with suppliers. Keep libraries and appliances current, get dated roadmaps from SaaS, CDN and VPN providers, and inventory your own certificates and SSH keys.
• Large or regulated organisations: need the full CBOM, a PQC PKI design, an HSM refresh plan and board reporting against 2028, 2031 and 2035. See the Cyber Risk Quantification Guide for expressing the risk in business terms.

Vendor, HSM and library readiness

HSMs are often the slowest dependency: check firmware support for ML-DSA key generation, PQC key wrapping, and partition capacity with larger keys. Libraries move faster: OpenSSL 3.5, a long-term support release, ships ML-KEM, ML-DSA and SLH-DSA, so many Linux systems inherit support through distribution upgrades. See the CLM Buyer's Guide for certificate platform evaluation.

Detection and measurement

Log the negotiated key exchange group on TLS terminators and the key exchange algorithm in SSH logs, and trend the hybrid share. Alert when services that negotiated hybrid fall back to classical groups: a broken middlebox or a downgrade attempt (ATT&CK T1689 Downgrade Attack, T1557 Adversary-in-the-Middle). Watch issuance for new long-lived quantum-vulnerable certificates and signing logs for unapproved algorithms (T1553.002 Code Signing).

• Inventory coverage: production systems with a current CBOM entry, weighted by data class.
• Hybrid share: external and internal TLS and SSH connections negotiating a hybrid group.
• Long-lived exposure: quantum-vulnerable certificates and keys valid beyond 2030, especially roots and code signing keys.
• Agility: systems with hard-coded algorithms, trending to zero.
• Supplier readiness: critical suppliers with a dated, written PQC roadmap.
• Milestones: high-priority systems migrated against the 2031 target.

Common failure patterns

• Treating a network scan as the inventory. It misses data at rest, code paths, embedded devices and signing keys: the long-lived items.
• Deprioritising signatures because there is no harvest risk. The Microsoft Storm-0558 Key Breach showed what one usable signing key does to token trust; a CRQC would make every classical signing key still in use that valuable.
• No rotation muscle. Teams that cannot replace a code signing certificate quickly will not migrate one. The AnyDesk breach forced a revocation and re-signing exercise that a crypto-agile pipeline makes routine.
• Enabling hybrid without testing inspection devices. Larger ClientHellos break some proxies, and teams then disable PQC globally instead of fixing the middlebox.
• Buying non-agile hardware today. Appliances, HSMs and devices without upgradeable cryptography become the 2035 long tail.
• Stateful hash-based signing in ordinary software. Restoring a VM snapshot can reuse one-time keys and destroy LMS or XMSS security.

Framework mapping

Practitioner checklist

• Appoint a PQC programme owner and publish an approved-algorithm standard naming ML-KEM-768, ML-DSA-65 and their CNSA 2.0 equivalents.
• Build a CycloneDX 1.6 CBOM per critical system and score each entry with Mosca's inequality.
• Upgrade TLS terminators and SSH to versions that negotiate X25519MLKEM768 and mlkem768x25519-sha256 by default, after testing inspection devices.
• Log negotiated key exchange groups and report the hybrid share monthly.
• Design a parallel or composite PQC PKI and test certificate sizes on constrained devices.
• Dual-sign firmware and software releases and move signing keys to HSMs with PQC support.
• Add PQC, FIPS 140-3 scope and CBOM questions to every security-relevant procurement.
• Map milestones to NCSC 2028, 2031 and 2035, EU 2026 and 2030, and CNSA 2.0 where it applies.
• Keep classical fallback configurable during rollout and revoke classical trust anchors last.

Standards and references

• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards (initial public draft)
• NIST: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption
• UK NCSC: Timelines for migration to post-quantum cryptography
• NSA: The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ
• European Commission: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
• IETF: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
• IETF: RFC 9881, Algorithm Identifiers for ML-DSA in X.509
• OWASP CycloneDX: Cryptography Bill of Materials

Related NHI Mgmt Group resources: Post-Quantum Readiness Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Cryptographic Key Management Guide · Cryptography Basics Guide · TLS Inspection Guide