NIST PQC Standards Explained: FIPS 203, 204, and 205 for Enterprise Teams

Quick answer: NIST finalized three post-quantum cryptography standards on August 13, 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for general-purpose digital signatures, and FIPS 205 (SLH-DSA) as a conservative, hash-based signature fallback. Most enterprise deployments default to ML-KEM-768 and ML-DSA-65 for civilian use, or ML-KEM-1024 and ML-DSA-87 for CNSA 2.0 environments, and reserve SLH-DSA for narrow cases where algorithm diversity matters more than performance.

Three standards published on the same day is not the same as three standards that solve the same problem. Enterprise teams keep asking which FIPS document actually applies to their TLS stack, their code-signing pipeline, or their certificate authority, and the honest answer is that FIPS 203, 204, and 205 were never meant to compete with each other. They cover different jobs, carry different performance profiles, and are at different points of implementation maturity across libraries, HSMs, and platforms in 2026.

This guide breaks down what each standard actually specifies, compares ML-KEM, ML-DSA, and SLH-DSA head to head, and maps each one to the use case, performance profile, and migration dependency that should drive the decision. For a faster, decision-focused version of this comparison and the most common selection mistakes, see our ML-KEM vs ML-DSA vs SLH-DSA decision guide.

Key Takeaways

• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) were finalized by NIST on August 13, 2024, closing an eight-year public evaluation process.
• ML-KEM solves key establishment; ML-DSA and SLH-DSA solve digital signatures. They are not interchangeable, and most systems need both a KEM and a signature algorithm.
• ML-DSA is the general-purpose signature default; SLH-DSA trades performance and size for a conservative, hash-based security assumption independent of lattice math.
• Parameter set choice depends on the deployment target: ML-KEM-768 and ML-DSA-65 for civilian systems, ML-KEM-1024 and ML-DSA-87 where CNSA 2.0 applies.
• Implementation maturity varies sharply by algorithm and platform in 2026, and that maturity gap, not algorithm preference, should drive sequencing.

What FIPS 203, 204, and 205 Actually Standardize

NIST’s post-quantum cryptography project began in 2016 with an open call for algorithm submissions and ran through several rounds of public cryptanalysis before NIST selected finalists in 2022. The Secretary of Commerce approved the resulting standards on August 13, 2024, effective the following day.

Standard	Algorithm	Based on	Function	Replaces
FIPS 203	ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)	CRYSTALS-Kyber	Key establishment	RSA and Diffie-Hellman key exchange, ECDH
FIPS 204	ML-DSA (Module-Lattice-Based Digital Signature Algorithm)	CRYSTALS-Dilithium	Digital signatures	RSA and ECDSA signatures
FIPS 205	SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)	SPHINCS+	Digital signatures	RSA and ECDSA signatures, as a conservative fallback

ML-KEM is a key encapsulation mechanism, the post-quantum equivalent of establishing a shared secret over an insecure channel, the job classical Diffie-Hellman and ECDH perform today. ML-DSA and SLH-DSA are both digital signature algorithms that prove a message, certificate, or software artifact came from a specific private key and was not altered, the job RSA and ECDSA perform today. A fourth standard, FN-DSA (FALCON), remained a draft as FIPS 206 through mid-2026, and NIST also selected HQC in 2025 as a structurally independent backup KEM to ML-KEM.

ML-KEM vs. ML-DSA vs. SLH-DSA at a Glance

The three algorithms differ in more than function. Key and signature sizes, the security assumption each rests on, and computational cost all shape where each one fits in a real deployment.

