up:: In the Protocols MOC

PQC in Firmware and Code Signing

Post-quantum firmware and code signing is the migration of the signatures that prove software and firmware came from a trusted publisher, and it is the first signing surface that has to move, because a firmware root of trust or a secure-boot chain is expected to stay verifiable for the decade-plus a device sits in the field, which runs straight through the arrival of a quantum computer. The defining choice in this domain is which post-quantum signature to use. For long-lived, low-volume firmware signing, the frequent answer is the stateful hash-based signatures LMS and XMSS, standardized in NIST SP 800-208, rather than the general-purpose lattice signature ML-DSA, because their security rests only on a hash function and their signatures are compact. The price is statefulness, which is why CNSA 2.0 approves LMS and XMSS specifically for software and firmware signing and requires the signing to happen in hardware.

Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, csrc.nist.gov.

The short version:

• Firmware and code signing move first among signing surfaces, because a device’s root of trust and secure-boot chain must stay verifiable for the many years the device lives, so its signature has to outlast the quantum computer.
• The signature is Non-HNDL, so it is not a harvest-now-decrypt-later race, but a firmware key with a long life still has to be quantum-safe before a quantum computer can forge an update that a decade-old device will accept.
• The standard-bearer choice is the stateful hash-based signatures LMS and XMSS from NIST SP 800-208, because their hash-only security is maximally conservative and their signatures are compact, which suits low-volume signing on constrained devices.
• The catch is state: each key signs a fixed number of times and must never reuse a one-time key, because a single reuse lets an attacker forge arbitrary signatures, so SP 800-208 requires signing inside a hardware module.
• CNSA 2.0 names LMS and XMSS for firmware and software signing, and SLH-DSA is the stateless hash-based alternative where the state burden isn’t worth carrying, while ML-DSA is the general-purpose lattice signature for higher-volume, latency-sensitive surfaces.

Picture the master seal that authorizes updates to a satellite that will orbit for 15 years. You will use that seal only a handful of times across its life, but every press has to be trusted for the whole mission, long after the ground has changed. You would want the simplest, most time-tested seal design you can get, and you would keep it locked in a vault that never lets a copy out, so no one can press it twice by accident. Firmware signing is that seal. The hash-based schemes are the time-tested design, the hardware module is the vault, and the discipline that no press is ever repeated is what keeps the whole thing sound.

Why does firmware signing migrate before other signatures?

Because firmware trust has to survive the longest, so it has the least slack against the quantum clock. A TLS certificate lives for months and a code-signing certificate for a few years, but a firmware root of trust is burned into a device that ships and then operates for a decade or more with the same trust anchor. When that device receives an update, its bootloader verifies the update’s signature against a public key it was manufactured to trust. If a quantum computer can forge that signature during the device’s service life, an attacker can push malicious firmware that the device will accept as genuine, and there is no practical way to re-key millions of already-shipped units.

That is why firmware and code signing sit at the front of the signature migration even though signatures overall are the Non-HNDL, slower-clock half of the transition. The exposure is not harvest-now-decrypt-later, because a forged signature needs a live quantum computer to produce, so there is nothing to record today. The urgency instead comes from device lifetime: a signing key and a trust anchor chosen now have to still be unforgeable a decade from now, so the safe move is to bake a quantum-resistant signature into the boot chain before the long-lived hardware ships. This is also why NIST SP 800-193, the firmware resiliency guidelines, treats cryptographic authentication of firmware as load-bearing for the protect-detect-recover model.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, May 2018, csrc.nist.gov.

Why use stateful hash-based signatures instead of ML-DSA?

Because firmware signing wants the most conservative security foundation and the smallest signatures, and the stateful hash-based schemes deliver both, at the cost of a state-management burden that a controlled firmware signer can actually meet. Four properties drive the choice:

