| Standard | FIPS Number | Purpose | Original Submission Name |
|---|---|---|---|
| ML-KEM | FIPS 203 | Key encapsulation mechanism, replaces RSA and ECDH key exchange | CRYSTALS-Kyber |
| ML-DSA | FIPS 204 | Digital signatures, replaces ECDSA and RSA signatures | CRYSTALS-Dilithium |
| SLH-DSA | FIPS 205 | Hash-based digital signatures, conservative fallback | SPHINCS+ |
Why NIST Standardized Three Algorithms, Not One
NIST finalized FIPS 203, FIPS 204, and FIPS 205 on August 13, 2024, marking the conclusion of an eight-year public evaluation process that began in 2016. The decision to standardize three separate algorithms rather than a single universal replacement reflects a deliberate risk-management choice: ML-KEM and ML-DSA are both built on structured lattice mathematics, which is efficient and well-studied, but relying on a single mathematical foundation for every use case would be dangerous if a future cryptanalytic breakthrough weakened lattice-based assumptions. SLH-DSA exists specifically as a hedge, built on hash functions whose security properties rest on entirely different, more conservative assumptions than lattice problems.
ML-KEM (FIPS 203): Key Encapsulation
ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism, is the standard organizations will touch first in almost every migration, because key exchange happens at the start of nearly every secure connection. It provides IND-CCA2 secure key encapsulation, meaning it is designed to remain secure even against an adversary who can submit chosen ciphertexts for decryption, a strong and practically relevant security property. ML-KEM comes in three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with higher numbers trading performance for a larger security margin. ML-KEM-768 is the parameter set most commonly recommended for general-purpose use, roughly comparable in intended security strength to AES-192.
In practice, ML-KEM shows up first in hybrid TLS handshakes, where it runs alongside a classical key exchange like X25519 so that a connection remains secure even if one of the two algorithms is later broken. Our dedicated piece on post-quantum TLS covers exactly how that hybrid negotiation works in a real handshake.
ML-DSA (FIPS 204): Digital Signatures
ML-DSA, the Module-Lattice-Based Digital Signature Algorithm, is the direct replacement for ECDSA and RSA signatures across certificates, code signing, and authentication protocols. It provides EUF-CMA security, meaning it is designed to resist existential forgery even against an adversary who can request signatures on chosen messages. Like ML-KEM, it is built on structured lattice problems, specifically the Module Learning With Errors problem, which gives it strong performance characteristics relative to other post-quantum signature candidates.
ML-DSA is the standard most directly tied to certificate authority operations. Microsoft’s general availability release of ML-DSA support in Active Directory Certificate Services on Windows Server 2025 is a concrete sign that certificate infrastructure vendors are treating ML-DSA as the default signature algorithm for the next generation of PKI, ahead of SLH-DSA in most deployment plans due to its smaller signature sizes and faster verification.
SLH-DSA (FIPS 205): The Conservative Hash-Based Backup
SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm, began life as SPHINCS+ and takes an entirely different mathematical approach than the other two standards. Instead of relying on lattice problems, it builds its security guarantees on the properties of cryptographic hash functions, which have been studied for far longer and are generally considered to rest on more conservative, better-understood assumptions. The tradeoff is size and speed: SLH-DSA signatures are substantially larger than ML-DSA signatures, and signing operations are slower, which is why it is positioned as a fallback rather than a default.
Organizations typically reach for SLH-DSA in one of two situations: extremely high-assurance contexts where diversifying away from lattice-based mathematics entirely is worth the performance cost, or as insurance in systems designed to support algorithm agility, where SLH-DSA sits ready as a drop-in replacement if a future weakness is ever found in ML-DSA.
Figure: Where Each Standard Fits in a TLS Handshake
During connection setup, ML-KEM (FIPS 203) handles the key exchange step, typically paired with a classical algorithm in hybrid mode. The server’s certificate, and any code-signing operations tied to the deployed software, are validated using ML-DSA (FIPS 204) signatures. SLH-DSA (FIPS 205) sits alongside as an available fallback signature scheme for high-assurance certificate chains or root-of-trust anchors that specifically want hash-based diversification.
Performance and Sizing Comparison
| Property | ML-KEM-768 | ML-DSA-65 | SLH-DSA (128s) |
|---|---|---|---|
| Mathematical basis | Module lattice problems | Module lattice problems | Hash functions |
| Relative key or signature size | Small ciphertext overhead | Moderate signature size | Large signature size |
| Relative speed | Fast | Fast | Slower, especially signing |
| Primary use case | Key exchange in TLS, VPNs, SSH | Certificates, code signing, general authentication | High-assurance root-of-trust and long-term signature diversification |
| Security assumption independence | Shared with ML-DSA | Shared with ML-KEM | Independent of lattice assumptions |
How These Standards Fit Into a Migration Plan
Understanding what each standard actually does is a prerequisite for sequencing a real migration. Most organizations pilot ML-KEM first because key exchange is the most immediate harvest-now-decrypt-later exposure point, then move to ML-DSA as certificate infrastructure catches up, and only later evaluate whether SLH-DSA belongs in specific high-assurance corners of their estate. For the full ordered sequence, including inventory, vendor coordination, and cutover steps, see our post-quantum cryptography migration roadmap. None of this sequencing matters, though, if you do not first know where your existing classical algorithms live; that discovery work is covered in our guide to building a cryptographic bill of materials.
Common Misconceptions About the Standards
A frequent misunderstanding is treating ML-KEM and ML-DSA as interchangeable simply because they share a lattice-based foundation. They solve different problems: one establishes a shared secret between two parties, the other proves the authenticity and integrity of a message or certificate. You cannot substitute one for the other in a protocol. Another common misconception is assuming SLH-DSA is obsolete or a legacy option because it is slower; it was standardized specifically because its independence from lattice assumptions has ongoing strategic value, not because it failed to be a first choice.
Common mistake
Assuming that adopting ML-KEM for key exchange automatically covers your signature and certificate needs as well. Teams sometimes update TLS key exchange to use ML-KEM and consider their PQC work done, while their certificate chains, code-signing pipeline, and authentication tokens still rely entirely on classical ECDSA or RSA signatures, leaving a major gap that ML-DSA is specifically meant to close.
What worked
Running ML-KEM and ML-DSA pilots as two clearly separate workstreams with different owners, rather than one combined “post-quantum crypto” initiative. Because the two standards touch different systems, different teams, and different vendor dependencies, splitting ownership let each workstream move at its own realistic pace instead of one blocking the other.
Frequently Overlooked Details About the Standards
- Parameter set choice mattersML-KEM-512, 768, and 1024 offer different security-versus-performance tradeoffs; picking the wrong one for your context wastes either performance or security margin.
- Signature size affects protocol designML-DSA and especially SLH-DSA signatures are larger than ECDSA signatures, which can break assumptions baked into packet size limits or embedded device memory budgets.
- Stateless versus stateful hash signaturesSLH-DSA is stateless, meaning it does not require tracking which one-time keys have been used, unlike some earlier hash-based signature schemes that demanded careful state management to remain secure.
- Hybrid mode is a transition tool, not the end stateRunning classical and post-quantum algorithms together is meant to be temporary, with pure post-quantum modes as the eventual target once trust in the new standards is fully established.
- A fourth algorithm is still comingNIST continues to evaluate additional key encapsulation candidates from a separate track to further diversify the key exchange options beyond ML-KEM alone.
- Library support varies by ecosystemNot every programming language’s standard cryptography library has caught up to all three standards at the same pace, so verify support before committing to a rollout timeline.
Choosing Which Standard to Prioritize
For most organizations, the practical order is: enable hybrid ML-KEM key exchange in TLS and VPN infrastructure first, since it addresses the most urgent harvest-now-decrypt-later risk with the least disruption to existing certificate hierarchies. Move to ML-DSA for certificate authorities and code-signing pipelines next, coordinating with vendors who are still rolling out support, and confirm that any hardware security modules in your key management chain can actually generate and store the new key types before committing to a rollout date. Reserve SLH-DSA evaluation for specific high-assurance systems, such as root certificate authorities or firmware signing roots, where the independent security assumption is worth the performance tradeoff. Whichever order you choose, wrap the rollout in a crypto-agility layer so the next algorithm transition does not require repeating this same standard-by-standard analysis from scratch.
- Key encapsulation mechanism (KEM)
- A cryptographic method for two parties to establish a shared secret key over an insecure channel, the modern replacement for traditional key exchange.
- Module Learning With Errors (Module-LWE)
- The structured lattice mathematical problem underlying both ML-KEM and ML-DSA, believed to be hard even for quantum computers to solve.
- IND-CCA2 security
- A formal security property meaning a scheme remains secure even against an adversary who can request decryptions of chosen ciphertexts.
- EUF-CMA security
- A formal security property for signature schemes meaning an adversary cannot forge a valid signature even after seeing signatures on messages of their choosing.
- Stateless hash-based signature
- A signature scheme built from hash functions that does not require tracking previously used keys to remain secure, unlike earlier stateful hash-based designs.
Key Takeaways
- NIST finalized three post-quantum standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
- ML-KEM handles key encapsulation and is typically the first standard organizations deploy, often in hybrid mode.
- ML-DSA replaces ECDSA and RSA for certificates, code signing, and general-purpose digital signatures.
- SLH-DSA is a conservative, hash-based signature fallback with security assumptions independent of lattice mathematics.
- ML-KEM and ML-DSA share a lattice-based foundation but are not interchangeable; they solve different problems.
- Larger signature and key sizes in all three standards can affect protocol and embedded-device design decisions.
- A practical rollout order is ML-KEM first, ML-DSA second, and SLH-DSA reserved for specific high-assurance use cases.
FAQs
What does ML-KEM stand for and what does it do?
ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism, standardized as FIPS 203. It allows two parties to establish a shared secret key over an insecure channel and is designed as a direct replacement for RSA and ECDH key exchange.
What is the difference between ML-KEM and ML-DSA?
ML-KEM handles key encapsulation, establishing a shared secret between two parties, while ML-DSA handles digital signatures, proving the authenticity of a message or certificate. They solve different cryptographic problems and are not interchangeable despite sharing a lattice-based mathematical foundation.
Why did NIST standardize SLH-DSA alongside two lattice-based algorithms?
SLH-DSA is built on hash functions rather than lattice mathematics, giving it independent security assumptions. NIST included it as a conservative backup in case a future cryptanalytic breakthrough ever weakens confidence in lattice-based problems underlying ML-KEM and ML-DSA.
What were the original names of these algorithms before standardization?
ML-KEM was originally submitted as CRYSTALS-Kyber, ML-DSA was originally submitted as CRYSTALS-Dilithium, and SLH-DSA began as SPHINCS+, all renamed during NIST’s finalization process into their current FIPS designations.
Which standard should an organization deploy first?
Most organizations deploy ML-KEM first, typically in hybrid mode alongside a classical algorithm in TLS or VPN key exchange, since key exchange carries the most immediate harvest-now-decrypt-later exposure, followed by ML-DSA for certificates and code signing.
Why are post-quantum signatures and keys larger than classical ones?
The underlying mathematical structures, whether lattice-based or hash-based, require more data to achieve equivalent security margins than compact elliptic-curve mathematics, resulting in larger ciphertexts and signatures that can affect packet sizes and device memory budgets.
Is SLH-DSA considered a legacy or lesser standard compared to ML-DSA?
No. SLH-DSA is slower and produces larger signatures, but it was standardized deliberately for its independent, conservative security assumptions, making it a strategic choice for high-assurance systems rather than an outdated option.
When were FIPS 203, 204, and 205 officially finalized?
NIST finalized and released FIPS 203, FIPS 204, and FIPS 205 on August 13, 2024, concluding a multi-year public evaluation and standardization process that began in 2016.
References
- NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards”
- Federal Register, “Announcing Issuance of Federal Information Processing Standards FIPS 203, 204, and 205”
- DigiCert, “An In-Depth Look At The NIST PQC Algorithms”
- Cloud Security Alliance, “NIST FIPS 203, 204 and 205 Finalized: An Important Step Towards a Quantum-Safe Future”
- QRAMM, “NIST Post-Quantum Cryptography Standards: Complete Guide to FIPS 203, 204, 205”
- wolfSSL, “What are FIPS 203, 204, and 205?”
