The NIST post-quantum standards, and what each one replaces
In August 2024 NIST published the first three finished post-quantum standards — FIPS 203, 204, and 205. Here is what each is for, what classical algorithm it replaces, and what is still coming.
The short version
NIST's post-quantum project produced three final standards on 13 August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for general-purpose signatures, and FIPS 205 (SLH-DSA) for conservative hash-based signatures. A fourth signature standard based on FALCON (FN-DSA) is still in draft, and a code-based backup KEM (HQC) was selected in 2025. Together these are what replace RSA and elliptic-curve cryptography.
The quantum threat is not uniform. Shor's algorithm breaks the asymmetric algorithms — RSA, Diffie-Hellman, and the elliptic-curve variants (ECDH, ECDSA) — that do key exchange and digital signatures across the internet. It does not break AES or SHA-2 in the same way. So NIST's replacement effort is aimed squarely at asymmetric crypto, and it splits into two jobs: establishing shared keys, and signing.
The three finished standards
- **FIPS 203 — ML-KEM** (Module-Lattice-Based Key-Encapsulation Mechanism), derived from CRYSTALS-Kyber. This replaces RSA and (EC)DH **key establishment** — the part of a TLS or VPN handshake that agrees on a session key. It is the priority migration because of harvest-now-decrypt-later. Parameter sets: ML-KEM-512, 768, and 1024.
- **FIPS 204 — ML-DSA** (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium. This is the **default replacement for RSA and ECDSA signatures** — certificates, code signing, tokens. Parameter sets: ML-DSA-44, 65, and 87.
- **FIPS 205 — SLH-DSA** (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+. A **conservative signature** option whose security rests only on hash functions, not on lattice assumptions. It has larger signatures and is slower, so it is used where a very high assurance margin matters more than size — for example firmware and root-of-trust signing.
What is still coming
Two more pieces are in flight. FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm), based on FALCON, is expected as a future FIPS: it produces much smaller signatures than ML-DSA, which suits bandwidth- or storage-constrained uses, at the cost of trickier constant-time implementation. Separately, in March 2025 NIST selected HQC — a code-based KEM built on different mathematics from the lattice-based ML-KEM — as a backup key-establishment mechanism, so that a future weakness in lattices would not leave the ecosystem without an alternative.
Pick ML-KEM and ML-DSA as your defaults
For nearly all systems the working default is ML-KEM for key establishment and ML-DSA for signatures. Reach for SLH-DSA only where you want hash-only assurance for long-lived signing keys, and treat FN-DSA and HQC as options to design for but not yet deploy in production.
Note the naming: the standardized algorithm names (ML-KEM, ML-DSA, SLH-DSA) are the NIST versions and are what you should specify in policy. The submission names (Kyber, Dilithium, SPHINCS+, FALCON) refer to the research schemes they were derived from and can differ in parameters — do not treat them as interchangeable in a compliance document.