Post-Quantum Code Signing with ML-DSA and LMS

Post-quantum code signing is the practice of signing software, firmware, and updates with quantum-resistant algorithms, primarily ML-DSA (FIPS 204) for general-purpose signing and the hash-based LMS or XMSS schemes (NIST SP 800-208) for firmware, so that signatures remain trustworthy after quantum computers can break RSA and ECDSA.

Post-quantum code signing replaces the RSA and ECDSA signatures used in today’s code signing with quantum-resistant algorithms. The two main choices are ML-DSA (FIPS 204), a lattice-based signature suited to general-purpose and high-volume signing, and LMS or XMSS (NIST SP 800-208), stateful hash-based signatures the NSA recommends for firmware and software update signing today. Because signed code can persist for years, this migration is one of the most urgent in the quantum transition.

Key Takeaways

• Post-quantum code signing uses quantum-resistant algorithms so that software and firmware signatures cannot be forged once a quantum computer can break RSA and ECDSA.
• ML-DSA (FIPS 204) is the lattice-based, general-purpose choice: stateless, high-throughput, and well suited to frequent software signing. It was finalized in August 2024.
• LMS and XMSS (NIST SP 800-208) are stateful hash-based signatures. The NSA recommends them for firmware and software update signing today, but they require strict key-state tracking, which makes secure key management essential.
• Signed code has a long shelf life, so a signature created today must resist a quantum computer that arrives years later. That is why code signing is a top-priority migration area under CNSA 2.0.
• Not all HSMs support ML-DSA yet, so a real migration involves confirming HSM and toolchain support, piloting in non-production, and often dual or hybrid signing during the transition.

Why Code Signing Must Go Post-Quantum

Code signing proves that software came from a trusted publisher and has not been altered. It relies almost entirely on RSA and ECDSA signatures, both of which a sufficiently powerful quantum computer can forge using Shor’s algorithm. If an attacker can forge a code signature, they can distribute malicious software that operating systems, package managers, and devices will accept as genuine, which is among the most damaging attacks possible.

Two factors make this urgent rather than theoretical. First, signed artifacts are long-lived: firmware, drivers, and operating system images signed today may still be verified a decade or more from now, so a signature must resist the quantum computers of the future, not just the present. Second, in many systems the verification algorithm is hard to change after deployment. This is why the NSA’s CNSA 2.0 guidance treats code and firmware signing as a top-priority migration area, ahead of many other cryptographic transitions.

The Two Main Approaches: ML-DSA and Hash-Based (LMS/XMSS)

Post-quantum code signing centers on two families of algorithms, and choosing between them is the central decision. They are complementary, not competing, and many organizations will use both.

ML-DSA (FIPS 204)

ML-DSA is a lattice-based signature algorithm, finalized by NIST in August 2024, and it is the general-purpose default for post-quantum signing. Its key advantages for code signing are that it is stateless, so there is no per-signature bookkeeping, and it offers unlimited signing capacity with strong performance, which suits high-volume and high-throughput signing such as continuous software builds.

Its main cost is larger signatures and keys than classical algorithms, though smaller than the hash-based alternatives in many configurations.

LMS and XMSS (NIST SP 800-208)

LMS (Leighton-Micali Signature) and XMSS (eXtended Merkle Signature Scheme) are stateful hash-based signatures, standardized by NIST in 2019. Their security rests only on the properties of hash functions, the most conservative and well-understood foundation in cryptography, which is why the NSA recommends them for firmware and software update signing today.

The catch is that they are stateful: each private key can produce only a fixed number of signatures, and the signer must track which one-time keys have been used, because reusing one breaks security. This makes them ideal for infrequent, controlled signing such as firmware releases, and impractical for high-frequency signing.

SLH-DSA (FIPS 205): the stateless hash-based option

SLH-DSA, finalized in August 2024, is a stateless hash-based signature. It offers the conservative hash-based security of LMS and XMSS without the state-management burden, at the cost of larger signatures. It is a strong choice where an organization wants hash-based assurance but cannot manage signing state.

Algorithm	Type	Best code-signing fit
ML-DSA (FIPS 204)	Lattice-based, stateless	General-purpose, high-volume software signing; CI/CD
LMS / XMSS (SP 800-208)	Hash-based, stateful	Firmware and infrequent update signing; NSA-recommended today
SLH-DSA (FIPS 205)	Hash-based, stateless	Conservative long-lived signing without state management

How to Choose: ML-DSA or LMS/XMSS

The decision comes down to signing frequency, the conservatism required, and operational complexity.

• Choose ML-DSA when you sign frequently or at high volume, want stateless simplicity in CI/CD, and are comfortable with lattice-based security. This fits most general software signing.
• Choose LMS or XMSS when you sign infrequently, need the most conservative hash-based security for long-lived firmware, and follow CNSA 2.0 guidance for firmware and software update signing today. Be ready to manage signing state.
• Choose SLH-DSA when you want hash-based conservatism but cannot accept the operational burden of state management, and can tolerate larger signatures.

Many organizations combine them: LMS or XMSS for the firmware and secure-boot roots that must be maximally conservative, and ML-DSA for the higher-volume application and package signing where throughput matters.

