SLH-DSA — formerly known as SPHINCS+, standardised by NIST as FIPS 205 — is the conservative signature scheme in the post-quantum portfolio. Conservative meaning: its security depends only on the properties of a hash function. No lattices. No discrete logs. No structured number theory that has decades of cryptanalytic history but still produces uncomfortable surprises. If a hash function holds, SLH-DSA holds.
That security simplicity is paid for in size. A SLH-DSA-128f signature is 17,088 bytes; a SLH-DSA-256f signature is 49,856. Compare that to ML-DSA-65 at 3,309 bytes or ECDSA P-256 at 64. That is the trade. Almost every decision about when to use SLH-DSA flows from one question: is the bandwidth tolerable here?
Where the trade is right
Three categories where SLH-DSA earns its cost cleanly:
1. Firmware signing for long-deployed hardware
A POS terminal deployed at an Indian merchant site is going to run the same firmware for 5–10 years before it gets refreshed. The signature on that firmware has to remain unbreakable for that whole period. If lattice-based signatures were ever cryptanalytically weakened, a firmware-signing root using ML-DSA would have to be rotated, which means re-issuing every signed firmware image in deployment. With SLH-DSA, the trust anchor's security tracks the hash function — and SHA-2 / SHA-3 have a much longer cryptanalytic track record than any lattice scheme.
The extra signature bytes don't matter here. Firmware images are typically megabytes; a 17 KB signature is rounding error.
2. Code signing for slow-moving software
The same logic applies to operating system update images, driver packages, and platform-level software bundles. The relying parties verifying these signatures are doing so as a step in a download that's already in the tens-to-hundreds of megabytes. The signature size is invisible. The security assumption simplification is operationally valuable.
3. Root and high-intermediate CAs
A 20-year root certificate signed with ML-DSA is a 20-year bet that lattice cryptanalysis won't advance to break ML-DSA. Reasonable bet, but a non-trivial one. A 20-year root signed with SLH-DSA is a 20-year bet that SHA-3 will continue to resist preimage attack. That bet has much more historical evidence behind it.
The root and high-intermediate CAs are signed once and read many times — but the reads are infrequent (only when the chain is being validated from scratch by a new relying party). So even though signature bytes accumulate over the lifetime of the cert, they accumulate slowly. SLH-DSA at the top of the hierarchy is the right call (see the PKI rotation piece).
Where the trade is wrong
Three categories where ML-DSA (or FN-DSA) is the right default, not SLH-DSA:
- TLS leaf certificates. Served on every handshake, multiple per page-load on a complex site. A 17 KB signature in this position would put 30+ KB of certificate chain on every TLS connection setup. Use ML-DSA-44 or FN-DSA-512.
- JWT and short-lived bearer tokens. Small payloads (typically a few hundred bytes) wrapping a signature. A 17 KB signature is 30× the payload. ML-DSA, or FN-DSA if signature size really matters.
- mTLS client certificates. Sent on every connection, often from constrained clients. Same argument.
SLH-DSA parameter sets, briefly
FIPS 205 defines six parameter sets crossed two ways. The first dimension is security level (NIST levels 1, 3, 5 corresponding to roughly AES-128, AES-192, AES-256 against classical attack). The second is the "s" / "f" choice: "s" for small signatures and slow verification; "f" for faster signing and verification with larger signatures.
For BFSI use:
- SLH-DSA-128s: a workable code-signing target for tools where signatures sit on disk and verification is occasional.
- SLH-DSA-128f: the practical default for most code/firmware signing where signing happens regularly.
- SLH-DSA-256f: NIST level 5 for roots and long-lived trust anchors where the conservative ceiling matters most.
What to migrate to SLH-DSA, in order
For an Indian bank running through the PQC programme, the SLH-DSA targets in priority order:
- Internal CA root. Once. Long validity. Cross-sign with the legacy root for trust continuity.
- Code-signing intermediate. Sign your internal software releases under an SLH-DSA-128f-signed intermediate.
- Firmware-signing intermediate. POS, ATM, IoT firmware chains.
- Document-signing high-assurance tier. Only if your regulatory category requires hash-based conservatism — most don't.
Everything else stays on ML-DSA (or FN-DSA where signature size dominates). The pattern, across the migration: SLH-DSA at the top of the hierarchy where it signs rarely and lives long; ML-DSA / FN-DSA at the bottom where it signs constantly and lives briefly.