Every major post-quantum migration story in 2026 centers on ML-KEM and ML-DSA, the lattice-based algorithms NIST finalized in August 2024. But there’s a second, quieter category of quantum-resistant signatures that already has a hard deadline attached to it: stateful hash-based signatures. The NSA’s Commercial National Security Algorithm Suite 2.0 requires new national security systems to support quantum-resistant cryptography starting January 1, 2027, and for firmware and software signing specifically, the approved tools aren’t ML-DSA or SLH-DSA. They’re LMS and XMSS, two schemes that have quietly protected Cisco firmware updates for over a decade.
Both algorithms are final, standardized, and already shipping in production code. Neither gets the attention ML-KEM gets. This comparison breaks down the real differences between LMS and XMSS: signature sizes, performance, library support, pricing for the infrastructure that backs them, and the operational trap that makes both of them far more dangerous to deploy carelessly than RSA or ECDSA ever were.
If you only remember one distinction from this article, make it this one: LMS and XMSS are not a safer drop-in replacement for your existing RSA or ECDSA signing key. They’re a different operating model entirely, one where the private key has a finite, countable number of uses and where reusing one by accident can hand an attacker the ability to forge your firmware signatures. Everything else in this comparison, sizes, speed, library maturity, pricing, sits downstream of that one structural fact.
What Are LMS and XMSS? Inside NIST’s Stateful Signature Standards
LMS (Leighton-Micali Signatures) and XMSS (eXtended Merkle Signature Scheme) are both digital signature schemes built entirely from hash functions rather than number-theoretic problems like factoring or discrete logarithms. That matters because hash-based security rests on assumptions, like preimage and second-preimage resistance, that nobody expects a quantum computer to break. Shor’s algorithm threatens RSA and elliptic-curve math; it does nothing to SHA-256.
LMS comes from IETF RFC 8554, published in April 2019 and co-authored by Cisco engineers David McGrew, Scott Fluhrer, and Michael Curcio. XMSS comes from RFC 8391, published in May 2018. Both were folded into a single federal recommendation, NIST SP 800-208, finalized on October 29, 2020. SP 800-208 doesn’t approve every parameter set in the RFCs; it narrows the field down to specific profiles NIST considers safe for government use, along with the hierarchical multi-tree variants HSS (for LMS) and XMSS^MT (for XMSS).
Structurally, both schemes build a Merkle tree over many one-time-signature key pairs. LMS uses the Leighton-Micali one-time signature (LMOTS) construction. XMSS uses WOTS+ (Winternitz One-Time Signature Plus). The tree’s root becomes the public key; each leaf signs exactly one message before it’s retired. That one detail, “retired after one use,” is the whole story of why these algorithms are powerful and why they’re risky.
Why Stateful Hash-Based Signatures Still Matter in 2026
ML-DSA, the NIST-standardized descendant of Dilithium, is stateless: you can sign as many messages as you want with no bookkeeping. So why would anyone choose a scheme that demands careful state tracking? Because the NSA doesn’t fully trust the newer lattice math yet, at least not for every use case.
According to the NSA’s CNSA 2.0 FAQ, SLH-DSA (the stateless hash-based alternative, standardized as FIPS 205) is not approved for use in National Security Systems at all, and FN-DSA (Falcon, still in draft as FIPS 206) isn’t available yet, with the agency reportedly favoring ML-DSA over Falcon because Falcon’s implementation is seen as more prone to security-breaking mistakes. For firmware and software signing specifically, where the signer is a tightly controlled build server rather than millions of independent users, CNSA 2.0 leans on the older, more conservative LMS and XMSS instead, as detailed in wolfSSL’s breakdown of the CNSA 2.0 hash-based signature guidance.
That’s the frame for this whole comparison: LMS and XMSS aren’t competing with ML-DSA for general-purpose TLS or email signing. They’re competing with each other for a narrower job, signing firmware, bootloaders, and software updates, where a single organization controls the signer and can enforce the state discipline both schemes demand.
LMS/XMSS vs ML-DSA and SLH-DSA: Where Stateful Signatures Fit
It helps to place LMS and XMSS on the same map as the other post-quantum signature schemes NIST has already standardized, because the four options aren’t interchangeable. ML-DSA (FIPS 204) is stateless, fast to sign and verify, and sits at the center of the broader PQC migration story, TLS, code repositories, certificate chains, anywhere a signer can’t realistically track per-key state. SLH-DSA (FIPS 205) is also stateless and leans on even more conservative hash-based assumptions than ML-DSA, trading much larger signatures for an extra layer of mathematical conservatism, yet the NSA still excludes it from National Security System use under CNSA 2.0.
LMS and XMSS occupy a third category entirely: stateful, hash-based, and deliberately restricted to controlled signing authorities. They’re not safer or less safe than SLH-DSA in a pure cryptographic sense, they’re accepted for a different operational model. A build server that signs firmware once per release and can guarantee exclusive control over a signing index is exactly the environment where the state-management cost pays for itself in smaller signatures and faster verification than SLH-DSA offers. A certificate authority issuing millions of independent end-user certificates is exactly the environment where that same state requirement becomes untenable. Understanding which category your use case falls into is the real first step in this comparison, long before you decide between LMS and XMSS specifically.
LMS vs XMSS: Full Specification Comparison
The table below lines up the two schemes across the specs that actually drive a deployment decision.
| Specification | LMS / HSS | XMSS / XMSS^MT |
|---|---|---|
| Governing RFC | RFC 8554 (April 2019) | RFC 8391 (May 2018) |
| NIST federal profile | SP 800-208 (final, Oct. 29, 2020) | SP 800-208 (final, Oct. 29, 2020) |
| Security basis | Hash function one-wayness (SHA-256 common) | Hash function one-wayness (SHA-256 common) |
| One-time signature scheme | LMOTS | WOTS+ (Winternitz OTS Plus) |
| State model | Stateful — leaf index must never repeat | Stateful — leaf index must never repeat |
| Multi-tree variant | HSS (Hierarchical Signature System) | XMSS^MT (multi-tree XMSS) |
| Public key size (SHA-256, n=32) | 56 bytes (single tree) | 68 bytes (single tree) |
| Signature size at height 10 | ~1,432 bytes | ~2,500 bytes |
| Signature size at height 20 | ~1,752 bytes | ~2,820 bytes |
| Primary real-world use case | Firmware/software signing (Cisco) | Bootloader verification on select platforms |
| Quantum resistance basis | Hash functions (not number theory) | Hash functions (not number theory) |
| CNSA 2.0 status | Approved for specified signing use cases | Approved for specified signing use cases |
| CAVP validation | Available | Available |
The headline takeaway from that table is simple: LMS signatures are consistently smaller than XMSS signatures at the same tree height, because LMOTS uses fewer hash-chain elements than WOTS+. XMSS compensates with a more extensively documented tree-traversal design and a wider published menu of standardized parameter sets.
Signature and Key Sizes: The Byte-for-Byte Breakdown
Tree height determines how many signatures a single key pair can issue before it’s exhausted, and it directly sets signature size for both schemes. A height-10 tree gives you 1,024 signatures; height-20 gives you over a million. Here’s how that scales for each algorithm using SHA-256 with n=32, per the wire-format math defined in RFC 8554 and RFC 8391.
| Tree height (h) | Signature capacity | LMS signature size | XMSS signature size |
|---|---|---|---|
| 5 | 32 signatures | ~1,272 bytes | n/a (impractically small tree) |
| 10 | 1,024 signatures | ~1,432 bytes | ~2,500 bytes |
| 15 | 32,768 signatures | ~1,592 bytes | ~2,660 bytes |
| 16 | 65,536 signatures | ~1,624 bytes | ~2,692 bytes |
| 20 | 1,048,576 signatures | ~1,752 bytes | ~2,820 bytes |
Public keys stay flat regardless of tree height for both schemes (56 bytes for LMS, 68 bytes for XMSS), since the public key is just the Merkle root plus a few format bytes. Private-key representations vary by implementation: the RFCs define a minimal seed-based form, but production systems typically also need to persist traversal state, which is where storage requirements balloon well beyond the “56 bytes” headline figure. Need more signing capacity than a single tree supports? That’s what HSS and XMSS^MT exist for, chaining multiple trees in a hierarchy so you never have to pre-generate one astronomically large tree up front.
Performance Benchmarks: Signing, Verifying, and Tree Generation
Benchmarking LMS against XMSS honestly is harder than it sounds, because published numbers come from different CPUs, different hash implementations, and different tree heights. Three things are consistent across the sources that do exist.
First, from the RFC size formulas themselves (RFC 8554, RFC 8391): verification cost for both schemes scales with tree height, since a verifier has to walk the full Merkle authentication path and recompute the one-time-signature chain. Neither scheme is “fast” verification in the way ECDSA is, but both are predictable and cheap enough for firmware-update checks that happen once per boot or once per update cycle, not thousands of times per second.
Second, per NIST SP 800-208 and the project’s own documentation at NIST’s Stateful Hash-Based Signatures page, signing cost is dominated by tree-traversal bookkeeping rather than raw hashing. Implementations that precompute the full tree get fast, uniform signing latency at the cost of large upfront storage; implementations that compute authentication paths on demand use far less memory but accept slower, less uniform signing time. That tradeoff applies to both LMS and XMSS equally. It’s an implementation decision, not an algorithm-level one.
Third, library-level documentation from wolfSSL’s post-quantum product page, which implements both RFC 8554 and RFC 8391 directly in wolfCrypt, confirms that LMS’s smaller LMOTS construction generally produces faster signing per operation than XMSS’s WOTS+ construction at comparable security margins, while XMSS’s broader standardized parameter menu (XMSS-SHA2_10_256, XMSS-SHA2_16_256, XMSS-SHA2_20_256, and SHAKE variants) gives implementers more flexibility to tune the size-versus-speed tradeoff. Neither advantage is dramatic enough to override the other factors in this comparison: ecosystem support, existing deployment, and operational state-management tooling matter more than a modest cycle-count edge.
One performance variable both schemes share: Grover’s algorithm, the quantum search speedup that applies to generic hash problems, only grants an attacker a quadratic advantage, not the exponential break Shor’s algorithm gives against RSA or elliptic curves. That’s why SHA-256 (producing 256-bit output) rather than a smaller hash was chosen for the common LMS and XMSS parameter sets profiled in SP 800-208, it preserves roughly 128 bits of post-quantum security margin even after accounting for Grover. Verification time on commodity server hardware for either scheme at height 10 to 20 is measured in low single-digit milliseconds in most documented implementations; the real latency cost shows up during initial key generation and tree construction, not during routine signing or verification once the tree already exists.
The State-Reuse Catastrophe: Both Schemes’ Shared Weakness
Here’s the part that makes LMS and XMSS fundamentally different from RSA, ECDSA, Ed25519, or even ML-DSA: the private key is not safely clonable. Every signature consumes one leaf of the Merkle tree, and that leaf can never be used again. Sign twice with the same leaf, using two different messages, and an attacker who sees both signatures can potentially recover enough of the one-time-signature key material to forge new signatures under that identity.
This isn’t a theoretical edge case; it’s the single biggest operational risk in deploying either scheme. A restored backup that rolls the signing index backward, two signer replicas that both think they own the next unused leaf, a crash that loses an in-flight state update, or simple human error in a disaster-recovery drill can all trigger leaf reuse. The RFCs define the cryptography; they say nothing about how to prevent this in production, so that burden falls entirely on the implementer.
Standard mitigations that production deployments rely on include storing the signing index in tamper-resistant hardware or protected non-volatile memory, allocating disjoint index ranges across signer replicas instead of sharing one counter, treating “reserve index, then sign” as an atomic transaction, blocking backup-and-restore operations that could roll state backward, and separating a rarely-used offline root key from a more frequently used online signing key. This is precisely why both schemes are approved only for controlled signing authorities, like a firmware build pipeline, rather than for open-ended, high-volume signing by independent devices or users.
It’s worth contrasting this against how RSA and ECDSA private keys behave. Clone an RSA private key onto a second server and both servers can sign indefinitely without any coordination, the keys don’t know or care how many signatures have already been produced. Clone an LMS or XMSS private key onto a second server, and you’ve just created two signers that can both reach for the same unused leaf at the same time, with no built-in mechanism to detect the collision until an attacker exploits it. High-availability architectures built around traditional PKI assumptions, active-active signing nodes, hot failover, routine key export for backup, all need to be redesigned around exclusive, auditable leaf allocation before a stateful scheme can be deployed safely.
HSS vs XMSS^MT: Scaling Beyond a Single Tree
A single Merkle tree at height 20 supports just over a million signatures, which sounds like a lot until you consider a firmware vendor shipping updates across a large device fleet for a decade. Both schemes solve this the same way: chain multiple smaller trees into a hierarchy instead of building one enormous tree.
HSS (Hierarchical Signature System) is LMS’s answer; XMSS^MT is XMSS’s. Both reduce the cost and latency of initial key generation, since you only need to build the top-level tree immediately and can generate subordinate trees lazily or offline. Both also make key rollover more manageable: if a lower-level tree is compromised or exhausted, you can replace it without touching the root. The tradeoff is signature size: a multi-tree signature has to include authentication data for every level in the hierarchy, so HSS and XMSS^MT signatures run larger than their single-tree counterparts. Per wolfSSL’s CNSA 2.0 guidance, this is exactly why NIST SP 800-208 treats the multi-tree constructions as a distinct, separately profiled category rather than folding them into the base LMS/XMSS parameter sets.
Library and Platform Support in 2026
Support for these two algorithms is real but narrower than the buzz around ML-KEM and ML-DSA would suggest.
wolfSSL is the clearest, most directly documented implementation of both. Its wolfCrypt post-quantum page lists native LMS/HSS support based on RFC 8554 and XMSS/XMSS^MT support based on RFC 8391, including the SHA2_10_256, SHA2_16_256, and SHA2_20_256 parameter APIs.
Bouncy Castle has offered XMSS-family functionality in its Java and .NET APIs for several release cycles, though exact class-level support for every parameter set depends on the specific release, and should be checked against current API docs before any compliance claim.
Mainline OpenSSL does not natively ship production-ready LMS or XMSS signing in the way it ships RSA, ECDSA, or EdDSA. If a system uses OpenSSL, that alone is not evidence of LMS/XMSS capability; it typically requires separate provider modules or direct integration with a library like wolfCrypt.
liboqs, the Open Quantum Safe project’s library, focuses primarily on the newer stateless NIST algorithms (ML-KEM, ML-DSA, SLH-DSA); stateful schemes like LMS and XMSS sit outside its core design philosophy precisely because liboqs is built around stateless key generation and testing workflows, as documented on the Open Quantum Safe project page.
Real-World Deployments: Cisco, NCSC, and the Secure Boot Ecosystem
Unlike several newer post-quantum algorithms still waiting for their first production use case, LMS has a genuine, named, decade-plus deployment history.
- Cisco firmware signing. Cisco’s own Post-Quantum Trust Anchors white paper states plainly: “we use LMS to sign firmware generated at Cisco so that the device can detect modified or inauthentic binary images.” The same paper notes that Cisco’s post-quantum software-signing work traces back to 2013, using the LMS predecessor LDWM on select FPGA-based hardware.
- Cisco RFC co-authorship. Three Cisco engineers, David McGrew, Scott Fluhrer, and Michael Curcio, co-authored RFC 8554 itself, which is a strong signal of how central LMS became to Cisco’s own security architecture rather than a theoretical interest.
- Cisco UCS and Intersight hardening guides. Cisco’s published compute hardening documentation lists image signing under RFC 8554 for LMS and separately defines XMSS for bootloader and image-signing contexts, indicating both schemes are live options across Cisco’s compute security architecture, not just a single product line.
- Cisco’s quantum-safe architecture blog. Cisco’s security blog on building a quantum-safe future states that “the root of trust verifies the first-stage bootloader using a hash-based, quantum-resistant signature scheme such as LMS or XMSS (on select platforms),” confirming XMSS’s role sits specifically at the bootloader-verification layer.
- UK NCSC corroboration. The UK’s National Cyber Security Centre, in its PQC migration timelines guidance, states that “some vendors have already developed secure boot solutions based on LMS and XMSS digital signature algorithms,” and anticipates more hardware roots of trust using these NIST standards becoming available through 2025 and beyond.
What’s notably absent from the public record: a named chip vendor, HSM manufacturer, or automotive supplier beyond Cisco with a detailed, dated production deployment statement. That doesn’t mean nobody else uses these schemes, secure-boot and firmware-signing architectures are rarely publicized in detail for obvious security reasons, but it does mean Cisco remains the clearest public reference deployment as of October 2026.
That scarcity of named deployments is itself informative. Compare it to ML-KEM, which Cloudflare, Chrome, Firefox, and Edge have all discussed publicly in the context of hybrid TLS key exchange. LMS and XMSS live one layer down the stack, inside secure boot ROM, firmware update servers, and build-pipeline signing infrastructure that vendors treat as sensitive internal tooling rather than a marketing talking point. For a team evaluating these algorithms, the practical implication is that you should expect to do more of your own validation work and lean more heavily on the RFCs and NIST SP 800-208 directly, rather than assuming a large ecosystem of public case studies and third-party audits will do that work for you.
Pricing and Cost: HSMs, Cloud Signing, and Compliance Overhead
There’s no “buy an LMS certificate” product the way there’s a TLS certificate market, because LMS and XMSS protect firmware-signing pipelines, not public-facing TLS endpoints. The real cost driver is the HSM or key-management infrastructure needed to protect signing state and prevent leaf reuse. Here’s what the general-purpose key-management market actually charges today.
| Service | Pricing model | Verified rate |
|---|---|---|
| AWS CloudHSM | Per HSM instance-hour | ~$1.60/hour (~$1,152/month at 720 hrs) |
| AWS KMS (customer-managed key) | Per key per month, plus API calls | $1.00/key/month; $0.03 per 10,000 requests above free tier |
| Google Cloud HSM (via Cloud KMS) | Per active key version per month | $1.00/mo (AES-256, RSA-2048); $2.50/mo (RSA-3072/4096, EC P-256/P-384) for first 2,000 versions |
| Google Cloud HSM (single-tenant instance) | Per instance-hour | ~$4.79/hour, 15,000 key versions included |
| Azure Dedicated HSM | Published pricing page, rate region/plan-dependent | Not independently verified to an exact figure — see Azure’s pricing page |
| Thales Luna (on-prem HSM appliance) | Enterprise quote | Quote-based; no public list price |
| wolfSSL wolfCrypt / wolfBoot commercial license | License/quote | Quote-based; no public list price |
Note what this table says implicitly: none of the big three cloud KMS providers currently advertise native LMS or XMSS key generation as a managed service. Organizations deploying these algorithms today are generally building custom signing infrastructure on top of wolfCrypt or similar libraries, backed by a general-purpose HSM for key and state protection, rather than buying an off-the-shelf “post-quantum signing” SKU. Budget for custom integration work on top of whichever HSM tier you choose.
That integration cost is usually the larger line item, not the HSM rental fee itself. A team adopting AWS CloudHSM at roughly $1,152 a month for a single instance still has to build the leaf-index reservation logic, the atomic state-update transaction, the backup-rollback protection, and the monitoring that alerts on tree exhaustion, none of which ships out of the box with a generic HSM. Organizations that already run an HSM for RSA or ECDSA code signing can often repurpose that same hardware for LMS or XMSS state storage, which makes the marginal cost of adding a stateful hash-based signature path considerably lower than starting from zero. Factor engineering time into any budget comparison, not just the monthly infrastructure bill.
CNSA 2.0 and the January 2027 Deadline
The compliance clock that makes this comparison urgent is CNSA 2.0, the NSA’s Commercial National Security Algorithm Suite. According to wolfSSL’s published CNSA 2.0 analysis, NIST SP 800-208 approves LMS and XMSS specifically, while the multi-tree HSS and XMSS^MT constructions carry separate, narrower approval scope for National Security System use.
January 1, 2027 is widely cited as a CNSA 2.0 transition milestone requiring new or upgraded National Security Systems to begin using approved post-quantum mechanisms. It’s important not to overstate the scope here: this is a National Security System requirement, not a blanket commercial mandate. Civilian federal agencies face a separate, later timeline, and purely commercial software vendors face no direct CNSA 2.0 obligation at all unless they sell into the NSS space. What the deadline does do is set the pace for the defense and intelligence supply chain, and for any commercial vendor that wants to sell firmware-signing or secure-boot products into that market, LMS and XMSS compliance stops being optional well before 2027 arrives.
Migration Guide: Moving From RSA/ECDSA to LMS or XMSS
Migrating a firmware-signing pipeline off RSA or ECDSA isn’t a drop-in algorithm swap, because the state-management requirement changes the entire operational model. Here’s the realistic sequence.
- Inventory every signer. Identify every system, build server, HSM, or CI pipeline stage that currently holds a private signing key. Stateful schemes require you to know exactly how many signers exist, because you can’t let two signers share one counter.
- Choose single-tree or hierarchical. Estimate total signatures needed over the product’s lifecycle. If it’s comfortably under a million, a single LMS or XMSS tree at height 20 may suffice. For long-lived product lines or high release cadence, plan for HSS or XMSS^MT from day one, migrating a hierarchy later is harder than building one upfront.
- Select your library. wolfSSL’s wolfCrypt currently offers the most directly documented implementation of both RFC 8554 and RFC 8391. Evaluate Bouncy Castle if your stack is Java or .NET-based.
- Design the state-protection layer first. Before writing any signing code, decide how the leaf index will be stored, how index reservation will be made atomic, and how backups will be prevented from rolling state backward. This is the step teams skip and regret.
- Run RSA/ECDSA and LMS/XMSS in parallel. Dual-sign firmware images with both the legacy algorithm and the new hash-based signature during a transition window, so older devices without updated verification logic still accept images.
- Update verifier code on every device. Devices in the field need firmware or bootloader updates that can parse and verify the new signature format before you can retire the legacy algorithm.
- Monitor remaining leaf capacity continuously. Build alerting for tree exhaustion well before it happens; regenerating or rolling to a new subtree under deadline pressure is how state-reuse mistakes happen.
- Document the CNSA 2.0 compliance mapping. If you’re selling into the NSS space, keep a clear record of which SP 800-208 parameter profile each product uses, since auditors will ask.
- Plan key rollover before you need it. Decide in advance how a lower-level HSS or XMSS^MT tree gets replaced when it’s exhausted or suspected of compromise, and rehearse that rollover in a staging environment rather than discovering the process for the first time during an incident.
- Retire the legacy algorithm on a published timeline. Once field telemetry confirms the overwhelming majority of deployed devices can verify the new signature format, set a hard date to stop dual-signing. Running two signature schemes indefinitely doubles your signing infrastructure’s attack surface and operational complexity for no lasting benefit.
Best Use Cases for LMS vs XMSS
Both algorithms solve the same narrow problem, but a handful of situational factors tip the choice one way or the other.
- Choose LMS when signature size is the binding constraint. Bandwidth-constrained firmware delivery, like over-the-air updates to low-power IoT devices on cellular or LPWAN links, benefits from LMS’s smaller signatures at every tree height.
- Choose LMS when you want Cisco’s track record behind you. A decade of production use in a major network-equipment vendor’s firmware pipeline is a meaningful risk signal for teams that want the most battle-tested option.
- Choose XMSS when you need bootloader-layer verification on select platforms. Cisco’s own documentation specifically ties XMSS to first-stage bootloader verification, suggesting it has an edge in that narrower verification context.
- Choose XMSS when you want more published parameter flexibility. XMSS’s broader standardized set of height and hash-function combinations gives implementers more room to tune the size-versus-capacity tradeoff without leaving the standard.
- Choose HSS over single-tree LMS for decade-plus product lines. Automotive, industrial control, and telecom infrastructure vendors shipping updates over 10+ year lifecycles should default to the hierarchical variant from the start.
- Choose neither if your signer isn’t tightly controlled. If you need many independent devices or users signing unpredictably, without centralized state coordination, a stateless scheme like ML-DSA is the safer architectural fit, full stop.
- Choose wolfSSL’s implementation if speed-to-deployment matters. It’s the most directly documented, actively maintained option for both algorithms as of late 2026.
Pros, Cons, and the Verdict
LMS pros: smaller signatures at every tested tree height, a real decade-long Cisco production deployment, RFC co-authored by engineers who actually ship it, native wolfCrypt support. LMS cons: fewer independently published parameter-set options than XMSS, same state-reuse risk as XMSS, limited library support outside wolfSSL and a handful of specialized toolchains.
XMSS pros: broader published parameter menu (SHA2 and SHAKE variants across multiple heights), documented role at the bootloader-verification layer, Bouncy Castle support for Java/.NET shops, strong academic pedigree. XMSS cons: consistently larger signatures than LMS at matching tree heights, the same catastrophic state-reuse failure mode, and thinner public evidence of large-scale production deployment beyond Cisco’s bootloader use.
The verdict: for pure firmware and software signing where minimizing signature size matters, LMS wins on the numbers, roughly 1,432 bytes versus 2,500 bytes at height 10, a margin that compounds across every update you ship. For bootloader-level verification specifically, Cisco’s own architecture suggests XMSS has a defensible, documented niche. Neither algorithm is a general-purpose RSA or ECDSA replacement, and neither should be deployed without a state-management design that’s been reviewed as carefully as the cryptography itself. If you’re choosing blind with no existing vendor lock-in, start with LMS: it has the smaller signatures, the clearer production track record, and the most actively maintained open implementation in wolfCrypt.
Frequently Asked Questions
Are LMS and XMSS actually quantum-resistant?
Yes. Both derive their security entirely from hash-function properties rather than factoring or discrete-log problems, so Shor’s algorithm offers no advantage against them. Grover’s algorithm provides only a quadratic speedup against generic hash search, which is why doubling output size (moving to SHA-256 instead of a smaller hash) restores the intended security margin.
What happens if a leaf index gets reused?
Reusing a one-time-signature leaf to sign two different messages can leak enough information about that leaf’s private key material for an attacker to forge additional signatures under it. This is the single most serious operational risk in deploying either scheme and the reason both are restricted to tightly controlled signers.
Can I use LMS or XMSS for TLS or general-purpose signing?
No. Both are approved specifically for controlled, low-volume signing contexts like firmware and software signing. General-purpose, high-volume, or multi-party signing scenarios should use a stateless scheme like ML-DSA instead.
Is LMS or XMSS faster?
Documentation from wolfSSL’s implementation indicates LMS’s LMOTS construction generally signs faster per operation than XMSS’s WOTS+ construction at comparable security levels, though both are dominated by tree-traversal overhead rather than raw hash speed, and implementation choices affect this more than the algorithm itself.
Does CNSA 2.0 require every company to adopt LMS or XMSS by January 2027?
No. The January 2027 milestone applies to new or upgraded National Security Systems. Civilian federal agencies and purely commercial vendors outside the NSS supply chain face different timelines and, in many cases, no direct CNSA 2.0 obligation at all.
Why doesn’t NIST just require ML-DSA for firmware signing instead?
ML-DSA is newer and stateless, which is operationally simpler, but LMS and XMSS rest on more conservative, decades-old hash-security assumptions. For a signing authority as sensitive as firmware and bootloader trust anchors, that conservatism carries real weight with standards bodies and the NSA.
What’s the difference between LMS and HSS, or between XMSS and XMSS^MT?
LMS and XMSS are the single-tree versions of each scheme, limited to the signature capacity of one Merkle tree. HSS and XMSS^MT are their hierarchical, multi-tree counterparts, chaining several smaller trees together so a key pair can issue far more signatures over its lifetime, at the cost of a larger signature that has to carry authentication data for every level of the hierarchy.
Do I need a hardware security module to deploy LMS or XMSS safely?
It’s strongly recommended but not cryptographically mandatory. An HSM makes it far easier to guarantee atomic, tamper-resistant state updates and prevent rollback, which directly reduces the risk of catastrophic leaf reuse.
Which open-source library should I start with?
wolfSSL’s wolfCrypt currently offers the most directly documented native support for both RFC 8554 (LMS/HSS) and RFC 8391 (XMSS/XMSS^MT). Java and .NET teams should also evaluate Bouncy Castle’s XMSS implementation.