The Migration Path to Post-Quantum Code Signing

1. Inventory your signing: Find every place your organization signs code and firmware, which algorithms and key sizes are used, and where the keys live. You cannot migrate what you cannot see.
2. Prioritize by longevity: Start with the signatures that must remain valid longest and are hardest to change: firmware, secure-boot roots, and long-lived releases.
3. Confirm HSM and toolchain support: Verify that your HSM, signing tools, and verification clients support your chosen post-quantum algorithm. Not all HSMs support ML-DSA yet, so engage vendors early.
4. Pilot in non-production: Test signing and verification with ML-DSA, LMS, or XMSS to surface performance, signature-size, and compatibility issues before committing.
5. Adopt dual or hybrid signing: During the transition, sign artifacts with both a classical and a post-quantum algorithm so older verifiers still work while newer ones gain quantum resistance.
6. Build crypto-agility: Design signing and verification so algorithms can be swapped without re-architecting, because guidance and standards will keep evolving.

The Hard Part: HSMs, Key Management, and State

The algorithms are standardized, but the operational reality of post-quantum code signing is where programs stall. Three challenges recur.

First, HSM support is still maturing. Not every hardware security module can yet generate and use ML-DSA keys, and vendors have been rolling out support on their own timelines, so confirming support is a real migration step rather than an assumption. Second, hash-based schemes add a state-management burden: LMS and XMSS require strict tracking of which one-time keys have been used, and a mistake can compromise security, so this cannot be left to manual processes.

Third, the keys themselves are as sensitive as ever, so they must remain in hardware throughout. A capable signing platform addresses all three: it manages HSM-backed post-quantum keys, tracks hash-based signing state automatically, and enforces access control and audit across every signing operation.

How Encryption Consulting Helps

Encryption Consulting’s CodeSign Secure is built to make post-quantum code signing operational, not just theoretical. It signs against keys held in a FIPS 140-2 Level 2 HSM, supports post-quantum signature schemes including ML-DSA and the hash-based LMS and XMSS, and handles the strict signing-state tracking that stateful hash-based schemes require so teams do not have to manage it by hand.

It integrates into CI/CD pipelines, supports dual and hybrid signing during the transition, and logs every operation for audit. The same platform governs your classical and post-quantum signing across software, firmware, and containers, so you can migrate on your own timeline without losing control. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is post-quantum code signing?

Post-quantum code signing is the practice of signing software, firmware, and updates with quantum-resistant algorithms instead of RSA or ECDSA, so the signatures cannot be forged by a future quantum computer. The main algorithms are ML-DSA (FIPS 204), a lattice-based general-purpose signature, and LMS or XMSS (NIST SP 800-208), stateful hash-based signatures recommended for firmware. Because signed code can remain in use for years, migrating code signing is one of the most urgent parts of the quantum transition.

Should I use ML-DSA or LMS for code signing?

It depends on how you sign. ML-DSA is stateless, high-throughput, and well suited to frequent, high-volume software signing such as CI/CD pipelines. LMS and XMSS are stateful hash-based schemes with the most conservative security, recommended by the NSA for firmware and software update signing today, but they require strict key-state tracking and suit infrequent signing. Many organizations use LMS or XMSS for firmware roots and ML-DSA for high-volume application signing.

Why are LMS and XMSS called stateful, and why does it matter?

LMS and XMSS are stateful because each private key can produce only a fixed number of signatures, and the signer must track which one-time keys have already been used. Reusing a one-time key breaks the security of the scheme, so the state must be tracked reliably, never manually. This is manageable for infrequent firmware signing but impractical for high-frequency signing, and it makes a capable signing platform that automates state tracking important for safe adoption.

Is ML-DSA supported by hardware security modules yet?

Support is growing but not universal. As of 2026, not all HSMs can generate and use ML-DSA keys, and major vendors have been rolling out post-quantum support on their own timelines. Confirming that your specific HSM, signing tools, and verification clients support your chosen algorithm is a necessary migration step, not something to assume. This is one reason organizations pilot post-quantum signing in non-production environments before committing.

What is dual or hybrid code signing?

Dual or hybrid signing means signing an artifact with both a classical algorithm (such as RSA or ECDSA) and a post-quantum algorithm (such as ML-DSA) during the transition period. Older verification clients that do not yet understand post-quantum signatures can still validate the classical signature, while newer clients gain quantum resistance from the post-quantum one. It is a practical way to migrate without breaking compatibility for systems that have not yet been updated.

Do I need to move to post-quantum code signing now?

For long-lived signed artifacts, yes, planning should start now. Firmware, drivers, and system images signed today may be verified years from now, when a quantum computer could forge classical signatures, and in many systems the verification algorithm is hard to change after deployment. CNSA 2.0 treats code and firmware signing as a top-priority migration area and sets an aggressive timeline. Starting with inventory and a non-production pilot lets you migrate deliberately rather than under pressure.

Move Your Code Signing to Quantum-Safe Algorithms

Post-quantum code signing is as much an operational challenge as an algorithm choice: HSM support, state management, and dual signing all have to work together. Explore CodeSign Secure to sign with ML-DSA and hash-based LMS and XMSS against HSM-protected keys, with automated state tracking and full audit.