- NIST finalized three post-quantum cryptography standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — on August 13, 2024, ending an eight-year selection process.
- NIST IR 8547 locks in a two-stage sunset: RSA-2048 and ECC P-256 deprecated by 2030, all quantum-vulnerable algorithms removed from NIST standards by 2035. NSA CNSA 2.0 mandates PQC for new national security systems starting 2027.
- Cloudflare crossed a 50% threshold in late October 2025, with over half of human-initiated web traffic already protected by X25519MLKEM768. Enterprise PQC migration takes two to five years — and the clock started yesterday.
The encrypted message you sent this morning may not stay encrypted for long. The NSA, GCHQ, and ANSSI have confirmed the threat, and post-quantum cryptography is the only defense that survives Q-Day.
This guide walks through the 2026 state of NIST post-quantum cryptography — the three finalized standards, the harvest-now-decrypt-later threat model, the 2030 and 2035 sunset deadlines, and what Cloudflare, Chrome, Apple, and Google have already shipped. It closes with a six-step enterprise migration playbook drawn from the CISA/NSA/NIST joint guidance. The question isn’t whether your systems migrate — it’s whether they migrate before today’s traffic loses its shelf life.
Q-Day Countdown: When a Quantum Computer Breaks RSA
Modern internet security rests on two mathematical problems — integer factorization (RSA) and the elliptic curve discrete logarithm (ECDH, ECDSA) — that classical computers cannot solve in reasonable time. Peter Shor’s 1994 algorithm changes the equation entirely. On a sufficiently large quantum computer, both problems collapse to polynomial time.
In plain English: the RSA-2048 key that would take thousands of years to brute-force today becomes a matter of hours or days post-Q-Day. The question is when “sufficiently large” arrives.
A 2025 MDPI analysis and multiple expert surveys put the window at 2029 to 2033. NIST’s own materials use a more conservative “within a decade” framing. Either estimate matters less than a second variable: enterprise cryptographic transitions typically take two to five years from start to finish.
That’s why 2026 is a migration year, not a planning year. Dustin Moody, the NIST mathematician who led the PQC standardization, put it bluntly at the August 2024 release: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”
The math of the race favors the attacker. Quantum capability is a research curve that compounds while migration is an operational project that doesn’t.
Starting late doesn’t just delay protection — it forfeits the window in which today’s data could have been sealed. That asymmetry is what makes 2026 feel urgent even to teams who see Q-Day a decade away.
NIST FIPS 203/204/205: The Three Post-Quantum Cryptography Standards
On August 13, 2024, NIST finalized three Federal Information Processing Standards after nearly a decade of public competition. Each standard plays a distinct role. Assuming one algorithm covers every use case is the first mistake most migration teams make.
FIPS 203 ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the renamed CRYSTALS-Kyber algorithm. It handles key exchange for TLS, IKE, SSH, and any protocol where two parties need to agree on a shared session key over a public channel.
NIST designated ML-KEM as the primary standard for general encryption. Parameter sets — ML-KEM-512, 768, and 1024 — let implementers dial in security levels, with ML-KEM-768 the common default.
FIPS 204 ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the renamed CRYSTALS-Dilithium. It’s the primary standard for digital signatures: certificate chains, code signing, document signatures, API token verification.
ML-DSA signatures run larger than RSA equivalents because lattice-based math carries heavier payloads. Verification speed remains competitive for real-world workloads, so the size trade-off rarely breaks latency budgets.
FIPS 205 SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is the renamed Sphincs+. Unlike ML-DSA, which relies on lattice assumptions, SLH-DSA is built on hash function security — a completely different mathematical foundation.
NIST deliberately kept it in the standards lineup as an insurance policy. If a structural flaw ever emerged in lattice cryptography, SLH-DSA would remain independently secure.
Three standards, three layers: ML-KEM for the keys that protect your sessions, ML-DSA for the signatures that prove who you are, and SLH-DSA as the mathematical seatbelt in case the first two ever fail. The right question isn’t “which do I pick?” — it’s “which of the three does each part of my stack need?”
Harvest Now, Decrypt Later: The Threat That Already Started
Q-Day arrives in the future. Harvest Now, Decrypt Later (HNDL) is already in progress. The strategy is straightforward: a nation-state actor captures encrypted traffic today, stores it indefinitely, and waits for the day a large enough quantum computer can retroactively decrypt anything sealed with RSA or ECDH.
Joint advisories from NSA, GCHQ, and ANSSI have made the warning explicit. Palo Alto Networks and recent State of Surveillance coverage point to China, Russia, and — in all likelihood — the NSA itself as actors running this playbook.
Cloudflare stated the premise with unusual clarity: “encrypted traffic can be harvested today, and decrypted after Q-day.” The prose is dry; the implication is not. Today’s wire data has a shelf life that extends well past today.
HNDL’s sharpest edge lands on data with long shelf lives. Medical records, genomic data, diplomatic cables, intellectual property, trade secrets, central bank swap line communications, long-term identity credentials — anything whose value persists for ten years or more.
Short-lived session cookies don’t need the same urgency, which is why rational migration plans start with data classification rather than brute-force cutovers. The prioritization question — which data is worth protecting against a decade-delayed attack — sets the whole project sequence.
The structural problem HNDL creates is a time asymmetry. The attacker pays a storage cost today and collects the payoff a decade later.
The defender has to protect today what will matter then. Plans that read “we’ll migrate when Q-Day gets closer” fail by design, because the data already moved through the wire before the migration happened.
The 2030/2035 Deadline: NIST IR 8547 and NSA CNSA 2.0
Until late 2024, the post-quantum transition had plenty of policy ambition and not much calendar. That changed with NIST IR 8547 (“Transition to Post-Quantum Cryptography Standards”), released as an initial public draft in November 2024.
IR 8547 locks in two hard dates. By 2030, all algorithms offering roughly 112 bits of classical security — RSA-2048, ECC P-256 — are deprecated. By 2035, any remaining use of quantum-vulnerable cryptography is disallowed in NIST standards entirely.
The national security track runs even tighter. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) roadmap mandates PQC compliance for new National Security System (NSS) acquisitions beginning in 2027.
Full transition across most NSS categories is targeted for the 2033–2035 window. Any global vendor selling into the US defense or intelligence supply chain effectively has a 2026–2027 readiness deadline.
Policy actions in 2026 reinforced the trajectory. CISA published a Product Categories for Technologies That Use Post-Quantum Cryptography Standards list in January 2026, giving federal procurement officers a concrete shopping guide.
Google announced on March 25, 2026 that its internal systems will complete PQC migration by 2029 — three years ahead of NIST’s 2035 floor. The joint CISA/NSA/NIST “Quantum-Readiness” guidance outlines the sequence: roadmap, inventory, supply-chain mapping, vendor engagement.
What makes the three timelines load-bearing is that each carries a different form of leverage. NIST IR 8547 removes algorithms from standards, CNSA 2.0 binds federal contracts, and the Google/Cloudflare self-imposed deadlines shape the de facto industry floor.
A private company may not sell to the federal government. But if it uses AWS, Cloudflare, or Google Cloud, it inherits at least two of those timelines indirectly.
Deployment Reality: Cloudflare, Chrome, and Apple in the Fast Lane
Standards and roadmaps are theory. Actual deployment on the public internet has accelerated faster than many enterprise security teams realize.
In late October 2025, Cloudflare crossed a 50% threshold — over half of human-initiated web traffic reaching its network was protected by X25519MLKEM768, a hybrid key agreement combining classical X25519 ECDH with ML-KEM-768. Cloudflare framed the milestone as “the new security baseline for the Internet.”
That’s marketing wrapped around a genuine shift. Running X25519 and ML-KEM-768 in parallel means an attacker has to break both to compromise a session — and combining a new algorithm with 20-year-tested X25519 is the rational move while ML-KEM is still early in real-world deployment.
Client-side adoption filled in across 2024 and 2025 in a coordinated wave. Chrome Desktop enabled PQC hybrid key agreement by default in March 2024, Chrome Android and Firefox Desktop followed in November 2024.
OpenSSL shipped in April 2025. Apple brought iOS, iPadOS, and macOS 26 onto the hybrid in October 2025. As of 2026, it’s harder to find a mainstream browser or OS without default PQC support than one with it.
The server side tells a different story. Cloudflare’s 2025 report found that 39% of public web servers advertised post-quantum TLS support as of September 2025, while origin servers sitting behind Cloudflare’s network showed X25519MLKEM768 support at just 3.7% — up from 0.5% in 2023.
The edge is already in the post-quantum era. The origins are not.
That gap — roughly 50% on the client, 3.7% at the origin — is the migration front for the next two to three years. Edge networks absorbed the initial wave because they control fewer code paths, while origin servers touch every back-end service and internal API. They move more slowly, and they move last.
The Six-Step Enterprise Migration Playbook
Enterprise PQC migration is difficult for a reason simple to state and painful to execute: cryptography isn’t a feature — it’s infrastructure. Algorithms live inside HSM firmware, TLS libraries, CA chains, VPN appliances, code signing pipelines, and authentication tokens.
That stack-wide scope explains the two-to-five-year migration window cited across NIST, CISA, and enterprise vendor guidance. Below are the six stages the joint CISA/NSA/NIST “Quantum-Readiness” document converges on.
Step 1 — Cryptographic Inventory. Build a map of every place cryptography is used inside the organization. Static code scanning, TLS handshake monitoring, certificate audits, and HSM key inventories are the tooling.
Without an inventory, migration is moving without a map. In practice this step is also the longest, because most organizations discover algorithms they didn’t know were running.
Step 2 — Prioritize by Risk. Rank systems by HNDL exposure and regulatory pressure — long-lived data, national security, finance, healthcare, and IP-sensitive domains move to the top of the queue.
Short-lived session data — ephemeral web cookies, one-hour JWTs — move to the bottom. “Everything at once” is the budget and schedule failure pattern.
Step 3 — Map the Supply Chain. Direct systems are only half the picture. HSM vendors, CA providers, SaaS dependencies, and silicon suppliers all run on their own PQC roadmaps.
Vendors without a credible PQC commitment by 2030 become replacement candidates. CISA emphasizes early vendor dialogue because vendor replacement commonly adds substantial time to the overall project, and starting that conversation late pushes transition dates out by months or years.
Step 4 — Deploy Hybrid at the Perimeter. Start with hybrid modes like X25519+ML-KEM at external boundaries: TLS endpoints, VPN concentrators, secure messaging. Hybrid is the canonical on-ramp because it layers two independent security assumptions.
If ML-KEM ever reveals a flaw, X25519 still protects the session. Cloudflare, Chrome, and Apple all chose this path for good reason.
Step 5 — Replace Internal Crypto Infrastructure. Move HSM firmware, internal CA chains, code signing pipelines, and long-term archival encryption onto ML-DSA and SLH-DSA. This step surfaces the hard engineering — key rotation at scale, certificate reissuance, and defense against protocol downgrade attacks that force fall-back to quantum-vulnerable ciphers.
Step 6 — Retire Legacy and Bake In Crypto-Agility. Systems still depending on RSA-2048 after 2030 aren’t technical debt — they’re regulatory liability.
The second-order lesson is cultural: architecture patterns that hard-code a single algorithm will force another painful transition next time. Crypto-agility — the design principle that cryptographic primitives are swappable rather than structural — is the insurance policy for whatever comes after PQC.
If you want a concrete view of how quantum hardware scaling translates into immediate crypto risk, the analysis in 200x Fewer Qubits: The Quantum Threat Is 9 Minutes Away walks through the Q-Day scenario in more depth. The steepness of that curve is exactly what determines whether a 2029 or 2033 estimate holds up.
The practical 2026 question isn’t when Q-Day arrives. It’s whether your organization has a cryptographic inventory.
Frequently Asked Questions
Q1. How is post-quantum cryptography different from RSA and ECC?
Post-quantum cryptography relies on mathematical problems that quantum computers cannot efficiently solve — lattice-based constructions for ML-KEM and ML-DSA, hash-based constructions for SLH-DSA. RSA, ECDH, and ECDSA all rest on integer factorization or elliptic curve discrete logarithms, both of which fall to Shor’s algorithm on a large enough quantum computer.
The APIs look similar on the surface. But key sizes, signature sizes, and performance profiles differ enough that drop-in replacement isn’t always possible.
Q2. When is “Q-Day” — the moment a quantum computer breaks RSA?
Most expert surveys converge on a 2029–2033 window, with NIST using a more conservative “within a decade” framing. The actual date depends on how fast quantum error correction and qubit scaling advance, which remains genuinely uncertain.
The more useful question is about harvest-now-decrypt-later. Because encrypted traffic is already being archived, today’s transmissions may be decrypted in a decade regardless of when Q-Day technically arrives.
Q3. What should ordinary users do right now?
Keep browsers (Chrome, Firefox) and operating systems (iOS 26, macOS 26) updated — when you connect to CDN-backed sites, X25519MLKEM768 hybrid key exchange negotiates automatically. As of October 2025, over 50% of human-initiated Cloudflare traffic already runs on hybrid PQC.
On the enterprise side, ask IT whether VPN clients, secure messengers, and HSM vendors have published PQC roadmaps. Vendors without a 2030 commitment become the highest-priority replacement candidates.
Q4. How do I choose between ML-KEM and ML-DSA?
They solve different problems. ML-KEM (FIPS 203) is for session key exchange in protocols like TLS and IKE, while ML-DSA (FIPS 204) handles digital signatures for code signing, certificates, and document authentication.
Most organizations need both. For signatures, ML-DSA is the default choice, with SLH-DSA (FIPS 205, hash-based) held in reserve as structural diversity against the remote possibility of a lattice break.
Q5. Why use a hybrid mode like X25519+ML-KEM?
Hybrid constructions run classical X25519 and post-quantum ML-KEM in parallel, so breaking the session requires defeating both. ML-KEM has NIST approval but limited real-world deployment hours, which means undiscovered implementation flaws remain a concern.
X25519 has 20 years of scrutiny but no quantum resistance. Combining them turns the security property into an AND condition, which is why Cloudflare, Chrome, and Apple all chose X25519MLKEM768 as the initial rollout.
Q6. How long does enterprise PQC migration actually take?
Two to five years is the consistent estimate across NIST, CISA, and vendor case studies. The timeline reflects the scope: HSM firmware, TLS libraries, CA certificate chains, VPN appliances, code signing pipelines, and authentication tokens all have to change in sequence.
NSA CNSA 2.0 starts mandating PQC for new National Security Systems in 2027 and targets full transition by 2033–2035. A 2026 start sits at the tight but achievable end of the curve.
Q7. Is blockchain — especially Bitcoin — safe from quantum computers?
Not fully. Bitcoin uses ECDSA on the P-256 curve, which Shor’s algorithm can break in principle, and addresses that have exposed public keys on-chain are particularly vulnerable to a future quantum attack.
The Ethereum Foundation and several other blockchain projects are researching PQC-based signatures like ML-DSA and SLH-DSA, but chain-level upgrades require careful coordination and user migration, typically measured in years. Under harvest-now-decrypt-later logic, existing on-chain transaction data may become exposed once Q-Day capabilities arrive.
200x Fewer Qubits: The Quantum Threat Is 9 Minutes Away
9-Minute Hack Looms: Circle’s Quantum-Proof Blockchain Arc
References
- NIST (2024-08-13) — Finalization of FIPS 203/204/205 and Dustin Moody quote urging immediate integration
- NIST CSRC FIPS 203 (2024-08-13) — ML-KEM (CRYSTALS-Kyber) module-lattice key encapsulation standard
- NIST CSRC FIPS 204 (2024-08-13) — ML-DSA (CRYSTALS-Dilithium) module-lattice digital signature standard
- NIST CSRC IR 8547 initial draft (2024-11) — 2030 deprecation of RSA-2048/ECC-256, 2035 full disallowance
- Cloudflare Blog (2025-10) — 50% X25519MLKEM768 milestone, browser and OS rollout timeline
- Security Boulevard (2026-03) — NSA CNSA 2.0 2027 NSS mandate and 2033–2035 full transition
- Palo Alto Networks Cyberpedia (2026) — HNDL threat model and NSA/GCHQ/ANSSI joint warnings
- Google Blog — The Keyword (2026-03) — Google’s 2029 PQC migration deadline announcement
- CISA (2026-01) — Federal procurement guidance: PQC-ready product categories
- MDPI Future Internet research (2025) — Q-Day 2029–2033 window estimate and HNDL time-asymmetry analysis
Stay Ahead of the Curve
Get the latest insights on AI, tech, and markets — delivered in both Korean and English.
Jugger | Backend Developer
A backend engineer working in enterprise solutions software since June 2021. The hands-on perspective from system design, API implementation, and production operations directly informs this site’s
AI, IT, and cloud infrastructure coverage.
For topics outside direct professional experience—blockchain and macroeconomics—analysis is built on primary-source citations such as SEC filings, whitepapers, institutional research, and government
statistics. Speculation is clearly separated from verified fact, and unverified claims are not published.
AI tools assist with drafting, but every article is reviewed, revised, and verified before publication. Errors are corrected with visible notes when discovered.
Contact: jjunggulee@gmail.com