1. Maximum-confidence security. LMS and XMSS reduce entirely to the strength of a hash function, the oldest and best-studied assumption in cryptography, so their security does not depend on the younger lattice mathematics ML-DSA rests on. For a trust anchor that must hold for decades, that conservatism is worth a lot.
2. Compact signatures. Hash-based stateful signatures are far smaller than the stateless SLH-DSA and competitive with the lattice schemes, which matters when a bootloader on a constrained device has to store and verify one in tight flash and memory budgets.
3. Low, predictable volume. A device might receive a handful of firmware updates a year across its life, which fits the finite signing capacity of a stateful key perfectly, since you can size the key’s capacity to the expected lifetime volume when you generate it.
4. A controlled signer that can manage state. Firmware is signed by a single, deliberate signing authority inside a hardware module, which is exactly the environment where the state can be tracked reliably, so the state burden that makes these schemes dangerous for general use is manageable here.

The tradeoff is that a stateful key can sign only a fixed number of times and the signer must never reuse a one-time key. That is a poor fit for high-volume, latency-sensitive signing, which is where the stateless lattice ML-DSA or the stateless hash-based SLH-DSA belong instead.

Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, csrc.nist.gov.

What is the state-management burden, and why does it force hardware?

The state is the record of which one-time keys a stateful private key has already spent, and it forces hardware because a single duplicated use collapses the scheme’s security completely. Under the hood, a hash-based signature is built from many one-time keys arranged as the leaves of a Merkle tree, and signing walks through them in order. Signing two different messages with the same one-time key exposes enough of the underlying secret that an attacker can forge signatures on messages of their choosing, which is a total break with no graceful degradation.

What makes the hazard sharp is that the ways to duplicate state are all ordinary IT operations that feel harmless:

1. Restoring from a backup. Roll a signing server back to last night’s snapshot and it resumes at a counter value it already passed, re-spending keys it used during the day.
2. Cloning a virtual machine or container. Two clones inherit the same counter and independently sign from the same position.
3. Syncing or load-balancing across nodes. Two instances that share a key but not a perfectly synchronized counter eventually collide on a leaf.
4. Copying a key for redundancy. Any “make a spare copy of the private key” instinct reintroduces the exact reuse it was meant to guard against.

Because of this, NIST SP 800-208 imposes an unusual conformance requirement for a signature standard: key and signature generation must happen inside hardware cryptographic modules that never export the secret keying material, even in encrypted form. The hardware boundary is what makes the backup-and-clone mistakes structurally impossible, which is why a software-only LMS or XMSS deployment is out of compliance with the standard. Firmware signing already lives inside a controlled hardware signer, so this requirement is a natural fit rather than an added obstacle.

Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, §1.2 and §8, October 2020, csrc.nist.gov.

Where is stateful hash-based signing approved for firmware?

The clearest approval comes from CNSA 2.0, which names LMS and XMSS specifically for signing software and firmware in national security systems, rather than for general-purpose use. The reasoning fits everything above: firmware and software updates are signed infrequently by a controlled authority, they must stay verifiable for the many years or decades a device stays in the field, and that long-lived trust is exactly where the maximum-confidence hash foundation earns its keep. CNSA 2.0 also reminds implementers that LMS and XMSS stay secure only if they meet all of NIST SP 800-208, including managing signing state and performing the signing in hardware.

This is why the schemes show up first in the boot and firmware world. A secure-boot chain or a constrained device that will receive updates for a decade needs signatures that outlive the arrival of a quantum computer, gets them rarely, and can host its signing key inside a hardware module. That profile matches stateful hash-based signing almost perfectly, and it is a poor match for high-volume, latency-sensitive surfaces like TLS, where the general-purpose lattice signature ML-DSA fits better.

Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022, nsa.gov.

Which post-quantum signature belongs on which signing surface?

The three NIST-standardized post-quantum signature families divide the signing world by volume, latency, and how the signer manages state. Firmware and code signing sit at the low-volume, long-lived, hardware-managed corner, which is the stateful hash-based schemes’ home.

Signing surface	Volume	Signature choice	Why
Firmware and secure-boot roots of trust	Low, over a long life	XMSS	Maximum-confidence hash security, compact signatures, controlled signer can manage state in hardware
General code signing where state is hard	Moderate	SLH-DSA	Same hash-based conservatism without the state footgun; larger signatures are the price
High-volume, latency-sensitive (e.g. TLS certificates, tokens)	High	ML-DSA	General-purpose lattice signature, fast and stateless, smaller than SLH-DSA

Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, csrc.nist.gov.

