On September 21, 2026, NIST moves every remaining FIPS 140-2 cryptographic-module certificate to Historical status. Three months after that, on January 1, 2027, the NSA's CNSA 2.0 suite says all new National Security System acquisitions must be quantum-safe. Neither of those dates depends on anyone building a working quantum computer. They are administrative deadlines, already published, already counting down. That is what changed: the post-quantum conversation stopped being about physics and started being about procurement calendars.

The science settled first. For three decades the public-key cryptography holding the internet together (RSA, Diffie-Hellman, elliptic curve) leaned on math that classical machines cannot brute-force in any useful timeframe. A large enough quantum computer running Shor's algorithm collapses all of it at once. NIST turned that threat into an engineering program on August 13, 2024, when it published its first finished standards: FIPS 203 (ML-KEM, from CRYSTALS-Kyber), FIPS 204 (ML-DSA, from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, from SPHINCS+). These are production federal standards, not drafts. NIST has since picked HQC as a fifth algorithm, a key-encapsulation backup built on different math than the lattice-based ML-KEM, with its draft expected this year.

Why your data is already exposed

The reason to care before the hardware exists has a name: harvest now, decrypt later. Well-resourced adversaries are recording encrypted traffic and copying stored ciphertext today, on the bet that they can decrypt it once a cryptographically relevant quantum computer shows up. Anything with a long confidentiality lifespan is effectively compromised the day that machine arrives, even if that day is a decade out. Health records, financial data, government secrets, source code, signing keys: if it has to stay secret into the 2030s, treat it as if it leaked the moment it crossed the wire.

That reframes the math. You are not racing the quantum computer. You are racing the gap between today and the day your most sensitive data stops mattering. For a lot of regulated data, that gap is wider than any realistic migration timeline.

The deadlines are doing the work

Two sets of dates are pulling the whole industry forward, and they reinforce each other.

CNSA 2.0 sets the hard federal line. New National Security System acquisitions must comply by January 1, 2027. Operating systems should prefer the suite by 2027 and use it exclusively by 2033; network gear has to be exclusive by 2030. The suite mandates ML-KEM-1024 and ML-DSA at the top parameter sets, so there is no ambiguity about which knobs to turn. Alongside it, the FIPS 140-2 sunset in September 2026 pushes every buyer toward FIPS 140-3 validated, quantum-ready modules whether or not they touch government work, because the certified-module supply chain is shared.

The private sector is not waiting for any of this. Google has set an internal target around 2029 for its own systems, and a decision that size ripples through every certificate authority and TLS stack downstream of it. When a browser vendor moves, the rest of the web inherits the schedule.

What actually replaces what

The standards map cleanly onto the jobs RSA and ECC do today. ML-KEM (FIPS 203) takes over key exchange from RSA and ECDH. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) take over signatures from RSA and ECDSA, with the hash-based SLH-DSA preferred for long-lived firmware and code signing where you want conservative, well-understood security.

The pragmatic default for now is hybrid: pair a classical algorithm with a post-quantum one, X25519 plus ML-KEM being the common example, so a flaw in the newer and less battle-tested math cannot quietly weaken you mid-transition. You get quantum resistance without betting everything on cryptography that has had a fraction of RSA's years under attack.

Inventory is the hard part, not the algorithms

Here is the thing teams keep getting wrong. The algorithms are decided. The bottleneck is finding every place cryptography hides: libraries, appliances, HSMs, embedded devices, and third-party SaaS you do not control. NIST frames the whole effort as a multi-year, inventory-first program built around crypto-agility, the ability to swap algorithms without re-architecting the system around them.

The timelines are sobering when you set them against the deadlines. Roughly five to seven years for small organizations, eight to twelve for mid-sized, and twelve to fifteen for large enterprises. For the slow movers, the buffer is already gone.

So the work for 2026 is concrete. Build a cryptographic bill of materials before you choose a single replacement, because you cannot migrate what you cannot see. Sort the migration by data lifespan and put anything with a 10-plus year confidentiality requirement first, since that data is already at harvest-now risk. Make post-quantum roadmaps and FIPS 140-3 validation a written procurement requirement, because the 2026 and 2027 dates will show up in your supplier contracts whether you raise them or not. Then deploy hybrid TLS on internet-facing paths, where OpenSSL and BoringSSL support is most mature, and measure the handshake-size and latency cost in production rather than guessing.

The firms that start inventory and pilots this year are the ones that finish before RSA becomes a liability instead of a control. The rest will be reading these same dates off a contract, with a lot less time left.

Sources

  • https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/
  • https://www.digicert.com/blog/the-progress-toward-post-quantum-cryptography
  • https://utimaco.com/news/blog-posts/pqc-news-nist-announces-hqc-fifth-algorithm-be-standardized