Property	ML-KEM (FIPS 203)	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Security basis	Module Learning With Errors (lattice)	Module Learning With Errors and Module Short Integer Solution (lattice)	Hash function security only, no lattice assumption
Parameter sets	ML-KEM-512, 768, 1024	ML-DSA-44, 65, 87	Multiple, e.g. SLH-DSA-128s/f, 192s/f, 256s/f
Civilian default	ML-KEM-768 (public key ~1,184 bytes, ciphertext ~1,088 bytes)	ML-DSA-65 (public key ~1,952 bytes, signature ~3,309 bytes)	Not a default; used selectively
CNSA 2.0 parameter	ML-KEM-1024 (public key ~1,568 bytes, ciphertext ~1,568 bytes)	ML-DSA-87 (public key ~2,592 bytes, signature ~4,627 bytes)	Not included in the CNSA 2.0 suite
Signature/ciphertext size vs. classical	Roughly 15 to 25 times larger than ECDH	Roughly 15 to 50 times larger than ECDSA	Roughly 100 to 700 times larger than ECDSA (7,856 to 49,856 bytes)
Relative speed	Fast; comparable to or faster than classical KEMs on modern hardware	Fast; suitable for high-volume signing	Slow; signing can take hundreds of milliseconds per operation
Best fit	TLS, VPN, and any key exchange	General-purpose signing: code, documents, certificates, protocols	Long-lived, low-volume signing where algorithm diversity matters most

The size gap matters operationally, not just academically. A four-certificate chain built on ML-DSA-87 carries roughly 15 to 20 times more signature data than the same chain on ECDSA P-384, which shows up as larger TLS handshakes, more OCSP response bytes, and higher HSM signing throughput requirements. SLH-DSA’s signatures run one to two orders of magnitude larger still, which is the direct trade-off for a security assumption that does not depend on lattice hardness holding up.

Choosing the Right Standard by Use Case

Most systems need a KEM and a signature algorithm working together, not a single choice between the three.

• TLS and VPN key exchange: ML-KEM is the direct fit. Hybrid constructions like X25519MLKEM768 pair it with a classical key exchange during the transition window.
• Code signing and firmware signing: ML-DSA is the practical default. Signed artifacts often need to remain verifiable for years, and ML-DSA’s performance profile supports the signing volume most build pipelines require.
• Certificate authority hierarchies: ML-DSA is the primary choice for issuing and root CAs, following the same parameter logic as code signing.
• High-assurance, low-volume, long-lived signatures: SLH-DSA fits where an organization wants a second, structurally independent signature scheme as insurance against a future weakness in lattice cryptography, accepting the size and speed cost in exchange.
• National Security Systems and the defense industrial base: ML-KEM-1024 and ML-DSA-87 are the required parameter sets under CNSA 2.0; SLH-DSA is not part of that suite.

Implementation Maturity in 2026

Standard status and deployment readiness are not the same thing. All three FIPS standards are final, but library, HSM, and platform support for each has matured at a different pace.

ML-KEM has the widest browser and TLS library support of the three, with hybrid key exchange already negotiable in current versions of major browsers and TLS stacks. ML-DSA support has reached mainstream enterprise PKI platforms, including general availability in Microsoft Active Directory Certificate Services on Windows Server 2025 as of the May 2026 update, though coverage varies by scenario: code signing is the most reliable path, while broader TLS, VPN, and Remote Desktop scenarios require workload-by-workload validation. SLH-DSA support exists in major cryptographic libraries but sees far less production deployment, reflecting its narrower, more specialized role. HSM firmware support for ML-KEM and ML-DSA is available on current-generation hardware from major vendors, while older HSM modules typically require a firmware update or hardware refresh before they can perform PQC operations.

Migration Dependency and Sequencing

None of these algorithms deploy in isolation, and the sequencing matters more than the algorithm choice.

1. Certificate authority hierarchies must migrate root-first. Issuing a leaf certificate on ML-DSA before the issuing CA and offline root are migrated breaks the chain of trust the migration was meant to establish.
2. HSM readiness gates signing throughput. ML-DSA and SLH-DSA both increase the computational and storage load per signing operation, and older HSM partitions need firmware validation before they can be trusted to keep pace in production.
3. Hybrid constructions buy time but add a second migration later. Composite or dual-stack designs that pair a classical algorithm with ML-KEM or ML-DSA protect against immature PQC implementations today, but they still need to shed the classical component before NIST’s proposed 2035 disallowance date for quantum-vulnerable public-key algorithms.
4. Discovery has to come first. An accurate inventory of where RSA, ECDSA, and ECDH are actually used today, mapped to owner and criticality, is the input every sequencing decision depends on.

What We’d Actually Recommend

