ML-DSA (FIPS 204) is the lattice-based general-purpose signature standard. SLH-DSA (FIPS 205) is a stateless hash-based standard derived from SPHINCS+. Choose by what you value: ML-DSA for the common default, SLH-DSA where you want security that rests only on hash functions and can accept its tradeoffs.
What the standards say
Both were published on 13 August 2024. Each describes a signature scheme that detects unauthorized changes, authenticates the signer, and gives a recipient evidence to show a third party who signed.
NIST states that ML-DSA is believed to be secure even against adversaries with a large-scale quantum computer. SLH-DSA is described as stateless hash-based and based on SPHINCS+, a scheme chosen through NIST's post-quantum standardization process.
The real difference: foundations
ML-DSA depends on module lattice problems, the same family as ML-KEM. SLH-DSA depends on hash functions. If a serious attack on lattices appeared, ML-KEM and ML-DSA would be affected together, while SLH-DSA would not. That is the main reason to keep SLH-DSA in your plans.
I am not stating signature sizes or speeds here because the NIST pages I fetched do not list them. Read the standards and your library's benchmarks, and test with your real payloads.
Decision guide
Ask four questions:
- How long must a signature stay verifiable? Decades-long trust, such as a root of trust or firmware, argues for considering the hash-based option.
- How constrained is the verifier? Small devices, bandwidth limits and certificate chains make signature size and speed matter. Measure.
- How much of the ecosystem already supports it? Check your TLS stack, code signing tools and HSMs.
- Do you want diversity? Using two families across different trust anchors limits the blast radius.
Practical defaults
- General application signing, JWT replacements, internal services: start with ML-DSA where your libraries support it.
- Long-lived roots and firmware: evaluate SLH-DSA, and stateful schemes from SP 800-208 if you control signing tightly.
- Anything user-facing in browsers: follow what the browsers and certificate authorities actually support, since they set the pace.
Do not forget the hash
Choosing a new signature does not fix an old process. Check key custody, who can trigger signing, and whether your verifier rejects algorithm downgrade.
For a pilot, pick one internal signing use, such as a build artifact or an internal document flow, and run both algorithms in parallel for a few weeks. Record signature size, signing time, verification time and any tooling problems. A small real measurement from your own environment is worth more than any general comparison, and it gives you a defensible record of why you chose what you chose.
Quick check
Is SLH-DSA more secure than ML-DSA?
That is not the right frame. They rest on different assumptions. SLH-DSA depends only on hash functions, which some teams prefer as a hedge.
Can I sign with both?
Dual signatures, two signatures on one message, are discussed in NIST's draft transition report as a hybrid technique. They add complexity, so decide deliberately.
Sources
Last reviewed: 19 October 2026.
