Post-Quantum Crypto Migration: The Checklist for Teams Who Haven't Started

Here is the situation, stripped of the marketing. The standards are final. The deadlines are law. The math that protects almost every secret you move over a network is on a clock, and the clock is now measured in a handful of years, not decades. And yet, when a Trusted Computing Group survey went out in December 2025, 91% of businesses said they had no formal roadmap to migrate to quantum-safe algorithms.^[1] A DigiCert study a few months earlier found that 69% of organizations recognize the quantum risk, and exactly 5% have actually deployed quantum-safe encryption.^[2]

That gap between “we know” and “we did something” is the whole story. This is not a piece about how lattice cryptography works. It is a checklist for the team that hasn't started, and the first item is the one everybody wants to skip. You can't migrate cryptography you can't see. So before you argue about which algorithm to pick, you have to find out where you use crypto at all. Almost nobody knows.

Why the clock actually started

For years the quantum threat lived in a comfortable place: real enough to put on a slide, distant enough to ignore. Two things moved it out of that place.

The first is the standards. On August 13, 2024, NIST published its first three finalized post-quantum standards.^[3] FIPS 203 is ML-KEM, derived from CRYSTALS-Kyber, for key encapsulation, which is how two parties agree on a shared secret. FIPS 204 is ML-DSA, from CRYSTALS-Dilithium, for digital signatures. FIPS 205 is SLH-DSA, from SPHINCS+, a hash-based signature backup. NIST later selected HQC, a code-based scheme, as a fifth backup KEM in March 2025, and a FALCON-based standard, FIPS 206, is still in development.^[4]The point is that the “we're waiting for the standard” excuse died in August 2024. The replacements have names, numbers, and reference code.

The second is the hardware target moving toward us. In May 2025, Google researcher Craig Gidney published a paper arguing RSA-2048 could be broken in under a week with fewer than 1 million noisy qubits.^[5] That is roughly a 20x reduction from his own 2019 estimate of about 20 million qubits, driven by cutting the required Toffoli-gate count by over 100x to around 6.5 billion. Nobody has a machine that does this today. But the engineering estimate for what such a machine needs is dropping faster than anyone forecast, and that direction is what matters when you are planning a multi-year migration.

Harvest now, decrypt later is why you can't wait for the machine

The instinct is to say: no quantum computer can break RSA today, so I'll migrate when one gets close. That reasoning has a hole in it, and the hole has a name. Harvest now, decrypt later.

An adversary doesn't need a quantum computer today to hurt you today. They need to capture your encrypted traffic today and store it. When a cryptographically relevant quantum computer eventually exists, they decrypt the archive.^[6]So the real question is not “when will the machine arrive.” It is “how long does this data need to stay secret.” If you move patient records, financial data, trade secrets, or anything with a secrecy lifetime that runs past the mid-2030s, and you send it over the wire in classically encrypted form right now, treat it as already exposed. The decryption is just deferred.

This is the argument that should reorder your priorities. It means the systems to migrate first are not the ones with the loudest compliance deadline. They are the ones carrying secrets with the longest shelf life. A session token that expires in an hour barely matters. A genomic database or a decade of legal discovery is bleeding right now, silently, and no alarm will ever fire.

The deadlines, in plain terms

On June 22, 2026, the federal timeline became concrete. Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” set December 31, 2030 as the deadline for federal agencies to move their most sensitive systems, High Value Assets and high-impact systems, to post-quantum key establishment, and December 31, 2031 for post-quantum digital signatures.^[7] It requires each agency head to name a PQC migration lead within 30 days, and it directs CISA and NIST to publish minimum-elements guidance for a Cryptographic Bill of Materials within 270 days.

Two days later, OMB issued Memorandum M-26-15, which turns those dates into a five-phase migration framework, requires agencies to submit comprehensive migration plans within roughly 120 days, and calls for automated cryptographic inventory and discovery tools plus integration of PQC into Zero Trust architectures. Running underneath all of it is NIST IR 8547, the transition roadmap, which deprecates RSA, ECDSA, ECDH, and DH (the roughly 112-bit-security algorithms like RSA-2048 and ECC P-256) by 2030, with full disallowance in federal systems by 2035.^[8]

The NSA's CNSA 2.0 suite adds a staggered schedule that hits different product classes at different times. Web browsers, servers, and cloud services should prefer CNSA 2.0 by 2025 and use it exclusively by 2033. Networking equipment like VPNs and routers should get there by 2030. Software and firmware signing should be exclusive by 2030. And starting January 1, 2027, new National Security System acquisitions must be CNSA 2.0-compliant by default.^[9] If you sell to the government, or to anyone who sells to the government, that last date is the one that quietly rewires your procurement.

