LMS and XMSS are stateful hash-based signature schemes specified in NIST SP 800-208, published in October 2020. They rely only on hash functions, which makes them conservative. The catch is state: the signer must never reuse a one-time key index, so they suit controlled environments like firmware signing rather than general use.
What SP 800-208 covers
The recommendation specifies two stateful hash-based digital signature algorithms, LMS and XMSS, along with their multi-tree variants HSS and XMSS^MT. The final version is dated 29 October 2020, earlier than the three FIPS standards of 2024.
What stateful means
These schemes are built from many one-time signing keys. Each signature uses the next unused one, and the signer has to remember which ones are spent. Reusing one-time key material for two different messages can break the security of the scheme. That point is general knowledge about this family, not text from the NIST page I fetched, so read the full document for the exact requirements.
In practice that means:
- The private key is not just a secret, it is a counter that must advance durably.
- Restoring a backup, cloning a signing server, or a crash that loses the counter can cause reuse.
- Hardware security modules that manage state carefully are the usual answer.
How it compares
SLH-DSA (FIPS 205) is also hash-based but stateless, so it avoids the counter problem. NIST describes it as based on SPHINCS+. ML-DSA (FIPS 204) is lattice-based and stateless.
If your problem is tracking state, a stateless scheme removes the risk. If you control the signing environment tightly, a stateful scheme can still be a fit.
When it fits
- Firmware and boot image signing, where one controlled system signs a limited number of artifacts.
- Environments with an HSM and a strict, audited signing ceremony.
- Cases where you need quantum-resistant signatures sooner than general-purpose standards are deployed in your toolchain.
When to avoid it
- Many signing servers or signing in CI with no durable state control.
- Teams that cannot guarantee backups never restore old state.
- Anything where a signing key might be cloned or snapshotted by infrastructure.
Checklist before adopting
- Who can sign, and from how many machines?
- Where is the counter stored, and how is it protected from rollback?
- How many signatures will you need over the key's life?
- What is your recovery plan after a crash?
- Does your verifier support the scheme?
If you do adopt one, treat the signing system like a ledger. Keep an audit log of every signature issued and the index it used. Review it against the key's internal counter on a schedule. A mismatch is a red flag, and catching it early is far better than finding out after two different artifacts carry signatures from the same one-time key.
Quick check
Why is a stateful signature scheme risky?
Because reusing a one-time key index can compromise security, the signer must reliably track state. Backups and cloned servers are the common failure points.
Is SLH-DSA stateful too?
No. FIPS 205 specifies a stateless hash-based scheme.
Sources
Last reviewed: 19 October 2026.