The decision rule most programs land on: if the signing lives inside a hardware module that can rigorously manage state and the volume is low and long-lived, the compact stateful schemes are excellent. Where the state cannot be guaranteed, the stateless SLH-DSA is the safer hash-based default, trading larger signatures for the removal of the reuse hazard. And where throughput and latency dominate, ML-DSA is the general-purpose choice. Note that all three sign only; key establishment stays the job of ML-KEM.

Common misconceptions

• “Firmware signing is a slow-clock problem, so it can wait.” The signature is Non-HNDL, so there is nothing to harvest, but a device that ships today operates for a decade with the same trust anchor, so a signature chosen now has to be unforgeable across that whole life. That long lifetime is why it moves first.
• “ML-DSA is the post-quantum signature, so firmware should use it.” ML-DSA is the general-purpose choice, but firmware often uses the stateful hash-based LMS or XMSS instead, for their conservative hash-only security and compact signatures on long-lived, low-volume signing.
• “LMS and XMSS are a drop-in signing swap.” They carry a hard requirement most schemes don’t: to stay secure and compliant they must meet all of NIST SP 800-208, including state management and signing performed in hardware. A software-only implementation is out of compliance and unsafe.
• “Reusing a firmware signing key just weakens it a little.” Signing two messages with the same one-time key is a complete break that lets an attacker forge arbitrary signatures. There is no graceful degradation, which is the entire reason the state discipline and the hardware requirement exist.
• “Stateless SLH-DSA replaced the stateful schemes for firmware.” All three hash-based and lattice options are current NIST standards for different jobs. The stateful schemes stay in the firmware toolkit precisely because they are more compact when the signer can manage state safely.

Questions people ask

Why does firmware signing migrate before TLS certificate signatures? Because firmware trust anchors live for a decade or more in shipped hardware, so a signature chosen now has to be unforgeable across that whole life, while a TLS certificate can be reissued in months. The long-lived boot chain has the least slack against the quantum clock, so it moves first.

Which post-quantum signature does firmware use? Frequently the stateful hash-based LMS or XMSS from NIST SP 800-208, because their hash-only security is maximally conservative and their signatures are compact. CNSA 2.0 names them specifically for software and firmware signing.

Why can’t I just use ML-DSA everywhere? You can for most surfaces, but firmware signing values the conservative hash-only foundation and small signatures that the stateful schemes give, and its low, controlled volume makes the state burden manageable. ML-DSA is the better fit for high-volume, latency-sensitive signing.

What happens if a stateful firmware key reuses a one-time key? An attacker who sees two signatures made with the same one-time key can recover enough secret material to forge signatures on messages of their choosing. It is a total compromise of that key, which is why signing must happen inside a hardware module that prevents key duplication.

Do I have to sign firmware in hardware? For LMS and XMSS, yes. NIST SP 800-208 requires key and signature generation inside a hardware module that never exports the secret key, because that is the only reliable way to guarantee a one-time key is never reused. Firmware signing already uses a controlled hardware signer, so this is a natural fit.

When should I use SLH-DSA instead of LMS or XMSS for signing software? When you can’t guarantee the signing state is never duplicated, or you don’t want to carry that operational burden. The stateless SLH-DSA removes the reuse hazard entirely, at the cost of much larger signatures.

Does any of this change how key exchange migrates? No. Firmware and code signing are a signature problem, and these hash-based schemes sign only. Key establishment moves separately to ML-KEM, so a full post-quantum migration handles signing and key exchange as two different tracks.

Go deeper

The stateful schemes themselves, their capacity numbers, and the reuse hazard live in Stateful Hash-Based Signatures (XMSS - LMS), with the standard at NIST SP 800-208. The signing surface as a whole is Code Signing, and the firmware-resiliency framing is NIST SP 800-193. The stateless hash-based alternative is SLH-DSA and the general-purpose lattice signature is ML-DSA. The hub that maps this into every other protocol is In the Protocols MOC.

---

Everything here is the map, given freely. When your team needs its firmware roots of trust, secure-boot chains, and code-signing pipelines assessed for where the stateful hash-based signatures actually belong and where a stateless scheme fits better, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.