If you sign software or firmware, the post-quantum transition reaches you before almost anyone else, and it forces a choice the rest of the PQC conversation mostly skips. Most of the attention goes to TLS and certificates, which can be reissued in hours when something needs to change. Firmware signing is the opposite case. The signature on a firmware image must stay verifiable for ten or fifteen years, on devices you may never physically touch again, against an attacker who may already have a quantum computer by the time those devices retire.
If that signature rests on RSA or ECDSA, a quantum computer can forge it, and forged firmware is firmware the device will trust and run. When the root of trust is burned into hardware, there is usually no patch that fixes it after the fact. That makes the devices you ship this year the ones most exposed, and the hardest to repair once they are in the field. This is the part of the post-quantum migration that cannot wait, and it is the reason firmware signing carries the earliest deadline in the entire transition.
The pressure is real, but the answers are not in doubt. The quantum-safe signature algorithms for this job, SLH-DSA, LMS, and XMSS, are all hash-based, all standardized, and all built on cryptography that has been studied for decades. So the question facing signing teams in 2026 is not whether a solution exists, it is which one to use, and the honest version of that decision is more constrained than it first appears. This post walks through how these algorithms differ, the stateful-versus-stateless trade-off at the center of the choice, and the one piece of regulatory guidance that often makes the decision for you.
Why hash-based signatures, and why now
Code and firmware signing has a property that most cryptography does not: the signature has to outlive almost everything around it. You sign a firmware image once, and that signature may need to verify correctly for the entire service life of the hardware, long after the signing infrastructure has changed. If the algorithm behind it is broken in that window, an attacker can forge a signature and push malicious firmware that devices will trust completely. For a root of trust burned into hardware, there may be no way to fix it in the field.
That long horizon is exactly why this is the first-place quantum resistance matters. It is also why hash-based signatures are the chosen tool. Unlike RSA and ECDSA, which rest on number-theoretic problems that a quantum computer can solve, hash-based signatures rest only on the security of a hash function like SHA-256. Hash functions are not meaningfully threatened by quantum computers, beyond a manageable reduction in strength that larger outputs absorb. They are old, they are well understood, and they were ready long before the lattice-based schemes matured. For something that must stay secure for fifteen years, that track record is worth a lot.
SLH-DSA, LMS, and XMSS are all hash-based, and they share the same underlying structure: many one-time signature instances combined into a single public key through a Merkle tree. The differences between them are what the decision turns on.
The real divide: stateful or stateless
The most important difference is not performance or signature size. It is state.
LMS and XMSS are stateful. Each private key can produce only a fixed number of signatures, and the signer must track exactly which ones have been used. That tracking is the whole ballgame. If the state is ever mismanaged, if a one-time component gets used twice because a key was restored from a backup, copied to a second server, or run in parallel, an attacker who sees both signatures can forge new ones. The math that makes these schemes secure depends absolutely on never reusing a one-time piece. Get the state wrong and the security is gone, quietly.
SLH-DSA is stateless. It was designed specifically to remove this hazard. Instead of tracking used signatures, it makes random selections and relies on the probability of a collision being negligibly small. There is no state to corrupt, no counter to lose, no risk from a restored backup. That single design choice has large operational consequences, which is the next thing to weigh.
What you give up and gain each way
Stateful signatures (LMS and XMSS) are efficient and compact relative to the stateless option, and they have a long deployment history in exactly this firmware-signing role. The cost is operational discipline. Because the signer must maintain state perfectly, signing is tied to a single controlled instance of the key. You cannot freely run signing in parallel across many machines, because that is precisely how you end up reusing state.
For a firmware signing process where the volume of signatures is known and bounded, this is usually an acceptable constraint, and it is why these schemes suit the firmware case so well. The strong recommendation, though, is to keep the key and its state management inside hardware, an HSM, so that state cannot be accidentally duplicated or rolled back.
Between the two stateful options, LMS is the simpler, faster default. It uses fewer clock cycles for key generation, signing, and verification, and it consumes less memory. XMSS adds a bitmask construction that some teams prefer for its stronger security assumptions, at the cost of more hashing and higher memory use. For most signing operations the practical difference is small, and LMS is the reasonable starting point unless you specifically want what XMSS offers.
Stateless signatures (SLH-DSA) trade size for safety. SLH-DSA signatures are larger, which can matter for bandwidth-limited devices or storage-constrained update mechanisms, and signing is computationally heavier. In return you get freedom from state entirely. Because there is nothing to corrupt, SLH-DSA can be parallelized and run across a distributed signing system without the reuse hazard that constrains LMS and XMSS. For a high-volume or distributed signing operation where coordinating state across machines would be fragile, that freedom is worth the larger signatures.
The catch that often decides it: CNSA 2.0
Here is where the clean three-way comparison breaks, and it is the detail most summaries bury. If your signing touches National Security Systems, or your customers sell into them, the NSA’s CNSA 2.0 suite governs your choice, and CNSA 2.0 does not approve SLH-DSA.
For software and firmware signing, CNSA 2.0 approves the stateful schemes, LMS and XMSS, drawn from NIST SP 800-208, with LMS using SHA-256/192 as the preferred parameter set. SLH-DSA is a final NIST standard under FIPS 205, and it is perfectly legitimate for commercial signing, but it is not part of CNSA 2.0 and is not approved for NSS. ML-DSA, the lattice-based stateless signature standard, is also approved under CNSA 2.0 and is the sensible option when your signing volume exceeds what a single stateful key can reasonably handle, or when you need distributed signing.
So, the decision splits cleanly along one line. If you are in scope for CNSA 2.0, your stateless option is effectively ML-DSA, not SLH-DSA, and you will likely be building on LMS or XMSS with hardware-backed state management. If you are signing for the commercial world, you have the full menu, and the stateful-versus-stateless trade-off above is a genuine engineering choice rather than a compliance constraint.
The timing pressure is real either way. Firmware signing carries the earliest deadline in the whole post-quantum transition, because firmware roots of trust are the hardest things to change after they ship. Under CNSA 2.0 the expectation has been to begin adopting these signatures already, with the acquisition gate for software and firmware signing arriving well ahead of the broader 2035 rollover. Whether or not CNSA 2.0 binds you, the underlying logic holds: the longer your signatures must stay valid, the less time you have to make the switch.
How Encryption Consulting can help
Choosing between stateful and stateless signing, and then operating it safely, is a mix of strategy and hard implementation detail. That is the work we do.
CodeSign Secure, our code signing solution, is built to protect signing keys and enforce controlled signing workflows, which is exactly what these quantum-safe schemes demand. It gives you a governed signing process for software, firmware, and other artifacts, with the policy controls and key protection that matter most when you move to LMS, XMSS, or a stateless algorithm. For stateful schemes, where a single state slip can undo the whole security model, having signing run through a disciplined, centralized system rather than ad hoc scripts is what keeps a one-time key from ever being reused.
Because the stateful schemes effectively require hardware-backed key and state management, HSM-as-a-Service is the natural foundation underneath them. It keeps your signing keys isolated in a hardware security module, so the state that LMS and XMSS depend on cannot be casually copied, restored from a backup, or run in parallel, the failure modes that turn a stateful signature into a forgeable one.
Deciding which algorithm fits your devices, your signing volume, and your compliance obligations is where our Post-Quantum Cryptographic Advisory Services come in. We help you weigh the stateful-versus-stateless trade-off against your real constraints, account for CNSA 2.0 if it applies to you, and build a migration plan for your signing infrastructure that fits the timeline you are working against.
If you are mapping out quantum-safe signing for your products, or trying to decide between LMS, XMSS, and a stateless scheme before you commit, get in touch. We can help you make the call and stand up the infrastructure behind it.
Conclusion
The move to quantum-safe code and firmware signing is one of the few parts of the PQC transition where the algorithms are settled and the deadline is close. SLH-DSA, LMS, and XMSS are all sound, hash-based, and quantum-resistant. The choice between them comes down to whether you can manage state safely and whether anything pushes you toward a stateless design.
For most teams the deciding factors are compliance and operations. If CNSA 2.0 applies, the stateless seat at the table belongs to ML-DSA, and your hash-based options are LMS and XMSS with hardware-backed state. If it does not, SLH-DSA is a legitimate way to avoid the state-management burden entirely, at the price of larger signatures. Either path works, but only if the signing keys are protected and the process is disciplined enough that a one-time key never gets used twice.
Firmware you sign this year may still be running, and still need to verify, long after quantum computers arrive. That is the reason this decision cannot wait, and the reason it is worth getting right the first time.