The checklist starts with an inventory, and it will hurt

Here is the part I want to be blunt about. The reason 91% of companies have no roadmap is not that ML-KEM is hard to understand. It is that step one is unglamorous, tedious, and reveals how little anyone knows about their own systems. That step is the cryptographic inventory.

The government gave it a formal name to make it a deliverable: the Cryptographic Bill of Materials. A CBOM is an inventory of the cryptographic algorithms, protocols, and implementations inside a hardware or software product, deliberately analogous to an SBOM, the software bill of materials that supply-chain security already made familiar.^[7] The idea is simple and the execution is brutal: you can't protect, replace, or even reason about crypto you don't know you're running.

A real inventory has to find crypto in places nobody documents:

• TLS everywhere. Every certificate, every cipher suite, every internal service-to-service call. What key exchange is it negotiating? What signs the cert?
• Code and libraries. Hardcoded algorithm choices buried in application code, plus whatever OpenSSL, BoringSSL, or language runtime your dependencies pull in and configure for you.
• Keys and secrets. Signing keys, SSH keys, VPN tunnels, code-signing and firmware-signing pipelines, and the key management systems that hold them.
• Data at rest. Database encryption, disk encryption, backups, and archives, where the secrecy lifetime is longest and the harvest-now risk is highest.
• Third parties and hardware. SaaS vendors, payment processors, HSMs, IoT devices, and anything embedded that may not be upgradeable in the field at all.

Doing this by hand across a real environment is a losing game, which is exactly why M-26-15 calls for automated cryptographic discovery tools. Point them at your traffic, your code, and your certificate stores, and let them build the map. The output is not just a to-do list. It is a prioritization engine. Once you can see every place you use crypto, crossed against secrecy lifetime and the CNSA 2.0 dates, the migration order stops being a guess.

After the inventory: hybrid, and the server-side gap

The good news is that once you know what to change, the how is further along than you'd think, and the industry has already picked the pattern. It is hybrid. You combine a classical algorithm with a post-quantum one, so the connection stays at least as secure as the classical scheme even if the new one has an undiscovered flaw, and it becomes quantum-safe if the classical one falls.

The client side moved shockingly fast. Chrome enabled the X25519MLKEM768 hybrid by default on desktop in 2024 and on Android in November 2025. Firefox turned it on for desktop in November 2025. Apple started rolling it out with iOS 26 and macOS 26 in October 2025.^[10]The hybrid pairs X25519 with ML-KEM-768 and pushes the TLS key-share to about 1,568 bytes. The result: by late October 2025, over half of human-initiated TLS traffic to Cloudflare's network was already protected with hybrid post-quantum ML-KEM.^[11]

Now the bad news, and it is the number that should motivate you. Only about 3.7% of origin servers supported the X25519MLKEM768 hybrid, up from 0.5% in September 2023. So the browsers are ready, the traffic is flowing, and the servers, the part you actually control, are the bottleneck. Half of that post-quantum traffic terminates at Cloudflare's edge and then rides classical crypto the rest of the way to the origin. That last hop is your job. It is also the single most concrete, shippable thing on this list: turn on hybrid key agreement at your own servers and load balancers.

What this costs, and why it's not just software

The federal government estimated it will spend roughly $7.1 billion in 2024 dollars migrating civilian agencies to post-quantum cryptography between 2025 and 2035.^[12] That number came from OMB, ONCD, CISA, and NIST in the July 2024 White House report mandated by the 2022 Quantum Computing Cybersecurity Preparedness Act. The detail that should stick with you is where the money goes: much of it is replacing technology that cannot support PQC at all.

That is the real tax. A modern server gets a config change and a library update. But an HSM that can't do lattice math, an embedded device with no update path, a payment terminal certified against a fixed crypto profile, or a piece of industrial hardware with a fifteen-year service life, those don't get patched. They get replaced. Your inventory is also your capital-planning document, because it is where you find out how much of your crypto is welded into hardware you'll have to rip out.

The honest bottom line

I don't think the risk here is that a quantum computer breaks RSA next year and catches everyone flat-footed. The risk is more boring and more likely. The deadlines arrive, the ecosystem moves without you, and you discover in 2029 that you never built the inventory, so you have no idea what to fix, no idea what it costs, and no time to do it calmly.

The teams that will be fine are not the ones with the deepest cryptography expertise. They are the ones that started the unglamorous part early. Name an owner. Run a discovery tool. Build the CBOM. Sort by secrecy lifetime. Turn on hybrid key exchange at your own servers, since the browsers already did their half. None of that requires a breakthrough. It requires starting, which, going by the 91%, is the rarest thing in this whole field.