Hash-based signatures are attractive because their security story is conservative. They depend on hash functions rather than lattice assumptions, and SLH-DSA is already standardised in FIPS 205. The challenge has always been practical: signatures can be large, and verification cost can be awkward for constrained or high-volume systems.
NIST’s April 2026 draft SP 800-230 addresses that tension. It proposes six additional SLH-DSA parameter sets for limited-signature use cases. They are tailored for workflows that need fast verification and smaller signatures, including software signing, firmware signing, and digital certificates.
The trade-off is a signing limit
The new parameter sets are not general-purpose replacements for standard SLH-DSA profiles. Their optimisation depends on a strict operational limit: no more than 2^24 signatures per signing key. NIST is explicit that users must evaluate whether they can ensure that limit is never exceeded during a key’s lifetime.
That turns a cryptographic choice into an operations problem. A limited-use key is only safe if the system can count, enforce, rotate, and audit usage. If signing is spread across build systems, HSM partitions, emergency release paths, and outsourced manufacturing lines, the signature budget must be a control, not a spreadsheet note.
Where limited-use profiles make sense
The natural fit is “sign once, verify many” infrastructure. Firmware images, boot components, operating-system packages, certificate authorities, and long-lived release artifacts can require enormous verification scale while producing comparatively few signatures. Smaller signatures and faster verification can help embedded devices, distribution networks, and certificate-heavy handshakes.
The weaker fit is anything that signs frequently, unpredictably, or across many uncontrolled issuers. Transaction signing, user-generated documents, high-volume API tokens, or distributed signing services may burn through a limited-use budget faster than governance can track. In those cases, ML-DSA or standard SLH-DSA profiles may be simpler to operate.
The evidence auditors will ask for
- Who owns the signing key and the rotation policy?
- Where is the counter enforced: application, HSM, CA, build system, or release pipeline?
- What happens when emergency signing bypasses normal tooling?
- Can the organisation prove the lifetime signature count after a merger, vendor change, or incident?
- Is there a safe rollover plan before the budget approaches exhaustion?
The draft is useful because it brings post-quantum signatures closer to real firmware and certificate workflows. It also raises the bar for operational discipline. Limited-use SLH-DSA can be a strong tool, but only where the signature budget is engineered as a hard control.
Further reading: NIST’s draft announcement and SP 800-230 initial public draft.