LMS XMSS firmware signing post quantum: how does it work?

LMS and XMSS firmware signing is the use of stateful hash-based signature schemes, the Leighton-Micali Signature system (RFC 8554) and the eXtended Merkle Signature Scheme (RFC 8391), to prove that a firmware image comes from its legitimate publisher. Their security rests only on hash functions, so a quantum computer cannot forge them. For OT operators this matters because firmware signed today may still be trusted by a device in the field twenty years from now.

This article explains why the NSA’s CNSA 2.0 suite names these two schemes for software and firmware signing, how they differ in practice, how to manage their one-time keys safely, and what this means for encryption gateways and edge devices, including those at air-gapped sites.

Why does CNSA 2.0 require LMS or XMSS for firmware signing?

CNSA 2.0 picks LMS or XMSS for software and firmware signatures because they are standardized, conservative, and well suited to a signing process that only a few people control. In the NSA’s algorithm table, they replace RSA and ECDSA P-384 in this role, under the profile set out in NIST SP 800-208.

Digital signatures in use today, such as RSA and ECDSA, rely on mathematical problems that a cryptographically relevant quantum computer could solve. Hash-based signatures make no such assumption. NIST published SP 800-208 in October 2020 to approve LMS and XMSS as a supplement to FIPS 186, at a time when the lattice-based standards were still years away. NIST described the schemes as follows:

“They are most appropriate for applications in which the use of the private key may be carefully controlled.” (NIST, announcement of SP 800-208)

Firmware signing fits that description. Releases are infrequent, a small team handles them, and each signature goes through a formal release step. Verification happens on the device every time it boots or installs an update, and it only needs hash computations. NIST’s own work on firmware use cases points the same way. Quynh Dang of NIST’s Cryptographic Technology Group put it this way: “For certificate, software and firmware signings, generally fast verify is more important than fast signing.”

The timeline is the second driver. Many OT assets are expected to run longer than the remaining life of classical signatures:

Firmware a device will verify after 2035 has to carry a signature that is still acceptable then. In practice, that means planning the switch to hash-based signing well before the deadline.

What are the differences between LMS and XMSS for signing gateway and OT device firmware?

Both schemes build a Merkle tree of one-time signature keys and have similar security goals. LMS is simpler and more often found in hardware and boot code. XMSS has a security argument that relies on weaker assumptions about the hash function, but it is more complex to implement and slower to generate keys.

NIST SP 800-208 approves only some of the parameter sets defined in the two RFCs, using SHA-256 or SHAKE256 with 192-bit or 256-bit outputs. It also covers the multi-tree variants: HSS for LMS and XMSS^MT for XMSS. A single tree of height h provides 2^h one-time keys. Multi-tree variants stack trees so that a very large key capacity does not require generating one enormous tree up front.

For a mixed estate of gateways, PLC modules and field devices, the choice often comes down to what the device’s root of trust can verify. If a hardware security module, the boot loader and the update agent already share one scheme, standardizing on it across the fleet keeps the verification code paths few and auditable. Choosing the more elegant scheme for each device separately usually adds complexity.

How do you manage signature state safely so a one-time key is never reused?

Each signature consumes one leaf of the tree, and the signer must record that it is used before the signature leaves the signing environment. NIST SP 800-208 requires key generation and signing in hardware cryptographic modules that do not allow secret keying material to be exported.

The “state” is the index of the next unused one-time key. If two signatures are ever made from the same index, the scheme’s security guarantee for that key is gone. The IETF draft on hash-based signature state management sets the rule plainly: the system must ensure that no two signing operations are ever issued from the same state. NIST’s project page adds that stateful schemes perform better than stateless ones but are vulnerable to misuse when implemented carelessly. The NSA raised the same concern in its comments on NIST SP 800-230: “Our main concerns revolve around the enforcement of the signature limit.”

Controls that work in practice

• Write the state before releasing the signature. The module advances and persists the index in non-volatile storage first, then exports the signature. A power cut in between can waste a leaf, but it can never reuse one.
• Use HSMs validated under FIPS 140-3. Operators typically meet the SP 800-208 hardware requirement with a module validated under FIPS 140-3 that supports LMS or XMSS with state stored inside the module.
• Split capacity instead of copying keys. SP 800-208 describes distributed multi-trees: each module holds its own subtree under one root, so redundancy never means two copies of the same state. It also describes multiple root public keys that devices accept, so losing one module does not halt releases.
• Monitor remaining capacity. Treat leaves left in a tree as an operational metric and alert well before the tree runs out.
• Keep signing ceremonial. A firmware release pipeline that needs two people and a logged HSM operation makes accidental double use unlikely.