For most enterprise teams outside National Security Systems, ML-KEM-768 for key exchange and ML-DSA-65 for signing is the right starting default: both sit at NIST’s Category 3 security level, both have solid library and platform support in 2026, and both keep certificate and handshake sizes closer to manageable than the highest parameter sets. Teams that expect to sell into NSS or the defense industrial base should design for ML-KEM-1024 and ML-DSA-87 from the start rather than retrofitting later, since CNSA 2.0 does not accept the civilian defaults. Reserve SLH-DSA for a narrow set of high-assurance signing use cases where a second, independent security assumption justifies the size and performance cost, not as a general-purpose default. Whichever combination a team lands on, the harder problem is rarely algorithm selection. It is knowing where classical algorithms are actually running today, which is why cryptographic discovery, not standard selection, is usually the first real blocker teams hit.

How Encryption Consulting Can Help

Choosing the right combination of ML-KEM, ML-DSA, and SLH-DSA is a decision that depends on an organization’s specific systems, regulatory obligations, and current cryptographic footprint, not a one-size-fits-all default. Our PQC Advisory Services work through exactly that decision with you: assessing which parameter sets fit each system category, sequencing the root-first CA migration path described above, and building a phased roadmap aligned to FIPS 203, 204, and 205 and, where applicable, CNSA 2.0 requirements.

That advisory work only holds up if it starts from an accurate picture of where classical algorithms actually run today. CBOM Secure builds and continuously maintains that inventory, mapping every RSA, ECDSA, and ECDH instance, along with the libraries and HSM partitions behind them, to the system owners who will need to act on the standard-selection decisions in this guide. It is the input every migration sequencing decision above depends on, and the reason algorithm selection so often stalls without it.

That inventory feeds two different execution paths, since ML-KEM and ML-DSA/SLH-DSA are managed through different infrastructure. HSM-as-a-Service carries the ML-KEM key establishment decision into production, FIPS-validated key management for TLS, VPN, and any key exchange workload. CodeSign Secure does the same for the ML-DSA and SLH-DSA signature decision, with HSM-backed signing for code, firmware, and long-lived artifacts. Where the signature decision applies to certificate issuance specifically, CertSecure Manager issues and manages ML-DSA and hybrid certificates across Microsoft AD CS and other CA platforms from a single policy plane.

Where This Leaves Enterprise Teams

FIPS 203, 204, and 205 answer three different engineering questions, not one. ML-KEM secures key exchange, ML-DSA carries the general-purpose signing load, and SLH-DSA sits in reserve for the narrow cases where a second, independent security assumption is worth its size and speed cost. The standards themselves are settled; what still varies by organization is parameter selection, implementation maturity on the specific platforms in use, and the sequencing required to migrate a PKI hierarchy safely. Teams that treat standard selection as the hard part often discover the real constraint is knowing where their classical cryptography lives in the first place.

Frequently Asked Questions

Are FIPS 203, 204, and 205 final standards or drafts?

All three are final. NIST’s Secretary of Commerce approved them on August 13, 2024, effective August 14, 2024. They are production-eligible standards, not drafts, unlike NIST IR 8547 or the draft FIPS 206 (FN-DSA), which remained in draft status through mid-2026.

Do I need all three standards, or can I pick just one?

Almost every system needs at least one KEM and one signature algorithm, so ML-KEM plus either ML-DSA or SLH-DSA is the realistic minimum. SLH-DSA is typically additive rather than a replacement for ML-DSA, used selectively where its independent security assumption is worth the performance cost.

Why does NIST have two signature standards instead of one?

Algorithm diversity is a deliberate hedge. ML-DSA and SLH-DSA rest on different mathematical assumptions, lattice problems versus hash function security, so a future weakness discovered in lattice cryptography would not compromise both at once. NIST maintains SLH-DSA specifically as that structurally independent fallback.

Which parameter sets should CNSA 2.0-regulated organizations use?

ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, both at NIST Category 5. CNSA 2.0 does not include SLH-DSA in its algorithm suite.

Does adopting these standards mean AES also needs to change?

No. FIPS 203, 204, and 205 address public-key cryptography, where Shor’s algorithm gives a quantum computer an exponential advantage. AES-256 is a symmetric algorithm and is already considered quantum-resistant at that key size, accounting for Grover’s algorithm.