Read this first
A post-quantum migration is a sequencing problem, not a single cutover. Five phases: inventory what you have, prioritize by risk and deadline, protect exposed traffic with hybrid TLS, migrate signatures and PKI, then bake in crypto-agility so the next change is cheap. Sequence by data confidentiality lifetime, not by how easy a system is to touch — the systems holding your longest-lived secrets go first even when they are the hardest.
Every organization that takes the quantum threat seriously arrives at the same question: not whether to migrate to post-quantum cryptography, but in what order. The algorithms are standardized and the deadlines are published; the hard part is turning a sprawling estate of TLS endpoints, PKI, code-signing pipelines, and embedded firmware into a sequenced plan that closes the highest risks first without breaking anything in flight. A roadmap is what converts an inventory into that plan.
Phase 1 — Build the inventory
You cannot sequence what you cannot see. The roadmap begins with a cryptographic inventory: a machine-readable map of where every algorithm, key, certificate, and protocol version actually lives — in application code, libraries, TLS configurations, hardware modules, and third-party dependencies. Without it, prioritization is guesswork and you will discover the forgotten key-exchange in a legacy service the hard way. The inventory is the source of truth every later phase reads from.
Phase 2 — Prioritize by risk and deadline
With the estate mapped, rank each data class two ways. First by exposure, using Mosca's inequality: if data confidentiality lifetime (X) plus migration time (Y) exceeds time-to-quantum (Z), the data is already at risk from harvest-now-decrypt-later. Second by mandate, using the deadlines that apply to you:
- **CNSA 2.0** — NSA requires post-quantum algorithms exclusively across national security systems, with software and firmware signing first and full adoption by 2033.
- **NIST IR 8547** — the federal timeline deprecates RSA-2048 and ECC after 2030 and disallows them after 2035, setting the pace most enterprises should plan against.
- **OMB M-23-02** — obliges US federal agencies to inventory quantum-vulnerable systems and report them, making Phase 1 a compliance artifact, not just an engineering one.
Sequence by data lifetime, not by ease
The tempting order is to migrate whatever is easiest first — a stateless service you fully control. Resist it. The correct first movers are the systems holding secrets whose confidentiality must outlive the time-to-quantum, even when those systems are the oldest and most fragile. A quick win on short-lived data does nothing for the archive an adversary is recording today; a hard migration of long-lived data closes the exposure that actually matters.
Phase 3 — Protect exposed traffic first
The one class of risk that is accruing right now is recorded key exchange. So the first migration to ship, ahead of the rest of the estate, is hybrid TLS key exchange: wrapping a post-quantum KEM around the classical exchange (see hybrid key exchange) so recorded handshakes cannot be decrypted retroactively. This closes the harvest-now-decrypt-later window on externally facing traffic while remaining interoperable with classical clients — you get protection before the full programme is anywhere near done.
Phase 4 — Migrate signatures and PKI
Signatures are not exposed to harvesting — a forged signature is only useful after a quantum computer exists — so they follow key exchange rather than lead it. But they carry their own engineering weight: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) produce signatures and keys far larger than ECDSA, which stresses certificate sizes, handshake budgets, protocol limits, and storage. For firmware and long-lived boot chains, the stateful hash-based schemes LMS and XMSS (SP 800-208) are the standardized choice, with careful state management to avoid one-time-key reuse. Plan PKI, code signing, and document signing as a distinct workstream.
Phase 5 — Bake in crypto-agility
The last phase makes the next migration cheap. Crypto-agility means algorithms are named in configuration, negotiated at runtime, and swappable without redeploying application logic — so the transition after this one is a config change, not another multi-year programme. Treat the current migration as the forcing function that finally decouples your systems from any single algorithm.
Avoiding breakage on the way
Hybrids exist precisely so migration is not a flag day: they keep backward compatibility with peers that have not moved. Roll out in stages behind feature flags, run interoperability testing against real client populations before enforcing, and keep a rollback path for every change until the post-quantum side is proven in production. The goal is a continuous ratchet — never a single irreversible cutover.
How quantakrypto helps
We run this roadmap end to end: an audit produces the inventory and the risk-and-deadline ranking, a migration engagement sequences and ships the phased rollout — hybrid TLS first, then signatures and PKI, then agility — and training leaves your teams able to reason about X + Y > Z and design for algorithm change on their own. Start with the inventory: everything downstream depends on knowing what you have.