The playbook

Migrating to post-quantum cryptography.

A comprehensive, NIST-aligned process organized into seven phases plus continuous crypto-agility. Built on the CISA/NSA/NIST Quantum-Readiness factsheet, the NIST NCCoE Migration to PQC project (SP 1800-38), NIST IR 8547, and NIST CSWP 39 on cryptographic agility.

7
phases from governance to validation
42–54
months typical enterprise timeline
2030
classical algorithms begin deprecation
2035
full migration target
How to use this: the phases are sequential in emphasis but overlapping in practice — inventory is continuous, crypto-agility is woven throughout, and high-priority systems can pilot hybrid PQC while discovery of the long tail continues. Start Phase 0–2 immediately; they gate everything else.
00–07

The migration phases

0

Establish governance & a quantum-readiness roadmap

You can't run a multi-year cryptographic program without an owner and a mandate. The CISA/NSA/NIST factsheet makes this step one.

  • Name an executive sponsor and a PQC migration lead / working group spanning security, infrastructure, application, procurement, and risk.
  • Set the internal deadlines you're bound by (map external mandates — CNSA 2.0 2027, IR 8547 2030/2035 — to your obligations).
  • Define scope, success criteria, budget, and reporting cadence. Treat PQC as a program, not a project.
  • Update policy so new systems must be crypto-agile and PQC-capable from procurement onward.
1

Discover & build a cryptographic inventory (CBOM)

You cannot migrate what you cannot see. Discovery is the single hardest and most important phase, and it's mandated annually for U.S. federal systems (OMB M-23-02). Catalog every use of cryptography across the estate.

  • Discover algorithms, key sizes, certificates, protocols, and libraries in transit, at rest, in code, and in identity/PKI.
  • Use a layered approach: passive network & SIEM log mining, active TLS/cert scanning, source/binary analysis, host agents, and cloud KMS/HSM APIs.
  • Record findings as a Cryptography Bill of Materials (CBOM) in CycloneDX 1.6 — a live, machine-readable inventory, not a one-time spreadsheet.
  • Capture, per asset: system, algorithm + parameters, purpose, data-confidentiality lifetime, exposure, and owner.
This is where AI helps most. See the dedicated Cryptographic Inventory page for discovery methods (including mining Splunk / SIEM logs) and a proof-of-concept plan for an AI-based inventory tool.
2

Assess risk & prioritize

Not everything migrates at once. Rank systems so effort goes where the risk is highest first.

  • Score each asset with Mosca's inequality (X + Y > Z): long-confidentiality data with long migration time is most urgent.
  • Prioritize "harvest now, decrypt later" exposure — anything with long-lived secrets crossing untrusted networks.
  • Weigh root-of-trust longevity (CA hierarchies, firmware/code-signing keys, device identities that live for decades).
  • Map dependencies and migration complexity: what's controlled by you vs. by a vendor; what's hardware-bound.
  • Produce a prioritized migration backlog tied to the inventory.

See Mosca's inequality for the scoring rule: if X + Y > Z, the asset is already exposed.

3

Plan the migration & engage vendors

Turn priorities into a sequenced plan, and get ahead of the parts you don't own.

  • Engage your technology vendors early — ask for their PQC roadmaps and support dates; a large share of your crypto is inside their products.
  • Add PQC and crypto-agility requirements to procurement and contracts (the EU Cyber Resilience Act already expects updatable cryptographic mechanisms).
  • Choose target algorithms and parameter sets (see the cheat sheet below) and a hybrid strategy for the transition period.
  • Sequence waves: quick wins (TLS front doors, VPNs) → high-risk long-lived data → deeply embedded / hardware-bound systems last.
4

Remediate, test & pilot hybrid PQC

Deploy in a lab before production. The NCCoE practice guide (SP 1800-38C) emphasizes interoperability and performance testing.

  • Stand up a non-production lab to validate PQC and hybrid handshakes end-to-end and measure size/latency impact.
  • Pilot hybrid key exchange (classical + PQC, e.g. X25519MLKEM768) on high-priority TLS/VPN paths — this neutralizes HNDL immediately while keeping a classical hedge.
  • Test for larger keys/signatures breaking protocol assumptions, buffers, MTU/fragmentation, and constrained devices.
  • Update libraries (e.g. OpenSSL 3.x + providers), and refactor hard-coded algorithm choices behind an abstraction layer.
5

Deploy to production in waves

