A post-quantum migration plan is a documented, prioritized roadmap for finding every use of quantum-vulnerable cryptography in your organization — RSA, ECDSA, ECDH, DH — and replacing it with NIST-standardized post-quantum algorithms like ML-KEM and ML-DSA before a cryptographically relevant quantum computer exists. It stopped being a thought experiment in August 2024, when NIST finalized FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, hash-based signatures). The algorithms are standardized, major TLS endpoints already speak hybrid key exchange, and the NSA's CNSA 2.0 timeline starts requiring post-quantum signatures for some software categories this decade. The plan is the deliverable auditors and federal customers are beginning to ask for — not a finished migration, but proof you know where your cryptography is and in what order it moves.
Why the deadline is earlier than the quantum computer
The reason to move before anyone builds the machine is harvest now, decrypt later: an adversary records your encrypted traffic today and decrypts it whenever the hardware arrives. If the data you're protecting must stay confidential for 10+ years — health records, source code escrow, key material, diplomatic anything — traffic captured in 2025 with classical key exchange is already compromised in that threat model. That's why key exchange migrates first and urgently, while signatures (which an attacker can't retroactively forge) migrate on a more relaxed clock, with one big exception: signatures baked into things you can't update later, like secure-boot roots and firmware update verification for devices with 15-year lifetimes.
The external forcing functions are concrete: CNSA 2.0 expects new national security systems to prefer post-quantum algorithms with phase-in beginning mid-decade and completion by 2033; OMB M-23-02 requires US federal agencies to inventory cryptography annually, which flows down to vendors via procurement questionnaires.
Step 1: Build the cryptographic inventory (CBOM)
You cannot migrate what you can't find, and cryptography hides everywhere: TLS terminations, SSH, JWTs, VPNs, code signing, database encryption, hardcoded algorithm choices in application code, and the crypto baked into your dependencies. A credible inventory has at least these columns: system, protocol, algorithm and key size, what data it protects, how long that data must stay secret, who owns it, and how hard the algorithm is to swap.
Practical collection methods:
# What are your TLS endpoints actually negotiating?
nmap --script ssl-enum-ciphers -p 443 api.internal.example.com
# Where does application code pick algorithms?
grep -rEn "RSA|ECDSA|secp256|X25519|PKCS1|rsa\.GenerateKey" --include="*.go" --include="*.py" --include="*.java" src/
# What crypto libraries are in the dependency tree?
syft dir:. -o cyclonedx-json | jq '.components[] | select(.name | test("openssl|bouncycastle|cryptography|libsodium"))'
The supply chain angle is why this belongs on a security engineering blog: most of your cryptography is inherited from dependencies, not written by you. CycloneDX 1.6 (released April 2024) added first-class support for cryptographic bills of materials — CBOMs — so the same pipeline that produces your SBOM can catalog cryptographic assets per component. If you already generate SBOMs per build in something like SBOM Studio, extending the inventory to algorithms is an increment, not a new program.
Step 2: Prioritize by data lifetime, not by system importance
The ranking heuristic is Mosca's inequality: if (years the data must stay secret) plus (years your migration takes) exceeds (years until a cryptographically relevant quantum computer), you're already late for that system. Nobody knows the third number — estimates run 2030-something to never — but the first two are knowable today, and they produce a defensible ordering:
| Priority | Category | Why |
|---|---|---|
| 1 | Key exchange protecting long-lived secrets (TLS for sensitive APIs, VPN tunnels, backups in transit) | Harvest-now-decrypt-later applies now |
| 2 | Long-lifetime signature roots (firmware signing, secure boot, update channels) | Unpatchable after devices ship |
| 3 | General TLS, SSH, internal service mesh | Large surface, but upgradeable |
| 4 | Short-lived tokens, session cookies, JWTs | Worthless to harvest |
Step 3: Deploy hybrids where the ecosystem is ready
You don't have to bet the company on new math. Hybrid key exchange runs a classical and a post-quantum exchange together and hashes both into the session key — an attacker must break both. This is already mainstream: Chrome enabled the X25519MLKEM768 hybrid by default in late 2024, Cloudflare and Google terminate it at the edge, and OpenSSH 9.9 added mlkem768x25519-sha256 (having shipped the Streamlined NTRU Prime hybrid as default back in 9.0). BoringSSL and liboqs give you the primitive if you terminate TLS yourself.
Concretely, this quarter's actionable items look like: upgrade edge proxies and CDN configs to offer hybrid groups, upgrade OpenSSH server fleets to 9.9+, and confirm your TLS libraries' roadmaps (OpenSSL has ML-KEM landing in its 2025 releases). Signature migration — ML-DSA certificates, PQ code signing — waits on CA/Browser Forum and ecosystem work, which is fine per the priority table above, except for firmware roots where SLH-DSA is conservative and available now.
Step 4: Buy crypto-agility, not just algorithms
The uncomfortable lesson from the last migrations (MD5→SHA-1→SHA-2, RSA-1024 deprecation, TLS 1.0 retirement) is that each took roughly a decade, mostly spent finding hardcoded assumptions. A migration plan that just swaps one hardcoded algorithm for another schedules the same pain for 2040 — and NIST has already signaled that today's PQC parameter sets will evolve.
Crypto-agility as concrete engineering requirements: algorithm choices live in configuration, not code; key and signature sizes are never assumed (ML-DSA-65 signatures are around 3.3 KB versus 64 bytes for Ed25519 — fixed-size database columns and packet-size assumptions will break); protocol negotiation handles new groups gracefully; and there's a tested procedure to rotate a root of trust. Budget for the sizes, too: bigger handshakes cost real bytes on constrained links.
What the written plan actually contains
Six sections, none longer than they need to be: (1) the cryptographic inventory and its refresh cadence; (2) data-lifetime classification and the resulting priority order; (3) current-state gaps — where you can't even see the crypto; (4) a phased timeline with owners, aligned to CNSA 2.0 / NIST deprecation milestones; (5) vendor and dependency posture — which of your suppliers have published their own plans, tracked like any other supply chain risk; (6) test and rollback criteria per phase. Safeguard's compliance mapping ties inventory evidence to the frameworks that are starting to ask for exactly this. If you want a deeper structured curriculum, the Academy covers PQC migration as part of its cryptography track.
Frequently asked questions
When do I actually need to be done?
Key exchange for long-secrecy data: as soon as practical, because harvesting is happening now. CNSA 2.0 sets 2030–2033 completion targets for national security systems, and commercial best practice is drafting behind it by a few years. The plan itself, however, is being requested in procurement and audits today.
Are ML-KEM and ML-DSA safe to deploy, or should I wait?
Deploy ML-KEM in hybrid mode now — that's the industry consensus, and it's what Chrome, Cloudflare, and OpenSSH already do, so you're joining the mainstream rather than pioneering. Pure-PQ deployments and signature migrations can wait for ecosystem maturity except where you're shipping unpatchable roots of trust.
What is a CBOM and do I need one?
A cryptographic bill of materials is an inventory of cryptographic assets — algorithms, keys, certificates, protocols — in a machine-readable format, standardized in CycloneDX 1.6. If regulators or customers ask for evidence of your PQC readiness, a CBOM generated per build is the artifact that answers them without a spreadsheet safari.
Does post-quantum migration affect my software supply chain security?
Directly: most of your cryptography arrives via dependencies, so your migration speed is capped by theirs. Inventory which libraries pin you to classical algorithms, track upstream PQC support the way you track CVE fixes, and ask key vendors for their migration plans in the same breath as their SOC 2 report.