Post-quantum code signing explained: LMS, XMSS, ML-DSA and SLH-DSA compared, CNSA 2.0 rules, state management and a migration plan for firmware.
Post-quantum code signing means signing firmware, software, update packages and container images with signature algorithms that a quantum computer cannot forge: the hash-based schemes LMS and XMSS (NIST SP 800-208), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). It matters earlier than most post-quantum work because a device often verifies signatures with the same algorithm and root key for its entire life.
A cryptographically relevant quantum computer could derive an RSA or ECDSA signing key from its public key and sign malicious updates that every device accepts. Firmware shipped today with an RSA-only verifier may still be in the field when that becomes possible. That is why the NSA treats software and firmware signing as the most urgent part of its CNSA 2.0 transition.
This guide compares the post-quantum signature options for code signing, explains the state management that LMS and XMSS require, summarizes the CNSA 2.0 rules, and gives a migration plan. For the mechanics of protecting signing keys, see our guide to code signing with non-exportable keys.
Encrypted data is exposed to "harvest now, decrypt later". Signatures face a different risk: a forged signature only matters once someone can forge it. For code signing that still arrives early, for three reasons:
The consequence: a device designed today needs a post-quantum verifier, or at least a way to add one through a trusted update, before it ships.
| Algorithm | Standard | Type | Keys and signatures | State to manage | CNSA 2.0 | Best fit |
|---|---|---|---|---|---|---|
| LMS | NIST SP 800-208 (RFC 8554) | Stateful hash-based | Small public key; compact signature; limited number of signatures per key | Yes, strictly | Approved for software and firmware signing; LMS SHA-256/192 recommended | Firmware and boot chains, constrained verifiers |
| XMSS | NIST SP 800-208 (RFC 8391) | Stateful hash-based | Small public key; limited number of signatures per key | Yes, strictly | Approved for software and firmware signing | Firmware where XMSS is already supported |
| ML-DSA | FIPS 204 | Lattice-based, stateless | Public key 1,312 to 2,592 bytes; signature 2,420 to 4,627 bytes | No | ML-DSA-87 approved for any signing use | Software, packages, containers, high signing volume |
| SLH-DSA | FIPS 205 | Stateless hash-based | Public key 32 to 64 bytes; signature 7,856 to 49,856 bytes; slow signing | No | Not approved for NSS | Long-lived roots outside NSS, conservative hedge |
| Composite (ML-DSA + ECDSA or RSA) | IETF draft | Hybrid | Sum of both | No | Not required by NSA | Transition where verifiers must also accept classical |
Hash-based schemes rely only on the security of the hash function, a conservative assumption, and verification is cheap on chips that already accelerate SHA-256. ML-DSA is stateless and fast, which suits build pipelines that sign many artefacts.
LMS and XMSS build a signing key from many one-time signature keys arranged in a Merkle tree. Each signature consumes one one-time key. Two rules follow:
What that means operationally:
| Concern | Why it matters | Practical control |
|---|---|---|
| Backup and restore | Restoring an older copy of the private key rewinds the state and causes key reuse | Do not back up state the classical way; use schemes that split the key into separate sub-trees or devices |
| High availability | Two signers sharing one key can use the same one-time key | One active signer per key, or a partitioned key space per signer |
| Crash during signing | State must be updated before the signature leaves the module | Use modules that persist state atomically |
| Key exhaustion | A key that runs out stops your release process | Monitor remaining signatures and roll keys early |
NIST SP 800-208 addresses this by requiring key generation and signing in hardware cryptographic modules that do not allow the private key to be exported. The NSA notes that NSS signers must follow SP 800-208, which requires CMVP-validated hardware, while products that only verify LMS or XMSS signatures need only CAVP-validated verification code.
This is the main reason stateful schemes are recommended for firmware and software signing only, where signing is centralized, infrequent and controlled, and not for general-purpose signing.
ML-DSA is the general-purpose post-quantum signature and needs no state, so it fits existing signing services, approval workflows and build pipelines with fewer operational changes. Its cost is size: an ML-DSA-65 signature is 3,309 bytes, and certificate chains for code signing grow by several kilobytes. For most software, packages and container images that is acceptable. For a boot ROM with tight memory it may not be.
SLH-DSA gives a hash-only security basis without state, but its signatures range from about 7.9 KB to 49.9 KB and signing is slow. It is a candidate for long-lived roots that sign rarely, outside the CNSA 2.0 scope.
Both standards define a "pure" mode and a pre-hash mode (HashML-DSA, HashSLH-DSA). Pre-hash signing lets a build send only a digest to a remote signer, the model used by most remote code signing services. Check which mode your verifier expects; the two are not interchangeable.
For certificate formats and post-quantum CA hierarchies that issue code signing certificates, see the ML-DSA certificates and post-quantum PKI guide.
For US National Security Systems, the NSA's CNSA 2.0 FAQ (version 2.2, October 2026) sets these rules:
The full schedule is in our CNSA 2.0 timeline.
Post-quantum code signing depends on verifiers: the operating system, the runtime, the bootloader or the admission controller that checks the signature. Support is uneven:
| Area | Status (November 2026) |
|---|---|
| Your own firmware and update agent | Fully under your control: you can add an LMS, XMSS or ML-DSA verifier now |
| Libraries | OpenSSL 3.5 implements ML-DSA and SLH-DSA; Java 24 added ML-DSA (JEP 497) |
| Java JAR signing | Out of scope of JEP 497, which lists JAR-file signing as a non-goal until the standards for it exist |
| Platform code signing (Authenticode, mobile app stores, package managers) | Depends on each platform vendor adding verification and on certificate policies; track vendor announcements |
| Private PKI for signing certificates | ML-DSA in X.509 is defined in RFC 9881 and usable with your own trust anchor |
The practical order is therefore: first the signatures you also verify yourself (firmware, update packages, internal artefacts), then platform signatures as vendors enable them.
According to DuoKey's documentation:
LMS and XMSS signing is not described in DuoKey's documentation. For a specific post-quantum signing requirement, contact DuoKey.
Q: What is post-quantum code signing?
It is the signing of firmware, software, packages and container images with signature algorithms designed to resist forgery by a quantum computer: LMS and XMSS (NIST SP 800-208), ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). It protects devices and users from malicious updates signed with a key derived by a quantum attack.
Q: Why is firmware signing more urgent than other post-quantum work?
Because the verifier is often locked into the device for its whole life. If the boot ROM or update agent only accepts RSA or ECDSA, a future forged signature cannot be blocked by a software change. The NSA prioritizes firmware signing in CNSA 2.0 for this reason.
Q: Should I use LMS, XMSS or ML-DSA for code signing?
LMS or XMSS suit firmware and boot chains: small public keys, cheap verification and a conservative hash-based security basis, at the cost of strict state management. ML-DSA suits software and high-volume signing because it is stateless. In CNSA 2.0 scope, LMS (preferably SHA-256/192), XMSS and ML-DSA-87 are approved.
Q: Is SLH-DSA approved for code signing under CNSA 2.0?
No. The NSA's CNSA 2.0 FAQ states that SLH-DSA is not part of CNSA and is not approved for any use in national security systems. Outside that scope, SLH-DSA is a NIST standard and can be used.
Q: Why are LMS and XMSS called stateful?
Each signature uses a one-time key from a Merkle tree, and a one-time key must never be reused. The signer must keep track of which keys are used, which makes backup, cloning and high availability harder. NIST SP 800-208 therefore requires signing in hardware modules that do not export the private key.
Q: Can I sign Windows or Java code with post-quantum algorithms today?
Publicly verified platform signatures depend on the platform vendors. Java 24 added ML-DSA, but its JEP lists JAR-file signing as a non-goal for now. Start with signatures you verify yourself, such as firmware and update packages, and track platform announcements for the rest.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