Roll out along the prioritized backlog with change control and rollback plans.

  • Deploy hybrid/PQC to production systems wave by wave; keep classical fallback until confidence is high.
  • Reissue certificates and re-key from PQC-capable CAs/HSMs where root-of-trust migration is in scope.
  • Coordinate both ends of every protocol — a handshake only upgrades when client and server both support it.
  • Track coverage against the CBOM so "done" is measurable.
6

Validate, monitor & report

Prove the migration worked and keep it honest over time.

  • Re-run discovery to confirm quantum-vulnerable algorithms are gone from migrated systems and catch regressions.
  • Monitor for downgrade attacks and misconfigurations that fall back to classical-only.
  • Keep the CBOM current on a schedule; report progress against internal and regulatory deadlines.
  • Validate compliance evidence (FIPS 140-3 modules, CNSA 2.0 where applicable).
7

Maintain cryptographic agility (continuous)

PQC is not a one-time swap. NIST CSWP 39 frames crypto-agility as the durable capability to change algorithms with minimal disruption.

  • Keep algorithms behind abstraction layers and configuration, never hard-coded, so the next transition is a change, not a rebuild.
  • Maintain a living inventory and automated discovery so drift is caught early.
  • Watch the standards pipeline (HQC, FN-DSA/FIPS 206, future revisions) and be ready to adopt or rotate.
  • Bake crypto-agility requirements permanently into architecture reviews and procurement.
08

Which algorithm, for what

NeedReplace…With (NIST)Enterprise default
Key exchange / establishment (TLS, VPN, SSH)RSA key transport, ECDH, DHML-KEM (FIPS 203)ML-KEM-768, deployed hybrid with X25519
General digital signatures (certs, tokens, docs)RSA, ECDSA, EdDSAML-DSA (FIPS 204)ML-DSA-65
Long-lived / firmware & code signingRSA, ECDSASLH-DSA (FIPS 205) or stateful LMS/XMSS (SP 800-208)SLH-DSA for conservative long-term roots
High-assurance / CNSA 2.0 scope—ML-KEM-1024 / ML-DSA-87Step up parameter sets
Bulk data encryption (at rest / in transit)AES-128Symmetric stays — just size upAES-256; SHA-256/384 for hashing
Rule of thumb: ML-KEM-768 / ML-DSA-65 are sensible enterprise defaults; step up to -1024 / -87 for high assurance or national-security-system scope; reserve SLH-DSA for conservative, long-lived signing such as firmware. Deploy key exchange hybrid during the transition.
09

Deadlines that drive the plan

Aug 2024
NIST finalizes FIPS 203/204/205. The starting gun — deployable standards exist.
2025–26
Roadmaps & inventory. EU members publish national strategies; crypto inventories underway. HQC selected as backup KEM (Mar 2025).
Jan 2027
CNSA 2.0 hard gate. New U.S. national-security-system acquisitions must be quantum-resistant; software/firmware signing face exclusive-use requirements.
2030
Deprecation begins. 112-bit algorithms (RSA-2048, ECC P-256) deprecated for new federal deployments per NIST IR 8547. "Starting in 2030 is already too late" for long-lived data.
2035
Full migration target. Quantum-vulnerable algorithms disallowed for federal systems; NSM-10 and EU roadmap converge on 2035.

Dates reflect published guidance and, for IR 8547, a draft that may change. See the home-page timeline for detail and confirm against primary sources.

10

Best practices & common pitfalls

Do

  • Deploy hybrid key exchange first on HNDL-exposed paths.
  • Prioritize by data lifetime and root-of-trust longevity, not convenience.
  • Put PQC & crypto-agility clauses in every contract now.
  • Test in a lab and measure size/latency before rollout.
  • Keep the CBOM live; re-run discovery on a schedule.

Avoid

  • Treating inventory as a one-time spreadsheet exercise.
  • Hard-coding the new algorithms — you'll do this again.
  • Ignoring embedded/OT and hardware that can't be field-upgraded.
  • Upgrading one end of a protocol and forgetting the other.
  • Waiting for "final" standards to start discovery and piloting.
11

Primary sources

Start with the hardest phase

Discovery and prioritization are where enterprises stall. The inventory page covers the discovery methods — network and TLS scanning, SIEM and log mining, source and binary analysis, endpoint agents — and how to turn their output into a CBOM.

Inventory methods & PoC plan → Vendors who do this