1. The exact problem this technology solves (real attack model)

SLH-DSA (FIPS 205, finalised August 2024) is the standardisation of SPHINCS+ — a stateless hash-based signature scheme. Its job is narrow but critical: produce signatures whose security rests only on the second-preimage and pseudorandomness properties of an underlying hash function (SHA-2 or SHAKE). No structured-lattice assumption, no algebraic problem, no number-theoretic hardness. If a future advance breaks ML-DSA (FIPS 204) — say, a non-trivial improvement on lattice sieving or a structural attack on Module-LWE — SLH-DSA still stands.

The threat model is concrete. Consider a firmware-signing key for a class of medical devices with a 15-year service life, or the root key of a national CA, or the offline signing key for a software supply chain (think kernel modules, EFI bootloaders, code-signing for an OS distribution). These artifacts must verify correctly in 2040. The signing key is used dozens of times per year, not millions; signature size and verification cost are second-order concerns. Cryptographic conservatism is the first-order concern.

The "harvest now, forge later" risk for signatures is different from KEMs. An attacker cannot retroactively forge a signature on yesterday's firmware — but they can forge a signature on tomorrow's malicious update if they break the algorithm before the trust anchor is rotated. For long-lived trust anchors that cannot be rotated cheaply (HSM-resident root keys, fused public keys in silicon, anchors burned into ROM), the migration window is the device lifetime, not the Q-Day horizon. SLH-DSA exists for exactly these assets.

2. The cryptographic primitive in technical detail

SLH-DSA is a stateless variant of the XMSS/LMS family. It composes three layers: a few-time signature scheme (FORS), a one-time signature scheme (WOTS+), and a hypertree of Merkle trees binding them together. Statelessness is achieved by pseudorandomly selecting a FORS instance from an enormous virtual set (2^63 to 2^64 leaves), with parameters chosen so the probability of a damaging collision over the device's signature budget is negligible.

FIPS 205 standardises twelve parameter sets across three security categories (NIST levels 1, 3, 5), two hash families (SHA-2, SHAKE), and two size/speed trade-offs (s small signatures, f fast signing):

SLH-DSA-SHA2-128s: 32-byte public key, 7,856-byte signature, ~level 1, slow signing
SLH-DSA-SHA2-128f: 32-byte public key, 17,088-byte signature, ~level 1, faster signing
SLH-DSA-SHA2-192s: 48-byte public key, 16,224-byte signature, ~level 3
SLH-DSA-SHA2-256s: 64-byte public key, 29,792-byte signature, ~level 5

The security target is EUF-CMA (existential unforgeability under chosen-message attack) in the random-oracle or quantum-random-oracle model, reduced to the second-preimage resistance of the hash function. Concretely, breaking SLH-DSA-SHA2-256s requires breaking SHA-256 in a way that costs less than 2^256 classical or 2^128 quantum operations. There is no algebraic structure to exploit — Grover gives the expected square-root speedup against the hash, and that is factored into the parameters.

The cost is signature size and signing time. SLH-DSA-SHA2-256s signing takes hundreds of milliseconds on a modern x86 core; signatures are ~30 KB. Verification is faster (single-digit milliseconds) but still expensive relative to Ed25519. For high-throughput TLS, this is unworkable. For a firmware blob signed once and verified once per boot, it is fine.

3. Reference implementations available in 2026

