While most of the post-quantum conversation in 2026 fixates on ML-KEM and ML-DSA, the lattice-based algorithms NIST finalized in August 2024, a narrower and arguably more urgent deadline is bearing down on firmware and software signing. The NSA's Commercial National Security Algorithm Suite 2.0 requires new national security systems to support quantum-resistant cryptography by January 1, 2027, and for signing code, the approved tools are not the algorithms dominating headlines. They are LMS and XMSS, two stateful hash-based signature schemes that have already been protecting Cisco firmware updates for more than a decade.
Two Standards Built on Hash Functions, Not Number Theory
LMS, formalized in IETF RFC 8554 and co-authored by Cisco engineers, and XMSS, published as RFC 8391, both derive their security from the one-wayness of hash functions like SHA-256 rather than the factoring or discrete-logarithm problems that Shor's algorithm threatens. NIST consolidated both into a single federal profile, SP 800-208, finalized in October 2020, which narrows the broader RFCs down to parameter sets considered safe for government use and adds the hierarchical variants HSS and XMSS^MT. Structurally, each scheme builds a Merkle tree over many one-time-signature key pairs, LMS using the LMOTS construction, XMSS using WOTS+, with the tree's root serving as the public key.
Why the NSA Still Wants Hash-Based Signatures
ML-DSA is stateless, meaning a signer can produce unlimited signatures without tracking anything. So why does CNSA 2.0 lean on something more operationally demanding? Because, according to the NSA's own FAQ, SLH-DSA is not approved for national security systems at all, and FN-DSA (Falcon) remains unfinished. For firmware and software signing specifically, where a single tightly controlled build server does the signing rather than millions of independent users, LMS and XMSS offer a more conservative, already-proven alternative. That narrower job, not general-purpose TLS or email, is where these two schemes actually compete with each other.
Smaller Signatures, Shared Risk
Across comparable tree heights, LMS consistently produces smaller signatures than XMSS, since LMOTS uses fewer hash-chain elements than WOTS+. At a tree height of 20, supporting over a million signatures, LMS runs roughly 1,752 bytes against XMSS's roughly 2,820 bytes, according to the wire-format math defined in their governing RFCs. Public keys stay compact and flat for both, 56 bytes for LMS, 68 bytes for XMSS, regardless of tree height. XMSS compensates with a wider published menu of standardized parameter sets, including SHAKE variants, giving implementers more room to tune the size-versus-speed tradeoff documented in wolfSSL's post-quantum library work.
The Operational Trap That Makes Both Schemes Unforgiving
The structural fact that overshadows every size and speed comparison is this: every signature consumes one leaf of the Merkle tree, and that leaf can never be reused. Sign twice from the same leaf with two different messages, and an attacker who observes both signatures can potentially reconstruct enough one-time-signature material to forge new signatures under that identity. Unlike RSA or ECDSA keys, which can be cloned and reused freely, an LMS or XMSS private key has a finite, countable number of uses, and the software managing it must guarantee that no leaf index is ever repeated, even across backups, failovers, or crashed build servers.
That operational discipline is the real cost of adopting either scheme. A build server that signs one firmware release at a time and can guarantee exclusive control over its signing index is exactly the environment where the tradeoff pays off, smaller signatures, faster verification, and a hash-based security basis that nobody expects a quantum computer to undermine. A certificate authority issuing certificates to millions of independent users is exactly the environment where that same requirement becomes unworkable. As the 2027 deadline approaches, organizations evaluating LMS and XMSS need to treat state management, not algorithm choice, as the central engineering problem.