NIST is also developing smaller SLH-DSA parameter sets limited to 2^24 signatures per key, intended for certificate, software and firmware signing (NIST, Quynh Dang, September 2025). These are stateless, so there is no index to keep in sync, but the per-key signature limit still has to be enforced. Organizations that find stateful operations too risky should watch this work.

Can quantum-safe firmware signing be retrofitted to existing encryption gateways and edge devices?

Often yes, if the device’s update path can accept a new verifier. Whether it can depends on where the trust anchor lives. A public key or verification routine burned into immutable boot ROM cannot change, but later boot stages and update agents usually can.

Hash-based verification is computationally light, which makes retrofitting more realistic than for many other post-quantum changes. A typical approach looks like this:

1. Map the chain of trust. For each device type, record which stage verifies which, which algorithm it uses, and whether that stage can be updated in the field.
2. Add the verifier at the lowest stage you can update. If the first-stage loader is fixed and only verifies ECDSA, the second stage or the update agent can be extended to require an LMS or XMSS signature on everything after it.
3. Dual-sign during the transition. Ship images with both a classical and a hash-based signature. Older units check the classical one, upgraded units require the hash-based one, and the classical check can later be retired.
4. Distribute the new public key under the old trust. SP 800-208 points to having the current key endorse its successor. The first update carrying the new key is signed with the existing key, and later updates rely on the new one.
5. Plan hardware refresh where nothing can be updated. Devices whose only verifier is immutable and classical cannot be retrofitted. Replace them on a timeline aligned with the NIST IR 8547 dates.

Gateways running on industry-standard x86 hardware usually have updatable boot loaders and operating system update agents, so the work there is mainly process and key management. Small embedded field devices are more likely to have hard limits.

How does quantum-safe firmware verification protect crypto-agility updates at air-gapped sites?

At an air-gapped site, the signature on an update package is the main proof of where it came from, because the device cannot check anything online. If that signature is quantum-safe, an algorithm change delivered by removable media can be trusted on the same terms as the original firmware.

Crypto-agility means you can replace a cryptographic algorithm without replacing the device. The flexibility comes with a risk: the update channel decides which algorithms the device will use. If the update channel is protected by a classical signature, the ability to switch to a stronger post-quantum algorithm is only as strong as RSA or ECDSA. Quantum-safe signing closes that gap. Quantum Network’s QPN gateway, for example, is built so its post-quantum algorithm can be changed, and it runs without cloud dependency, including in air-gapped networks. For equipment like this, authenticating the update package is a precondition for using that agility safely.

What verification looks like offline

• Pinned trust anchors. The device holds the LMS or XMSS public keys (or the root of a multi-tree) locally, so verification needs no network, timestamp server or certificate revocation lookup.
• Signed manifests, not just signed blobs. The manifest binds the image hash, the target device type, the version number and the algorithm configuration, so a valid image cannot be applied to the wrong unit.
• Anti-rollback counters. The device refuses any version lower than the one installed. This blocks reinstalling an older, validly signed image that still relies on a weaker algorithm.
• Verification at both ends of the transfer. Staff check the package at the media-preparation station before it crosses the gap, and the device checks it again before installing. Both checks use the same public keys.

Long service life is what makes this urgent for OT. A signature applied to a firmware image today is checked again at every boot for as long as the unit runs. Hash-based signatures let that integrity guarantee last as long as the asset does, instead of expiring when classical signatures are disallowed.

Where should an OT security team start with LMS and XMSS?

Start with an inventory of signing keys and verifiers rather than with algorithm selection. The schemes are standardized. What usually limits progress is knowing which devices can accept a new verifier and who controls the signing keys.

A workable sequence: list every firmware signing key and the devices that trust it. Classify each device as updatable, partly updatable or fixed. Choose LMS or XMSS based on what the updatable roots of trust can verify. Stand up signing in hardware modules with state handled inside the module. Then introduce dual signatures with the next scheduled release. Planning this way keeps most of the effort inside the normal release process rather than adding a separate project.