liboqs 0.12.x — Open Quantum Safe's reference. Production-grade SLH-DSA across all twelve parameter sets, AVX2-accelerated SHA-2 paths. The implementation we recommend for greenfield work.
OpenSSL 3.5+ with the oqs-provider — exposes SLH-DSA via the EVP signature API; works inside CMS and X.509 pipelines. Mainline OpenSSL 3.5 ships ML-DSA natively but defers SLH-DSA to the provider.
BoringSSL — has shipped ML-DSA and ML-KEM hybrid; SLH-DSA support remains experimental and gated, reflecting Google's view that ML-DSA is the default signing primitive and SLH-DSA is for niche long-lived-anchor use.
BIND 9.20+ — DNSSEC algorithm numbers for SLH-DSA are allocated; signing is functional but discouraged for zone signing because of signature size (a single RRSIG of 16 KB blows past UDP MTU). Useful for KSK only, where verification frequency is low.
OpenSSH 9.9 — ML-KEM hybrid for KEX is mainline. SLH-DSA host keys are not supported; the SSH community has chosen ML-DSA for signature use cases.
AWS KMS, GCP Cloud KMS, Azure Key Vault — all three offer ML-DSA in preview as of 2026. SLH-DSA is offered by AWS KMS only, in SLH-DSA-SHA2-128s form, marketed for code-signing and root-of-trust scenarios.

The signal here is clear: SLH-DSA is not a general-purpose signature replacement. It is a specialised tool for trust anchors and signed artifacts with multi-decade verifiability requirements.

4. Deployment pattern

Typical use: signing a firmware image or release artifact with an HSM-resident SLH-DSA key, embedding the public key as a trust anchor in the verifier. Example using OpenSSL 3.5 with oqs-provider:

# Generate an SLH-DSA-SHA2-192s keypair
openssl genpkey -provider oqsprovider -provider default \
    -algorithm sphincssha2192ssimple \
    -out firmware-signing.key

# Extract the public key (this becomes the trust anchor)
openssl pkey -provider oqsprovider -provider default \
    -in firmware-signing.key -pubout -out firmware-signing.pub

# Sign a firmware image
openssl dgst -provider oqsprovider -provider default \
    -sha256 -sign firmware-signing.key \
    -out firmware-v1.4.2.bin.sig firmware-v1.4.2.bin

# Verify (this is what the device does at boot)
openssl dgst -provider oqsprovider -provider default \
    -sha256 -verify firmware-signing.pub \
    -signature firmware-v1.4.2.bin.sig firmware-v1.4.2.bin

For X.509 CA roots, generate an SLH-DSA self-signed certificate and embed it in the verifier's trust store. Hybrid certificates (composite signatures combining Ed25519 and SLH-DSA via the draft-ietf-lamps-pq-composite-sigs scheme) are the migration bridge — verifiers that understand both algorithms validate both; legacy verifiers ignore the PQ component.

5. What goes wrong in production

Signature size breaks transport assumptions. A 30 KB signature in a TLS CertificateVerify exceeds the initial congestion window. DNS responses overflow UDP. CMS-signed email attachments balloon. Audit every protocol carrying the signature for size assumptions before deployment.
Signing latency. SLH-DSA-SHA2-256s on a Cavium HSM took 1.8 seconds per signature in our testing. CI/CD pipelines that signed thousands of artifacts in a release blew through SLAs. Either move to the f variants for higher-frequency signing, or batch-sign a Merkle root and use Ed25519 for per-artifact signatures under that anchor.
HSM firmware support is uneven. Vendors who advertise "PQ-ready" often mean ML-DSA only. Confirm SLH-DSA support at the parameter-set level — not all vendors implement 256s.
Composite-signature parsers. Hybrid X.509 with composite signatures hits parser bugs in older verifiers. Test the legacy verification path explicitly; do not assume "ignore unknown" works.
Entropy at signing time. SLH-DSA's stateless property depends on a strong PRF seed. On embedded signers without a hardware RNG, this is non-trivial. Use the deterministic mode (addrnd set to zero) if and only if you understand the attack surface.

6. How to test it works

Verify the algorithm OID in the certificate or signature blob:

# Inspect an SLH-DSA X.509 certificate
openssl x509 -provider oqsprovider -provider default \
    -in firmware-ca.crt -text -noout | grep -i "Signature Algorithm"
# Expected: sphincssha2192ssimple (OID

  Schedule a sovereign-cryptography assessment
  Book a security call →

SLH-DSA (FIPS 205) — SPHINCS+ stateless hash-based signatures for long-lived assets