PQC Migration Timeline Planner

This planner is for CISOs, PKI and cryptography owners, and architects who need to move public-key cryptography to quantum-resistant algorithms. Nobody knows exactly when a cryptographically relevant quantum computer will exist, but two risks are already real: "harvest now, decrypt later" collection of long-lived sensitive data, and the years it takes to replace cryptography embedded in products, protocols, and hardware.

NIST published its first post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) for stateless hash-based signatures. The draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms at the 112-bit security level after 2030 and disallowing quantum-vulnerable public-key algorithms entirely after 2035.

How to use this planner

The month ranges below suit a mid-sized to large organization; compress or stretch them to fit. Prioritize systems with Mosca's inequality: if the time your data must stay confidential plus the time your migration will take exceeds the time until a quantum attack is practical, that system is already late.

Phase 0: Governance (month 0–1)

• □ Name an executive sponsor and a program owner spanning PKI, IAM, network, application, and procurement teams.
• □ Add PQC readiness questions to vendor and procurement reviews, since much of your cryptography lives in products you buy.

Phase 1: Inventory (months 1–6)

• □ Build a cryptographic inventory of algorithms, key sizes, protocols, libraries, certificates, and HSMs, and where each is used. CycloneDX supports a cryptography bill of materials (CBOM) format for this.
• □ Flag quantum-vulnerable public-key algorithms: RSA, DH, ECDH, ECDSA, and EdDSA. Symmetric ciphers such as AES-256 and SHA-2/SHA-3 hashes are far less affected.
• □ Classify data by how long it must stay confidential. Long-lived secrets move to the front of the queue.
• □ Identify hard-to-change systems: embedded devices, HSMs, firmware signing, and long-lived root CAs.
• □ Collect vendor PQC roadmaps and note which products cannot be upgraded.

Phase 2: Preparation (months 7–18)

• □ Select algorithms per use case: ML-KEM for key establishment, ML-DSA for general signatures, SLH-DSA where conservative hash-based security justifies larger signatures, and stateful LMS/XMSS (SP 800-208) for firmware signing.
• □ Adopt hybrid key exchange for the transition (for example, the X25519MLKEM768 group in TLS 1.3), so a flaw in either algorithm alone does not break confidentiality.
• □ Engineer crypto-agility: centralize cryptography in shared libraries or services and make algorithms configurable rather than hard-coded.
• □ Test performance and size impacts: larger keys and signatures affect handshakes, certificate chains, packet sizes, and constrained devices.
• □ Update cryptographic standards and key management policy (SP 800-57 covers key management).
• □ Train engineering teams on the new algorithms, libraries, and failure modes.

Phase 3: Migration (months 19–36 and beyond)

• □ Migrate key exchange on sensitive data-in-transit first, because that is what harvest-now-decrypt-later targets.
• □ Make new systems PQC-ready by default through architecture standards.
• □ Schedule critical system and PKI hierarchy migrations in priority order.
• □ Validate each change: interoperability, fallback behavior, downgrade protection, and use of validated cryptographic modules.
• □ Track progress against the inventory and retire classical-only configurations.

Common pitfalls

• Waiting for a "quantum date". Migration lead times, not the threat date, set your deadline.
• An inventory limited to TLS certificates. It misses code signing, SSH, VPNs, token signing, and data-at-rest key wrapping.
• Rolling your own implementations. Use vetted libraries and validated modules.

For sector guidance, see CISA's Post-Quantum Cryptography Initiative.