NIST SP 800-208
NIST SP 800-208 is the NIST recommendation, published in October 2020, that approves four stateful hash-based signature schemes, LMS, HSS, XMSS, and XMSS^MT, for U.S. federal use, and it did so roughly four years before NIST finalized the main lattice-based post-quantum standards. Its full title is “Recommendation for Stateful Hash-Based Signature Schemes,” and it exists because these hash-based schemes rest on the oldest and most trusted assumption in cryptography, so they were mature enough to standardize early for a narrow set of jobs like firmware and software signing.
The catch that governs the whole document is statefulness: each signing key can produce only a fixed number of signatures and the signer must never reuse a one-time key, so SP 800-208 requires key generation and signing to happen inside validated hardware modules that cannot export or duplicate the private key.
The short version:
- SP 800-208 is a NIST Special Publication (not a FIPS) that approves the stateful hash-based signature schemes LMS, HSS, XMSS, and XMSS^MT for federal use.
- It was published in October 2020, which makes it the first standardized post-quantum signature guidance NIST issued, ahead of ML-DSA and SLH-DSA (both finalized in August 2024).
- It approves those schemes with four hash functions only, SHA-256, SHA-256/192, SHAKE256/256, and SHAKE256/192, and it explicitly excludes some parameter sets from the source RFCs.
- Because these schemes are stateful, SP 800-208 requires key and signature generation inside a FIPS 140 Level 3 (or higher) hardware module that never exports the private key. A software-only deployment is out of compliance.
- Its intended home is firmware and software signing, roots of trust, and other low-volume, long-lived signing, which is exactly where CNSA 2.0 points to it. The deep hazard of the statefulness itself lives in the stateful hash-based signatures note.
Think of SP 800-208 as the rulebook that certifies a particular kind of numbered, single-use seal for official documents. The seals themselves are trustworthy in a way nothing else is, because their security comes from the simplest lock in the shop. But a single-use seal is only safe if no one ever presses the same number twice, so the rulebook does something unusual: it says these seals may only be made and pressed inside a locked, tamper-evident vault whose machinery physically cannot hand out a duplicate. The document isn’t really about the cryptography, which is settled. It’s about the operational discipline that keeps a single-use scheme from being used twice.
What is NIST SP 800-208?
NIST SP 800-208 is a NIST Special Publication that recommends and specifies the approved parameter sets for stateful hash-based signature schemes in federal systems. It was authored by David A. Cooper, Daniel C. Apon, Quynh H. Dang, Michael S. Davidson, Morris J. Dworkin, and Carl A. Miller, runs 59 pages, and carries the title “Recommendation for Stateful Hash-Based Signature Schemes.” It sits in the Special Publication 800 series (NIST’s computer-security guidance line), which is a different instrument from a Federal Information Processing Standard like FIPS 203 or FIPS 204. A FIPS is a mandatory standard; an SP is a recommendation, though in practice a “shall”-laden SP like this one functions as a binding spec for anyone claiming conformance.
The document does three things. It names which schemes are approved, it pins down the exact parameter sets and hash functions allowed for each, and it imposes the conformance rules (the hardware requirement and the state-management mandate) that make a stateful scheme safe to run. It draws its underlying algorithm definitions from two existing IETF specifications rather than inventing new ones, then tightens and restricts them for federal use.
Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, NIST SP 800-208.
What schemes does SP 800-208 approve?
SP 800-208 approves two closely related families of hash-based signatures, each with a single-tree form and a multi-tree form, and it grounds each in an existing IETF RFC:
| Scheme | Full name | Structure | Underlying spec |
|---|---|---|---|
| LMS | Leighton-Micali Signature | Single hash tree | RFC 8554 |
| HSS | Hierarchical Signature System | Multi-tree LMS (LMS trees signing lower LMS trees) | RFC 8554 |
| XMSS | eXtended Merkle Signature Scheme | Single hash tree | RFC 8391 |
| XMSS^MT | Multi-tree XMSS | Multi-tree XMSS (stacked XMSS trees) | RFC 8391 |
The two families do the same job with different internal building blocks. LMS and HSS build their one-time signatures from LM-OTS; XMSS and XMSS^MT build theirs from WOTS+. The multi-tree variants (HSS and XMSS^MT) exist so a signer can reach very large signing capacities by chaining trees, where a top tree’s keys sign the roots of lower trees and only the bottom trees sign real messages. All four are pure hash constructions, which is why Shor’s algorithm finds no algebraic structure to attack. The full mechanism of how these trees produce and verify a signature lives in the stateful hash-based signatures note; SP 800-208 is the document that blesses them and sets their federal parameters.
Sources: R. Housley, “Leighton-Micali Hash-Based Signatures,” RFC 8554, April 2019, RFC 8554.
A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen, “XMSS, eXtended Merkle Signature Scheme,” RFC 8391, May 2018, RFC 8391.
Why did NIST publish SP 800-208 before the main PQC standards?
NIST published SP 800-208 in 2020, ahead of the lattice-based winners of its main competition, because hash-based signatures rest on an assumption the field already trusted completely and didn’t need years of new scrutiny to accept. A hash-based scheme’s security reduces to the collision and preimage resistance of its hash function, which is the most heavily studied primitive in all of cryptography. There was no new hard problem to age. So NIST could move these schemes to standardization on a faster track than ML-KEM and ML-DSA, whose lattice assumptions were younger and needed the full competition to build confidence.
The timing was also practical. Some organizations, especially those signing firmware and boot code that has to stay verifiable for a decade or more, needed an approved quantum-safe signing option before the main standards were ready. SP 800-208 gave them one. The reason it wasn’t simply made the general-purpose default is the statefulness, which carries an operational burden most everyday signing systems can’t safely absorb. So NIST scoped it narrowly, standardized it early, and left the broad signature default to the later lattice standards.
Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, §1.1, October 2020, NIST SP 800-208.
What hash functions and parameters does SP 800-208 approve?
SP 800-208 approves LMS, HSS, XMSS, and XMSS^MT with exactly four hash functions, and it deliberately restricts the parameter sets to a subset of what the source RFCs define. The approved hash functions are the same across both families:
| Approved hash function | Digest bits | Where the parameter sets are defined |
|---|---|---|
| SHA-256 | 256 | RFC 8554 (LMS), RFC 8391 (XMSS) |
| SHA-256/192 | 192 | SP 800-208 §4 and §5 |
| SHAKE256/256 | 256 | SP 800-208 §4 and §5 |
| SHAKE256/192 | 192 | SP 800-208 §4 and §5 |
For LMS, the height of the signing tree (h) is set at key generation and must be one of 5, 10, 15, 20, or 25, which is what fixes how many signatures the key can ever make. XMSS uses its own approved tree heights, and the multi-tree HSS and XMSS^MT variants stack trees to reach far higher capacities. One restriction is worth flagging because it trips people up: SP 800-208 explicitly does not approve the XMSS parameter sets from RFC 8391 that use SHAKE128, SHAKE256 (in the RFC’s original form), or SHA-512. Federal conformance means using the four approved hash functions above and nothing else.
Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, §4, §5, and Footnote 5, October 2020, NIST SP 800-208.
Why does SP 800-208 require signing in hardware?
SP 800-208 requires key generation and signature generation to happen inside a validated hardware cryptographic module because that is the only reliable way to guarantee a one-time key is never used twice, and one reused key is a total break of the scheme. The document’s §8.1 conformance language is unusually strict for a signature standard. It requires all of the following:
- Hardware modules only. Key generation and signing must be validated for use within hardware cryptographic modules; a software implementation cannot conform.
- FIPS 140 Level 3 or higher. The module must provide FIPS 140-2 or FIPS 140-3 Level 3 or higher physical security, with a non-modifiable or limited operational environment.
- No private-key export. The module must not allow the private keying material to be exported, which structurally blocks the “make a backup copy of the key” mistake.
- State written before the signature leaves. Before releasing a signature, the module must increment the leaf index (q in LMS, idx in XMSS) and store the new value in nonvolatile storage, so a crash or power loss can’t roll the counter backward.
- Never reuse a one-time key. The single most consequential sentence in the document says the module shall not use a one-time-signature key to generate a signature more than once.
The reason for all of this is that the failure mode is catastrophic rather than gradual. Signing two different messages with the same one-time key exposes enough of the secret structure to let an attacker forge signatures on messages of their choosing. The hardware boundary makes the ordinary IT operations that would duplicate state (restoring a backup, cloning a VM, copying a key for redundancy) physically impossible for the signing key. That deeper hazard, and why routine operations are the real danger, is covered in full in the stateful hash-based signatures note.
Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, §8.1, October 2020, NIST SP 800-208.
What is SP 800-208 used for?
SP 800-208 is aimed at low-volume, long-lived, tightly controlled signing, and firmware and software signing is the flagship case. The profile that fits it well has three features together: the signing volume is low and predictable (so the finite per-key capacity is comfortable), the signatures must stay verifiable for many years or decades (so the maximum-confidence hash foundation earns its cost), and the signing lives in a controlled authority that can host a hardware module (so the state discipline is real rather than aspirational). Secure-boot roots of trust, firmware update signing, and offline code-signing authorities all match that shape.
It’s a poor fit for the opposite profile: high-volume, latency-sensitive, horizontally scaled signing where many nodes share a key and coordinating state across them is fragile. General-purpose surfaces like TLS certificate signing fall in that camp, and the lattice signature ML-DSA is the better default there. When an organization wants the conservative hash-based security without the state-management burden at all, the stateless SLH-DSA is the option to reach for instead. None of these schemes do key establishment, which stays the job of ML-KEM.
How does SP 800-208 relate to FIPS 205 and CNSA 2.0?
SP 800-208 and FIPS 205 are the two halves of NIST’s hash-based signature offering, split by whether the scheme is stateful. SP 800-208 covers the stateful schemes (LMS, HSS, XMSS, XMSS^MT), which are compact but demand hardware state management. FIPS 205 covers the stateless SLH-DSA, which removes the state footgun entirely at the cost of much larger signatures. Both are current standards for different jobs, and neither replaces the other.
CNSA 2.0 is where SP 800-208 gets its concrete marching orders for national security systems. CNSA 2.0 names LMS and XMSS specifically for signing software and firmware, recommends LMS with SHA-256/192, and reminds implementers that these schemes only stay secure if they meet all of SP 800-208, including the state management and the hardware signing. So SP 800-208 is the technical spec, and CNSA 2.0 is the policy that points to it and scopes its use.
| Document | What it is | Scheme type | Role |
|---|---|---|---|
| SP 800-208 | NIST Special Publication (2020) | Stateful hash-based (LMS, HSS, XMSS, XMSS^MT) | Approves the schemes and sets federal parameters |
| FIPS 205 | Federal Information Processing Standard (2024) | Stateless hash-based (SLH-DSA) | Standardizes the stateless alternative |
| CNSA 2.0 | NSA policy suite (2022) | Points to SP 800-208 | Requires LMS/XMSS for NSS software and firmware signing |
Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022, CNSA 2.0.
Common misconceptions
- “SP 800-208 is a FIPS.” It’s a NIST Special Publication, not a Federal Information Processing Standard. That distinction matters because it’s a recommendation rather than a mandatory standard, though its “shall” conformance language makes it binding for anyone claiming compliance.
- “SP 800-208 was replaced by FIPS 205.” Both are current NIST standards for different jobs. FIPS 205 standardizes the stateless SLH-DSA; SP 800-208 keeps the stateful schemes in the toolkit precisely because they’re far more compact, which is what firmware signing wants when a signer can manage state safely.
- “You can run SP 800-208 schemes in software.” The document requires key generation and signing inside a FIPS 140 Level 3 (or higher) hardware module that never exports the private key. A software-only LMS or XMSS deployment is out of compliance with the standard.
- “SP 800-208 approves everything in RFC 8554 and RFC 8391.” It approves a restricted subset. Only four hash functions are allowed (SHA-256, SHA-256/192, SHAKE256/256, SHAKE256/192), and some RFC 8391 parameter sets (SHAKE128, SHAKE256, SHA-512) are explicitly not approved.
- “These schemes can also handle encryption or key exchange.” SP 800-208 is signatures only. Post-quantum key establishment stays with ML-KEM, so a full migration handles signing and key exchange as two separate problems.
- “An SP 800-208 key can sign forever.” Each key has a finite signing capacity fixed at generation by the tree height. Once the one-time keys are spent, the key pair is retired permanently, which is why these schemes suit low-volume, long-lived roles.
Questions people ask
Is SP 800-208 a finalized standard? Yes. NIST published it as final in October 2020, which makes it the earliest standardized post-quantum signature guidance, roughly four years before the lattice-based ML-DSA and the stateless SLH-DSA were finalized in August 2024.
Which schemes does SP 800-208 actually approve? Four: LMS and its multi-tree form HSS (from RFC 8554), and XMSS and its multi-tree form XMSS^MT (from RFC 8391). All four are stateful hash-based signature schemes.
Do I need a hardware security module to comply? Yes. SP 800-208 requires key generation and signing inside a validated hardware module at FIPS 140 Level 3 or higher, one that can’t export the private key and that persists the signing counter before releasing a signature. That hardware requirement is the standard’s defining conformance rule.
How is SP 800-208 different from FIPS 205? SP 800-208 covers the stateful schemes (compact, but the signer must track used keys in hardware). FIPS 205 covers the stateless SLH-DSA (no state to track, but much larger signatures). Both are conservative hash-based standards; the choice is whether you can manage state.
What should I use SP 800-208 schemes for? Firmware and software signing, secure-boot roots of trust, and other low-volume, long-lived signing done inside a hardware module. For high-volume general-purpose signing, ML-DSA fits better, and for hash-based security without state management, SLH-DSA does.
Why is reusing a key such a big deal? Signing two different messages with the same one-time key exposes enough secret material to forge arbitrary signatures, which is a complete break rather than a gradual weakening. That’s the entire reason SP 800-208 mandates hardware signing and nonvolatile state tracking. The mechanics of why reuse is catastrophic are in the stateful hash-based signatures note.
Does SP 800-208 change my key exchange? No. It only covers signatures. Key establishment moves separately to ML-KEM, so signing and key exchange are handled as two different parts of a post-quantum migration.
Everything here is the map, given freely. When your team needs to decide where LMS, XMSS, and the stateless SLH-DSA actually belong across your firmware, boot chains, and signing estate, that’s the work I do. Request an alignment briefing.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.