Quick answer: ML-KEM solves key establishment; ML-DSA and SLH-DSA solve digital signatures. They are not competing options for the same job, so “which one should I use” is really two separate questions: what establishes your keys, and what signs your data. ML-DSA is the default signature answer for almost everyone; SLH-DSA is a narrow, deliberate exception. This guide is a decision framework and a list of the selection mistakes we see most often. For the full standards comparison and implementation maturity data, see our FIPS 203, 204, and 205 guide.
“ML-KEM vs ML-DSA” is one of the most common search queries in post-quantum planning, and it is also a slightly malformed question. The two algorithms do not compete for the same slot in a system the way, say, two TLS cipher suites might. One establishes a shared secret; the other proves who sent a message and that it was not altered. Most systems need both, at the same time, doing different jobs. The actual decision points are elsewhere: which parameter set, whether SLH-DSA earns a place alongside ML-DSA, and where each algorithm actually gets configured in a certificate chain.
Key Takeaways
- ML-KEM (FIPS 203) is a key encapsulation mechanism; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are digital signature algorithms. They solve different problems and are not interchangeable.
- ML-DSA is the practical default for signatures in almost every case: certificate authorities, code signing, TLS, and general-purpose authentication.
- SLH-DSA is a deliberate, narrow exception, chosen when a second, independent security assumption matters more than performance or size.
- The most common selection mistake is not an algorithm mistake at all: it is skipping migration sequencing and issuing leaf certificates on a new algorithm before the CA hierarchy behind them has migrated.
- CNSA 2.0 environments require ML-KEM-1024 and ML-DSA-87 specifically; the civilian defaults (ML-KEM-768, ML-DSA-65) do not satisfy that requirement.
The Question That Actually Matters: What Are You Protecting?
Before parameter sets or performance trade-offs, the decision starts with what the cryptography is doing.
- Protecting data in transit, or establishing a shared secret between two parties: that is ML-KEM’s job. TLS handshakes, VPN tunnels, any key exchange.
- Proving who sent something, or that it was not altered: that is a signature algorithm’s job, almost always ML-DSA. Certificates, code signing, firmware signing, protocol authentication.
- Wanting a second, independent signature scheme as insurance against a future weakness in lattice cryptography: that is the specific, narrow case for SLH-DSA, layered alongside ML-DSA rather than instead of it.
Most production systems need the first two running simultaneously: ML-KEM to establish the connection, ML-DSA to authenticate the certificates that made the connection trustworthy in the first place.
See how HSM-as-a-Service and CodeSign Secure cover the key exchange and signing decisions this guide walks through.
Common Selection Mistakes We See
These are the errors that show up repeatedly in PQC planning conversations, roughly in order of how often they cause real problems.
- Treating ML-KEM and ML-DSA as substitutes for each other: They are not competing options; a system almost always needs both, deployed for different purposes. Asking “should we use ML-KEM or ML-DSA” for a single use case is usually a sign the use case has not been broken down into its key exchange and signing components yet.
- Migrating leaf certificates before the CA hierarchy: Issuing an ML-DSA leaf certificate under an ECDSA-signed issuing CA does not create a working chain of trust. Migration has to move root-first, then issuing CA, then leaf, in that order.
- Defaulting to SLH-DSA because it “sounds more secure”: SLH-DSA’s hash-based security assumption is conservative, but its signatures run 100 to 700 times larger than ECDSA and its signing is measured in hundreds of milliseconds, not the low single digits ML-DSA achieves. It is a deliberate trade-off for a specific risk tolerance, not a generally stronger default.
- Using civilian parameter sets in a CNSA 2.0 environment: ML-KEM-768 and ML-DSA-65 are the right default for most enterprise systems, but CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87 specifically. Building against the wrong parameter set from the start means redoing the work later.
- Assuming HSM and platform support is uniform across all three algorithms: ML-KEM has the broadest browser and TLS library support today; ML-DSA support on enterprise PKI platforms varies by scenario, with code signing typically the most mature path; SLH-DSA sees comparatively little production deployment. Checking platform-specific maturity before committing to a rollout timeline avoids a schedule built on the wrong assumption.
Where Each Algorithm Actually Lives in a Certificate Chain
A common point of confusion: a TLS certificate chain uses both a KEM and a signature algorithm, but not in the way people expect.
- The certificate’s signature: root signs issuing CA, issuing CA signs leaf, using ML-DSA. This is what proves the certificate chain is authentic.
- The TLS key exchange itself: negotiated separately, using ML-KEM (typically in a hybrid construction like X25519MLKEM768 during the transition window). It is not encoded in the certificate’s signature at all.
- Code and firmware signing: uses ML-DSA directly on the artifact, following the same logic as certificate signing.
Put simply: the certificate proves identity using ML-DSA, and the connection it secures negotiates its shared secret using ML-KEM. Confusing the two, or assuming one certificate field configures both, is a frequent source of misconfiguration during early PQC rollouts.
Quick Reference
| Situation | Use |
|---|---|
| TLS, VPN, any key exchange | ML-KEM (768 civilian, 1024 CNSA 2.0) |
| Certificate authority signing, code signing, general authentication | ML-DSA (65 civilian, 87 CNSA 2.0) |
| High-assurance, low-volume, long-lived signing where algorithm diversity matters most | SLH-DSA, layered alongside ML-DSA |
| National Security Systems and defense industrial base | ML-KEM-1024 and ML-DSA-87 specifically; SLH-DSA is not part of the CNSA 2.0 suite |
For the full byte-level size comparison, security-basis breakdown, and implementation maturity detail behind these recommendations, see our complete FIPS 203, 204, and 205 standards guide.
What We’d Actually Recommend
Stop asking “ML-KEM or ML-DSA” as a single question and start asking it twice, once for key exchange and once for signing, for every system in scope. Default to ML-DSA for signatures and treat SLH-DSA as an opt-in decision that needs its own justification, not a fallback chosen out of caution. Confirm which parameter set your regulatory environment actually requires before implementation starts, since retrofitting CNSA 2.0 parameters into a civilian-parameter rollout is more expensive than building to the right target from day one.
How Encryption Consulting Can Help
The two-question framing this guide argues for maps directly to two different products. For the ML-KEM decision, key establishment, TLS, VPN, any key exchange, HSM-as-a-Service provides FIPS-validated key management at the right parameter set for your regulatory environment. For the ML-DSA or SLH-DSA decision, signing, certificates, code, firmware, CodeSign Secure and CertSecure Manager carry that choice into production, the latter specifically handling the root-first CA migration sequencing this guide flags as the most common real mistake.
Our PQC Advisory Services make the parameter and sequencing decisions this guide covers against an accurate picture of where your cryptography actually sits today, root-first CA migration, correct parameter sets by regulatory environment, and a rollout plan that accounts for platform-specific implementation maturity rather than a one-size timeline.
Two Questions, Not One
ML-KEM versus ML-DSA is not really a competition, and most of the selection mistakes teams make come from treating it like one. The real decisions are which parameter set applies to your regulatory environment, whether SLH-DSA earns a deliberate place in your signing strategy, and whether your migration sequencing respects the fact that a certificate chain has to move root-first. Get those three right, and algorithm selection stops being the hard part of a PQC migration.
Frequently Asked Questions
Can ML-KEM be used for digital signatures, or ML-DSA for key exchange?
No. ML-KEM is a key encapsulation mechanism and does not produce signatures. ML-DSA is a signature algorithm and does not perform key encapsulation. Unlike RSA, which historically could do both jobs, none of the current NIST post-quantum algorithms serve both functions.
Do I need to choose between ML-DSA and SLH-DSA for my certificates?
For most organizations, no choice is needed: ML-DSA is the default. SLH-DSA is typically additive, deployed alongside ML-DSA for a specific subset of high-assurance, long-lived signing use cases, rather than a general replacement.
What is the most common mistake in ML-KEM and ML-DSA rollouts?
Sequencing, not algorithm choice. Issuing leaf certificates on the new algorithm before the issuing CA and root have migrated breaks the chain of trust the migration was meant to establish. Root-first migration order matters more than which specific parameter set is chosen.
Is SLH-DSA more secure than ML-DSA?
Not in a way that makes it a better general default. SLH-DSA rests on a different, more conservative security assumption, hash function security rather than lattice hardness, which is valuable as a hedge, but it comes with substantially larger signatures and slower signing. It is a deliberate trade-off, not an upgrade.
Which parameter sets does CNSA 2.0 require?
ML-KEM-1024 for key establishment and ML-DSA-87 for signatures. The civilian defaults, ML-KEM-768 and ML-DSA-65, do not satisfy CNSA 2.0 requirements, and SLH-DSA is not part of the CNSA 2.0 algorithm suite at all.
