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](https://csrc.nist.gov/pubs/fips/203/final): 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](https://csrc.nist.gov/pubs/fips/204/final): 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](https://csrc.nist.gov/pubs/fips/205/final): 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.