Post-Quantum Cryptography Explained: NIST's ML-KEM and ML-DSA Standards and Migration Deadlines
Post-quantum cryptography (PQC) is the set of public-key algorithms built to survive an attack by a large quantum computer. It runs on ordinary computers and ordinary chips. Nothing about it is quantum except the threat it is designed against. The reason anyone outside a cryptography department should care is simple: almost every secure connection you make today, from a bank login to a software update, depends on RSA or elliptic-curve cryptography (ECC), and both fall apart once a big enough quantum machine exists. The replacements are already standardized, governments have set deadlines, and a large share of web traffic has quietly switched over. This page covers the algorithms, the dates and who has moved, as of October 2026.
Why RSA and elliptic curves break
RSA is safe because factoring a 2048-bit number into its two primes takes classical computers longer than the age of the universe. ECC, which secures most TLS key exchange, Signal, WhatsApp and every Bitcoin wallet, is safe because recovering a private key from a public key (the elliptic curve discrete logarithm problem) is similarly hopeless on classical hardware.
In 1994 Peter Shor showed that a quantum computer could solve both problems in polynomial time. The Quantum Computing guide explains the mechanics; the short version is that Shor’s algorithm turns factoring and discrete logs into a period-finding problem that a quantum Fourier transform solves quickly. Key size doesn’t save you. Doubling RSA to 4096 bits only makes the quantum attack modestly more expensive.
The hardware gap is closing faster than many expected. In May 2025 Craig Gidney of Google estimated that RSA-2048 could be factored in under a week by a machine with fewer than one million noisy physical qubits, about a twentieth of his own 2019 estimate. On March 31, 2026, Google Quantum AI published estimates for 256-bit elliptic curves: roughly 1,200 to 1,450 logical qubits, fewer than 500,000 physical qubits, and a run time measured in minutes. No such machine exists yet. The point is that each new paper lowers the bar, and the Google researchers’ Bitcoin estimate is the latest step down.
Symmetric cryptography is in much better shape. Grover’s algorithm gives a quantum attacker a square-root speedup against AES and hash functions, which is why conservative guidance (including the NSA’s) simply uses AES-256 and SHA-384 or longer. No new symmetric algorithms are needed.
Harvest now, decrypt later
The reason migration started before any quantum computer can break anything is a tactic called harvest now, decrypt later. An adversary records encrypted traffic today, stores it, and decrypts it once the hardware arrives. Anything that must stay secret for ten or fifteen years (diplomatic cables, health records, merger documents, source code, intelligence sources) is already exposed if its key exchange used RSA or ECC.
This shapes the order of work. Key exchange had to move first, because a recorded handshake can be broken retroactively. Signatures were long considered less urgent, since a forged signature only matters while the signature is being checked. That view has shifted in 2026. Google and Cloudflare both now treat authentication as a near-term priority, partly because of the lower qubit estimates and partly because long-lived signing keys (root certificates, firmware signing keys, code-signing keys burned into devices) take years to replace.
The NIST standards: FIPS 203, 204 and 205
NIST ran an open competition from 2016. On August 13, 2024, it published the first three final standards:
| Standard | Algorithm | Based on | Job | Hard problem |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | CRYSTALS-Kyber | Key establishment | Module lattices |
| FIPS 204 | ML-DSA | CRYSTALS-Dilithium | Digital signatures | Module lattices |
| FIPS 205 | SLH-DSA | SPHINCS+ | Digital signatures | Hash functions only |
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) replaces Diffie-Hellman and ECDH. A KEM works slightly differently from a classic key exchange: one side publishes an encapsulation key, the other uses it to wrap a fresh random secret, and only the holder of the private key can unwrap it. It comes in three sizes, ML-KEM-512, 768 and 1024. ML-KEM-768 is the general default. It is fast, often faster than ECDH, but bigger: an ML-KEM-768 public key is 1,184 bytes and its ciphertext is 1,088 bytes, against 32 bytes each for X25519.
ML-DSA replaces RSA and ECDSA signatures. ML-DSA-44 signatures are 2,420 bytes, roughly 35 times the size of an ECDSA P-256 signature. That size is the main practical pain in TLS, where a certificate chain carries several signatures and public keys.
SLH-DSA is the conservative backup. Its security rests only on hash functions, which cryptographers understand very well, so it is the algorithm least likely to suffer a surprise break. The cost is large signatures (about 8 KB at the smallest standard parameter set) and slow signing. In April 2026 NIST released a draft, SP 800-230, adding SLH-DSA parameter sets for limited-use cases such as firmware signing where a key signs only a small number of messages.
What’s still in the pipeline: FN-DSA, HQC and more signatures
Three pieces of the NIST program were still open as of October 2026.
FN-DSA (FIPS 206) is the standardized form of Falcon, another lattice signature. Its draft went into NIST’s internal approval process on August 28, 2025, and the final standard was still pending at the time of writing. FN-DSA matters because its signatures are small: 666 bytes for FN-DSA-512, about a quarter the size of ML-DSA-44. The catch is implementation. Falcon’s signing step uses floating-point Gaussian sampling, which is hard to make constant-time and resistant to side-channel leaks. Several certificate authorities have said they won’t issue FN-DSA certificates until FIPS 206 is final.
HQC was selected on March 11, 2025, as a backup key-establishment algorithm. It is code-based (built on error-correcting codes) instead of lattice-based, so a breakthrough against lattices would not take it down along with ML-KEM. HQC is slower and larger than ML-KEM. NIST has said the final standard should arrive in 2027.
Additional signatures. Because ML-DSA and FN-DSA both depend on lattices, NIST opened a separate competition for signatures built on other math. On May 14, 2026, nine candidates moved to a third round. Expect no standard from this track for several years.
Supporting guidance is also arriving. SP 800-227, NIST’s recommendations for using KEMs safely, was finalized on September 18, 2025.
The migration deadlines
The dates below are the ones procurement teams and auditors plan against. Several are drafts; they are treated as binding in practice anyway.
| Who | Milestone | Date |
|---|---|---|
| NIST (IR 8547, draft) | RSA and ECC at 112-bit security (RSA-2048, P-256) deprecated | After 2030 |
| NIST (IR 8547, draft) | All quantum-vulnerable public-key algorithms disallowed | After 2035 |
| NSA (CNSA 2.0) | New National Security System acquisitions must be CNSA 2.0 compliant | January 1, 2027 |
| NSA (CNSA 2.0) | Software and firmware signing, networking equipment: exclusive use | 2030 |
| NSA (CNSA 2.0) | Web browsers, servers, cloud services, operating systems: exclusive use | 2033 |
| US (NSM-10) | All National Security Systems quantum-resistant | 2035 |
| EU (NIS Cooperation Group roadmap, June 2025) | National strategies and inventories begun | End of 2026 |
| EU | High-risk use cases migrated | 2030 |
| EU | Medium-risk use cases migrated | 2035 |
| UK (NCSC) | Discovery and migration plan complete | 2028 |
| UK (NCSC) | Highest-priority migration complete | 2031 |
| UK (NCSC) | Migration complete | 2035 |
NIST IR 8547 was released as an initial public draft on November 12, 2024, and was still a draft in October 2026. “Deprecated” means you may keep using an algorithm but shouldn’t pick it for new systems; “disallowed” means it no longer counts as approved under any circumstances.
CNSA 2.0, the NSA’s suite for classified and national security systems, is stricter than NIST. It picks only the largest parameter sets (ML-KEM-1024 and ML-DSA-87), adds the stateful hash-based signatures LMS and XMSS for firmware signing, and keeps AES-256 and SHA-384/512. It leaves out SLH-DSA.
Private companies have set earlier targets for themselves. Google announced on March 25, 2026, that it aims to finish its own migration by 2029, and said Android 17 would ship ML-DSA signature protection. Cloudflare followed on April 7, 2026, with a 2029 target that explicitly includes post-quantum authentication.
Hybrid key exchange: what’s already deployed
Most real deployments don’t trust ML-KEM alone yet. They use a hybrid: run classical X25519 and ML-KEM-768 side by side and combine both secrets. An attacker has to break both. If ML-KEM turns out to have a flaw, X25519 still protects today’s traffic; if a quantum computer arrives, ML-KEM still protects it. The TLS name for this pairing is X25519MLKEM768.
Deployment has gone further than most people realize:
- Chrome turned on a hybrid with pre-standard Kyber by default in Chrome 124 (April 2024), then switched to the standardized X25519MLKEM768 in Chrome 131 (November 2024).
- Cloudflare began offering hybrid key agreement in 2023. More than 65% of human traffic to its network was post-quantum encrypted by April 2026, up from 52% over 2025. Connections from Cloudflare to origin servers lag far behind; many origin servers still don’t support it.
- Apple shipped PQ3 for iMessage in iOS 17.4 (February 2024), adding Kyber to both the initial key setup and an ongoing rekeying ratchet. With iOS 26 and the matching macOS release, Apple turned on hybrid post-quantum TLS by default in URLSession and Network.framework, which covers Safari and many apps without code changes.
- Signal added PQXDH, a post-quantum initial handshake, in 2023. In October 2025 it added SPQR (Sparse Post-Quantum Ratchet), which brings ML-KEM into the ongoing ratchet so that a session heals with post-quantum keys after a compromise. Signal calls the combined design a triple ratchet.
- OpenSSL 3.5 (April 2025) ships ML-KEM, ML-DSA and SLH-DSA natively, which pulls post-quantum support into most Linux server stacks as distributions upgrade.
Signatures are the gap. Very few public websites serve post-quantum certificates, because a chain of ML-DSA certificates adds many kilobytes to every handshake. Cloudflare’s plan relies on Merkle Tree Certificates, a proposed design that cuts the number of signatures a browser has to receive. Expect this part of the web to change most over the next three years.
Bitcoin and other blockchains
Blockchains face the sharpest version of the problem. Bitcoin and Ethereum ownership rests on ECDSA (and Schnorr signatures for Taproot), and there is no central party to rotate keys for users. Once a quantum computer can derive a private key from a public key, any coin whose public key is visible on-chain can be stolen.
Not all coins are equally exposed. Standard Bitcoin addresses (P2PKH, P2WPKH) publish only a hash of the public key, and the key itself appears only when the coins are spent. The exposed pools are older pay-to-public-key (P2PK) outputs, which include many early-mined coins, plus any address that has been reused after spending. Google’s March 2026 analysis put about 1.7 million BTC in P2PK outputs and roughly 600,000 more exposed through reuse and similar patterns. Taproot outputs also reveal a key directly, which is a separate worry.
The main Bitcoin proposal, BIP-360, has been renamed several times (P2QRH, then P2TSH, now Pay-to-Merkle-Root, or P2MR). It defines an output type that disables Taproot’s key-path spend so no public key sits exposed. It is still a draft. It also only addresses exposure; actual post-quantum signatures for Bitcoin need a separate soft fork. The hardest question is political: what happens to coins whose owners never move them, including the early P2PK coins. Proposals range from leaving them alone to freezing them after a deadline, and none has consensus. There is no agreed timeline.
What to do with this
For most organizations the order is clear. Start with an inventory of where RSA and ECC are used, including the parts nobody thinks about: VPN concentrators, hardware security modules, embedded devices, code-signing pipelines, and long-lived certificates. Turn on hybrid TLS key exchange wherever your libraries support it, since that is nearly free and closes the harvest-now window for web traffic. Then plan the signature migration, which is slower, because it touches certificate authorities, firmware and hardware with ten-year lifespans. Building in crypto agility (the ability to swap algorithms without rewriting systems) is the one lesson every past migration, from DES to SHA-1, has taught.
Older ciphers show why this is worth doing early. The failure of book and running-key ciphers came from a mathematical shortcut that nobody using them had anticipated. Shor’s algorithm is the same kind of shortcut, except this time it was published thirty years before the hardware to run it.
The things to watch next: the final FIPS 206 for FN-DSA, the HQC draft, whether NIST IR 8547 is finalized with its 2030 and 2035 dates intact, and whether any quantum hardware milestone pulls the private-sector 2029 targets into regulation. For related reading, the cybersecurity glossary defines the surrounding terms, the explainer on passkeys covers a signature-based system that will itself need a post-quantum upgrade, and the guide to CVE, CVSS and CISA KEV covers how the more ordinary flaws get tracked in the meantime.