LMS and XMSS Adoption: The Reality of Quantum-Resistant Signatures
Updated: Aug 4
Introduction
When organizations consider their transition plans to quantum-resistant cryptography, they often cite the associated risks with ‘Harvest Now, Decrypt Later’ (HNDL). However, assuming one sets aside the industry’s current tendency to over hype the practical reality of the storage and computational requirements associated with HNDL as depicted well in this blog Why “Harvest Now, Decrypt Later” (HNDL) may not be your main concern, a fundamental cryptographic truth remains: the HNDL threat vector exclusively concerns the risk to data confidentiality through encryption and the related decryption algorithms.
There are actually two classes of migration required to transition to post-quantum cryptography, and the other, arguably more complex migration considers that of digital signatures which provide guarantees of the authenticity and integrity of data. Digital signatures are widely used for features such as executing low-level secure boot procedures on host operating systems and anchoring the chains of trust within Public Key Infrastructure (PKI).
On August 13, 2024 NIST released the final standards for digital signatures: Module-Lattice-Based and Stateless Hash-Based digital signature algorithms in FIPS 204 and FIPS 205 respectively. However, there have been quantum-resistant Stateful Hash-Based signature schemes standardized by the IETF and NIST between 2018 - 2020.
The Stateful HBS schemes described within the IETF and NIST standards in RFC 8391, RFC 8554, and SP 800-208 cover the Leighton-Micali Signatures (LMS), and the eXtended Merkle Signature Scheme (XMSS) and their multi-tree variants Hierarchical Signature System (HSS) and XMSS Multi-Tree (XMSS-MT). Although these schemes have longer standing standards, there are several reasons why LMS and XMSS have not been adopted in a mainstream fashion.
In this blog we explore a number of operational constraints, hidden bottlenecks, and challenging compliance requirements that should be considered by those looking to implement Stateful HBS schemes as part of their transition to quantum-resistant digital signatures.
Background to LMS and XMSS signatures
Stateful HBS schemes rely on the well-studied security properties of the underlying hash function such as SHA-256 or eXtendable-Output Functions (XOFs) such as SHAKE256. LMS and XMSS use Merkle trees and variants of the Winternitz One Time Signature (WOTS) scheme to create digital signatures resistant to a Cryptographically Relevant Quantum Computer (CRQC) running Shor’s algorithm. For a superb overview of Shor’s algorithm I recommend Computerphiles most recent video Shor's Algorithm for Quantum Computing - Computerphile.
LMS and XMSS private keys consist of a fixed number of WOTS keys. Each time a WOTS key is used, its state information must be updated, recorded, and immutably preserved to prevent reuse. If a WOTS private key were to sign more than one message, it would significantly increase the risk of a digital signature forgery.
The purpose of a Merkle tree in a Stateful HBS scheme is to efficiently manage and verify a large number of WOTS keys in a balanced binary tree. The height of the Merkle tree dictates the number of leaf nodes, each of which corresponds to a unique OTS public verification key. Therefore, a taller Merkle tree allows for more OTS keys, enabling the signing of a larger number of messages. This relationship is crucial for planning the capacity of the signature scheme over its intended lifespan as all keying material must be generated when the scheme is instantiated. Furthermore, although a taller Merkle tree allows for a larger number of OTS keys, it comes at a cost of a larger signature size and longer compute times for the generation of a digital signature.
Finally, as LMS and XMSS have strict requirements to maintain state and have a fixed number of OTS keys upon instantiation, these signature schemes are not intended for general use cases such as the use of security parameter signing in interactive protocols, such as TLS.
The last statement is the key aspect to why LMS and XMSS have not achieved mainstream adoption. The point is, they were never meant to.
The NIST SP 800-208 guidance also makes this point clear.
it is necessary to implement a digital signature scheme in the near future
the implementation will have a long lifetime
it would not be practical to transition to a different digital signature scheme once the implementation has been deployed
Finally, a large motivational factor in the early adoption of Stateful HBS schemes is the guidance provided by the NSA for their CNSA 2.0 Requirements for US National Security Systems (NSS) as seen below in Figure 1.
Figure 1: CNSA 2.0 Adoption Timeline, Source: CNSA Algorithm Suite 2.0
As we are already in 2026, there is a good chance that systems supporting US NSS software and firmware signing have already adopted Stateful HBS schemes across military, defense, and critical national infrastructure where the three requirements in SP 800-208 noted above are the driving factors for adoption. Furthermore, the CNSA 2.0 algorithm suite does not include the Stateless HBS scheme defined in FIPS 205 and support for lattice-based ML-DSA may not be suitable due to limitations on computationally constrained hardware-based cryptography, which we will discuss in Section Evidence of LMS and/or XMSS support.
For more technical information about LMS and XMSS schemes the following blog provides a balanced overview of these algorithms Leighton-Micali Hash-Based Signatures using Bouncy Castle and C#.
A Practical Use Case for Stateful HBS Deployment
Both the CNSA 2.0 FAQ and the NIST SP 800-208 indicate that the most likely use cases for LMS and XMSS signatures are for use cases such as firmware and software signing. Both the NSA and NIST indicate the importance of firmware signing in particular due to the inherent challenges in changing signature verification algorithms once deployed. Firmware signatures may need to be verified decades after the signature is generated and verification routines may be part of an immutable hardware-based implementation.
To analyse the operational realities of Stateful HBS, we utilize an implementation profile modelled after Thales deployment metrics. Our baseline scenario assumes an organization must issue secure firmware signatures across four standalone product lines.
We will assume that an organization requires firmware signatures for four product lines. The order of magnitude will be one signature per product line per day, and most importantly we will assume each product has a life span of 25 years. This latter point is the most essential when we consider the challenges associated with the maintenance of state for LMS and XMSS signatures.
With the scene set, let’s look at the well-known and lesser-known challenges of these schemes.
The Well Known Challenges of Stateful HBS Adoption
State Maintenance
Perhaps the biggest limiting factor in adopting LMS or XMSS in a practical setting is the requirement to reliably maintain state. Recall that both LMS and XMSS are built upon One-Time Signature (OTS) schemes. Therefore, the signing architecture must ensure that an OTS private key is only ever used to sign one message. If an OTS private key were to sign more than one message then it becomes computationally feasible for an adversary to forge a signature on an arbitrary message. Therefore, the need to maintain state is an essential property to ensure the unforgeability of these signature schemes.
The requirements to maintain state are strict and rigorous if your implementation is to conform to the SP 800-208 standard. In fact, to conform to CNSA 2.0 guidance no waivers are permitted to any of the state requirements outlined in the SP 800-208 standard.
Hardware Requirements
The SP 800-208 standard makes explicit that a Stateful HBS implementation must perform the key generation and signature on a vetted hardware platform. This hardware must be FIPS 140-2 or FIPS 140-3 validated (bear in mind now that you can no longer obtain FIPS 140-2 certification. In fact any FIPS 140-2 certifications will move into NIST’s ‘historical’ list in September 2026, which may not be suitable for high assurance cryptographic environments FIPS 140-3 Transition Effort ). Of course, signature verification can happen in a software or hardware based environment as only public keys are required.
Table 1 below outlines the other requirements in hardware for an LMS or XMSS digital signature scheme for conformance to the SP 800-208 standard and provides a note on how typical the requirement is when compared to other digital signature schemes.
Item | Requirement | Prevalence |
|---|---|---|
1 | Cryptographic modules must be FIPS 140-2/3 Level 3 or higher. (see note above on Historical status as of September 2026). | A standard requirement for high assurance environments. However, popular public cloud HSMs do not support Stateful HBS. |
2 | Key generation and signature algorithms must occur in an approved mode ‘FIPS’ operational mode. | A standard requirement for high assurance environments. |
3 | Random Bit Generator must be SP 800-90 series compliant. | A standard requirement for high assurance environments. |
4 | Cryptographic module must not allow private key export. | A standard requirement for high assurance environments which can be controlled by policies on the HSM. |
5 | Each time a key is used an increment indicating the use of this key must be stored in non-volatile storage before exporting a signature or accepting another request to sign a message. | A non-standard requirement for other digital signature schemes and is specific to stateful schemes. |
Table 1: Cryptographic Module requirements for LMS and XMSS implementations conforming to SP 800-208
Wait, no backups?
Organizations may currently have policy-based rules conforming to Item 4 for current classical digital signature schemes, such as those which conform to the FIPS 186-5 standard. That is, an organization may wish to limit private key export for digital signature schemes like RSA, ECDSA, or EdDSA. However, this typically does not preclude the ability to perform a backup of the keying material to an appropriately validated FIPS 140-2 or FIPS-140-3 Level 3 or higher backup solution.
However, because state maintenance must be stored in non-volatile storage to conform to Item 5, this precludes the ability to perform a backup of the private keying material associated with LMS and XMSS digital signature schemes.
There is a great blog on this topic from PQShield.
Ultimately the limitations for backups result in the requirement to have a considerably resilient HSM deployment to ensure that state information has the appropriate level of long term fault tolerance in the design. Due to the strict requirement to restrict backups, this limits the maintenance of state on a software-defined solution, such as a suitably resilient database. This then leaves the option to consider a cloud deployment or an on premise deployment, which we consider next.
Can I use a cloud HSM?
To consider if a cloud HSM is appropriate for LMS and XMSS signatures we first need to focus on Item 1, the requirement for the cryptographic module to be FIPS 140-2 or FIPS 140-3 Level 3 validated hardware.
Unfortunately, although the big 3 public cloud providers AWS, Microsoft Azure, and GCP all have the correct level of FIPS validation, none of their implementations support LMS or XMSS as can be seen in Table 2.
Cloud | FIPS 140-2/3 Level 3 certificate | LMS or XMSS support |
|---|---|---|
AWS | FIPS 140-2 Certificate #4218 (Historical) FIPS 140-3 Certificate #4703 (Active) | No |
Microsoft Azure | FIPS 140-3 Certificate #4700 (Active) | No |
GCP | FIPS 140-2 Certificate #4399 (Historical) | No |
Table 2: Public Cloud HSM FIPS Certificates and their lack of support for LMS or XMSS algorithms
Furthermore, if you consider the firmware signing use case intended for LMS and XMSS digital signatures and the requirement to maintain state then perhaps cloud HSMs would not meet the non-functional requirements of stateful HBS schemes. For example, even if a cloud HSM did support LMS and XMSS digital signatures, is it likely that your organization would maintain your relationship with the same cloud provider for >20 years? Remember, you cannot perform any backups of these keys, which would preclude you from having flexibility in your organization's strategic selection of cloud provider.
In our assessment the need for a FIPS validated implementation capable of maintaining the strict requirements for state maintenance will rule cloud implementations out. Furthermore, if you consider a non-functional requirement, such as the need to maintain the state of the signature scheme for >20 years, then public cloud may also be the wrong strategy.
Buy a lot of hardware and plan ahead
If leveraging resilient and fault-tolerant HSM architecture in a public cloud is largely precluded and there are limitations in SP 800-208 that forbid backing up OTS keys for LMS and XMSS, how do you mitigate hardware failure? The answer: buy more hardware.
Thales provides three reference architectures for Stateful Hash-Based signatures: Basic, High Assurance, and Offline Redundancy.
Before considering the hardware needed for fault tolerance and resiliency in these architectures, we need to address the culture shock of Stateful HBS Key Signing Ceremonies. The Thales whitepaper suggests that for firmware use cases, signature verification would occur on a hardware-based platform, requiring the signature size to remain constant throughout the product's lifespan. This means the hierarchical structure of Stateful HBS schemes must be defined and fixed during the setup, and the total number of private keys needed for the entire duration must be known in advance. We cover the different LMS parameters including signature capacity and signature size in Section Why not use Stateless Hash Based Signatures? .
This approach is a significant shift in managing Key Signing Ceremonies, akin to a ‘Waterfall Approach’. Sorry all you Agile evangelists, there is no room for you at a Stateful HBS scheme key signing ceremony.
In Figure 2 we show a diagram of a Basic reference architecture for a Stateful HBS scheme.
Figure 2: Basic Stateful HBS reference architecture example: Source Thales
Table 3 in the Thales example outlines the scaling of hardware required.
Architecture | Per Product Network HSMs required | Per Product USB HSMs required | HSM Loss Tolerance per Product | x4 Products (# of HSMs) |
Basic | 4 | 0 | 3 Network HSMs | 16 Network HSMs 0 USB HSMs |
High Assurance | 6 | 2 | 4 Network HSMs + Introduction of new HSM if needed | 24 Network HSMs 8 USB HSMs |
Offline Redundancy | 4 | 2 | 3 Network HSMs 1 USB HSM | 16 Network HSMs 8 USB HSMs |
Table 3: Thales Stateful HBS Reference Architecture HSM Hardware Requirements
If Stateful Hash-Based signatures were the only option for quantum-resistant signatures, I would advise investing in HSM hardware companies and firms offering Key Signing Ceremony consultancy to predict keying material requirements for over 20 years of operation.
Although every HSM manages keys differently, the need to maintain state on non-volatile memory for LMS and XMSS means that losing operation of an HSM results in losing the ability to sign with remaining unused keys and a loss of the state information of those OTS keys which were already used.
Consider the MTBF (mean time before failures) of an HSM. Is it over 20 years? Anyone still managing their Safenet Luna K4 device from 2005 likely has some interesting stories maintaining a legacy estate. It would be wonderful to see the contents of the Cryptographic Bill of Materials (CBOM) which reflect the persistent use of your 3DES and RSA-1024 bit keys.
The Lesser Known Challenges of Stateful HBS Adoption
XMSS Standards Gap
If you are still reading a deep dive on Stateful Hash-Based signatures, you are here to understand production-level realities, and not surface-level commentary. You are likely a deeply technical individual contributor who is an engineer, architect, or security practitioner tasked with implementing high-assurance cryptographic solutions in the real world. Navigating the operational realities of LMS or XMSS means you are dealing with a standard that is entirely unforgiving. These algorithm implementations are not implemented on architecture which you sketched out during your sprint planning. Given the stakes of managing a stateful system, you are undoubtedly looking for hard assurance that your chosen framework has been thoroughly scrutinized and validated.
So, where could you start? A good place to begin is the NIST Cryptographic Algorithm Validation Program (CAVP). Here you can check which vendors are validated to run the algorithms of a Stateful HBS scheme.
Now you will face your first challenge. NIST does not perform CAVP for XMSS. It is notably missing from its list of ‘Includes Algorithm(s)’. I am not the first to identify this notable gap. Dr Axel Poschmann also makes note of this omission in his 2025 PKI Consortium breakout presentation on Quantum-Safe Secure Boot.
At this point we are left with LMS as an option for a NIST validated Stateful HBS. This is somewhat interesting as we will see in Section Evidence of LMS and/or XMSS support, as we see both NVIDIA and STMicro with XMSS algorithm support.
The Validation Gap
Now, it is important to understand the difference between the NIST Cryptographic Algorithm Validation Program (CAVP) and the more rigorous NIST Cryptographic Module Validation Program (CMVP). CAVP checks for each algorithm and basically verifies ‘is the maths right?’. But what it does not check is all the caveats for implementation, and in the case of Stateful HBS the CAVP does not validate ‘can the maintenance of the state information for each key be trusted?'.
Aspects covering implementation such as state maintenance would be covered by the more rigorous CMVP and NIST indicates that CAVP is prerequisite to CMVP. Remember that state must be maintained as it is clear in the name: Stateful Hash-Based signature scheme. Recall that state maintenance is essential to ensure the one time use of each key to prevent digital signature forgery should a single key be used to sign more than one distinct message.
In Section XMSS Standards Gap we identified that LMS does have NIST CAVP validation for the algorithms: LMS KeyGen, LMS SigGen, and LMS SigVer. Frustratingly, there is currently no option on the NIST CMVP web form to filter for modules that support the LMS algorithms.
The LMS Validation Lag
Another point of discussion is the lag in algorithm validation dates for LMS. Remember that as far as standards are concerned the IETF released the XMSS RFC in 2018 and LMS RFC in 2019, and that NIST released the Hash-Based Signature SP 800-208 standard in 2020. Then there was a three-year lag until the first vendor could run LMS in a validated state as seen in Figure 3.
Figure 3 : Time-series of Stateful HBS standards release and NIST validated vendor adoption.
If we compare this to ML-DSA, FIPS 204 was released in August 2024 and in that year there were already six vendors validated to run this algorithm. Also, as we will see in the next section Market Reality: LMS vs ML DSA, there are now nearly 80 vendors which have CAVP for ML-DSA.
Market Reality: LMS vs ML-DSA
Stateful Hash-Based signature schemes also face the challenge of having a limited number of vendors validated to run these algorithms.
As of July 2026, there are precisely 30 entries spanning 13 distinct organizations with the NIST CAVP for LMS. If we compare this to ML-DSA there are 182 entries spanning 77 distinct organizations with NIST CAVP for ML-DSA. Nearly six times the number of organizations supporting ML-DSA is notable, especially as we identify in the Section The LMS Validation Lag that LMS was first standardized by NIST in 2020 in SP 800-208 and ML-DSA was first standardized by NIST in 2024 in FIPS 204.
In Table 4 we provide the full details of the 30 CAVP records for LMS implementations.
Vendor | Country | Implementation | Validation Number | Validation Date | Type |
|---|---|---|---|---|---|
Beijing JN TASS Technology Co., Ltd. | China | 7/17/2025 | FIRMWARE | ||
Beijing JN TASS Technology Co., Ltd. | China | 5/27/2025 | FIRMWARE | ||
Crypto4A Technologies, Inc. | Canada | 8/14/2024 | HARDWARE | ||
Crypto4A Technologies, Inc. | Canada | 1/30/2026 | HARDWARE | ||
Entrust Corporation | USA | 1/30/2026 | SOFTWARE (SDK) | ||
Fortanix, Inc. | USA | 5/22/2024 | FIRMWARE | ||
IDEMIA Secure Transactions | France | 5/28/2025 | SOFTWARE | ||
Open Security Research Inc. | China | 4/27/2026 | HARDWARE | ||
PQSecure Technologies, LLC | USA | 5/20/2025 | SOFTWARE | ||
PQSecure Technologies, LLC | USA | 10/29/2025 | SOFTWARE | ||
PQSecure Technologies, LLC | USA | 5/26/2026 | SW Hybrid | ||
PUFsecurity Corporation | Taiwan | 6/11/2025 | FIRMWARE | ||
Securosys SA | Switzerland | 12/15/2025 | FIRMWARE | ||
Securosys SA | Switzerland | 9/4/2024 | FIRMWARE | ||
Securosys SA | Switzerland | 7/9/2026 | FIRMWARE | ||
Securosys SA | Switzerland | 9/4/2024 | FIRMWARE | ||
Shanghai Uni-Sentry Intelligent Technology Co., LTD | China | 5/19/2026 | SOFTWARE | ||
Shanghai Uni-Sentry Intelligent Technology Co., LTD | China | 3/30/2026 | FIRMWARE | ||
Thales | Canada | 9/2/2025 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 1/30/2024 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 6/25/2026 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 1/30/2024 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 6/25/2026 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 3/5/2025 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 9/29/2025 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 1/16/2026 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 3/5/2025 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 9/29/2025 | FIRMWARE | ||
Thales Trusted Cyber Technologies | USA | 1/16/2026 | FIRMWARE | ||
Utimaco IS GmbH | Germany | 9/17/2025 | FIRMWARE |
Table 4: Vendors with CAVP for LMS and their country of origin, implementation details, certificate details, date of validation, and validation scope (firmware/hardware/software/hybrid).
Finally, we provide the breakdown of the vendor support by country can be seen in Figure 4.
Figure 4: Histogram of vendor support for LMS with NIST CAVP certification.
In Europe, we see three vendors across Germany, France, and Switzerland. However, for a production environment we can exclude the French entry for IDEMIA as it is a software only validation. Software alone is not capable of state maintenance. State maintenance for key usage in a one-time signature scheme must be durable in the event of graceful or ungraceful power downs. Typically hardware mechanisms such as battery backed non-volatile SRAM/NVRAM, Trusted Platform Module (TPM) monotonic counters, or One-Time-Programmable memory with one-way fuse blowing can achieve durable state maintenance required of SP 800-208.
This leaves two European vendors potentially capable of an enterprise deployment.
In North America, we have our highest distribution of vendors with LMS support with NIST CAVP certification. In total there are six vendors, however we can also preclude the entry for Entrust as it is a software development kit (SDK) offering only. An SDK alone does not possess the capability to maintain state, for the reasons noted previously.
Finally, in Asia we see four vendors offering LMS support for firmware and/or hardware deployments: three based in China and one in Taiwan. Given the ongoing geopolitical tensions between China and Taiwan, it seems reasonable to expect that organizations on either side would be reluctant to adopt cryptographic implementations sourced from a vendor based in the other country.
While I remain neutral, I have encountered procurement rules for the various organizations that I have worked for that restrict the purchase of security-based software and hardware from certain countries. I've also faced legal limitations preventing supplier on-boarding due to disagreements over non-disclosure agreements, indemnity issues, and other legal terms and conditions. In summary, having only a limited number of suppliers in specific geographic areas to choose from may not be sufficient to navigate all the corporate governance hurdles required to successfully implement a stateful HBS from a NIST vetted supplier.
Navigating the differences in standards
We have also identified that when reviewing the standards and guidance from organizations such as IETF, NIST, and the NSA they do not always align. This is not specific to Stateful HBS schemes, but it is worth illuminating some of the differences in the guidance between these organizations.
Firstly, if we consider NIST, the SP 800-208 standard provides the guidance for the use of LMS and XMSS schemes as well as their multi-tree variants HSS and XMSS^MT respectively. Table 5 below identifies the differences in the parameter sets from LMS/HSS defined in RFC 8554 and XMSS/XMSS-MT defined in RFC 8391. It also shows the preferred parameter set of the CNSA 2.0 suite.
Standard | Organization | Date Released | Parameter Set |
|---|---|---|---|
RFC 8391 (XMSS) | IETF | May 2018 | SHA-256 |
RFC 8554 (LMS) | IETF | April 2019 | SHA-256 |
SP 800-208 (LMS & XMSS) | NIST | October 2020 | SHA-256, SHA256/192, SHAKE256/256, SHAKE256/192 |
CNSA 2.0 FAQ (LMS) | NSA | December 2024 | SHA256/192 |
Table 5: Parameter sets for LMS & XMSS for IETF, NIST, and NSA standards
We then have a few subtle items to discuss. For example, although standards such as RFC 9802 refer to the CNSA 2.0 for the possible use cases which could apply to firmware signing, software signing, and CA certificates, it is worth noting that the CNSA does not approve the use of the multi-tree variants of LMS, namely HSS, or XMSS^MT. Of course the scope of applicability of the CNSA 2.0 suite is for US National Security Systems (NSS), and as such will be stricter than deployments which require a lower level of security assurance.
In Figure 5 we provide a visual guide of Hash-Based signature schemes and outline which standards and vetting programs allow the specific algorithms under the Stateful category.
Figure 5: Diagram of which Stateful Hash-Based signatures are included in NIST SP 800-208, have NIST Cryptographic Algorithm Validation, are allowed in the CNSA 2.0 suite, and are included RFC 9802.
Figure 5 demonstrates that the only Stateful HBS scheme which achieves a ‘full house’ in terms of inclusion into all areas, is the single-tree version of LMS. Of course, for non-NSS multi-tree LMS (HSS) is also a reasonable option so long as the use case is not for US NSS.
Why not use Stateless Hash-Based Signatures (SLH-DSA)?
If ML-DSA may not be suitable for embedded environments due to the requirement to support lattices, then why not pivot to Stateless Hash-Based signatures such as SLH-DSA? The simple answer is the prohibitively large digital signature size. The ability to provide a stateless HBS has a trade-off: to remove the restrictive overheads of immutable state maintenance required of stateful HBS schemes, the signature sizes become very large.
As the FIPS 205 standard indicates, the smallest signature size is 7,856 bytes for the SHA2-128s or SHAKE-128s parameter set, and the largest signature size is 49,856 bytes for the SHA2-256f or SHAKE-256f parameter set.
To support the Thales example in Section Buy a lot of hardware and plan ahead, the following parameter set could be used for a stateful LMS HBS scheme: LMS_SHA256_M32_H15 with LMOTS_SHA256_N32_W4. This would yield a signature size of 2,672 bytes. Encouragingly, this is smaller than the equivalent Stateless HBS security category. Unfortunately this still exceeds the 1500 byte MTU limit common in various embedded bus architectures, thus requiring support for network-layer fragmentation, which may not be supported. However, although only Informational in status, RFC 9858 provides additional parameter sets for LMS signatures which can further reduce the size of an LMS signature.
In Table 6 we show the different signature sizes for the LMS algorithm based on different height parameters explicitly allowed by the SP 800-208 standard. Table 6 also shows the size efficiency that could be achieved with the RFC 9858 implementation.
Merkle tree Height | Signature Capacity | Standard LMS Signature Size (Bytes) (SHA256) | Optimized LMS Signature size (SHA256)* |
|---|---|---|---|
5 | 32 | 2,344 | 1,376 Bytes (Fits in a single MTU frame) |
10 | 1,024 | 2,504 | 1,496 Bytes (Fits in a single MTU frame) |
15 | 32,768 | 2,672 | 1,616 Bytes (Triggers MTU fragmentation) |
20 | 1,048,576 | 2,840 | 1,736 Bytes (Triggers MTU fragmentation) |
25 | 33,554,432 | 3,008 | 1,856 Bytes (Triggers MTU fragmentation) |
Table 6: LMS signature sizes for the specific SP 800-208 height parameters and the RFC 9858 truncated hash function implementation. *RFC 9858
As the metrics indicate, a height of 15 configuration yields a signature size of 2,672 bytes, and this is the most commonly implemented height parameter we have seen deployed. While this payload is smaller than SLH-DSA's best-case 7,856 bytes footprint, it still directly violates the 1,500-byte network MTU barrier common to various automotive and industrial embedded bus architectures.
To provide a concrete automotive example of limited X.509 certificate size we can see the reality of these limitations in the ISO 15118 standard for Vehicle-to-Grid (V2G) Plug & Charge communication. In the ISO 15118-2 deployments, the entire transport layer is computationally constrained to prevent packet fragmentation over the network bus, forcing end entity certificates to be 800 bytes or less. Even with the more robust ISO 15118-20 standard the certificate limit has an upper limit of 1,600 bytes. The ISO 15118 standard does not support any Stateless or Stateful HBS schemes, instead opting to support various elliptic curve digital signature schemes.
Crucially, the ISO 15118 standard does not support any stateful or stateless Hash-Based signature schemes, relying instead on highly compact elliptic curve algorithms like ECDSA or EdDSA. While these traditional curve primitives are completely vulnerable to a CRQC running Shor’s algorithm, we highlight this ecosystem to illustrate the hard mathematical ceiling facing the industry: modern embedded automotive networks simply lack the bus bandwidth and memory buffers required to ingest the multi-kilobyte payloads demanded by every currently standardized quantum-resistant algorithm
Finally, the United States NSA's CNSA 2.0 guidelines completely exclude SLH-DSA from its mandatory software and firmware signing requirements, explicitly allowing stateful signatures for schemes reliant on hash functions or eXtendable-Output Functions. For hardware-defined, computationally constrained embedded architectures, statelessness has a size overhead that typically cannot be supported.
Evidence of LMS and/or XMSS support
At Innophia, we have tracked several critical field deployments that validate the real-world demand for stateful HBS quantum-resistant signatures. These industry use cases extend beyond our empirical analysis of the NIST CAVP registries in Section Market Reality: LMS vs ML-DSA and operate entirely within the realm of hardware-defined cryptography. This refers to constrained, physical hardware environments where algorithm support is deeply rigid and the ideal of crypto-agility is exceptionally difficult to achieve.
In these architectures, systems frequently utilize One-Time Programmable (OTP) memory to immutably anchor public keys at manufacture by physically blowing on-chip fuses. Consequently, traditional software-driven revocation models do not apply. In a software-defined ecosystem, platforms seamlessly leverage the rich metadata of standard X.509 or Card Verifiable Certificates (CVC) to manage trust chain validation via Certification Authorities (CAs), and revocation via Certificate Revocation Lists (CRLs), and OCSP responders.
However, as hardware-defined systems increase their processing capabilities, we have seen a middle ground. Some constrained modern architectures also adopt lean CVC profiles or highly stripped-down X.509 variants with only ruthlessly populated essential ASN.1 fields to remain under the strict 1,500-byte network MTU limitation typical of embedded channels.
This reality of immutable, fused verification keys is most prominent across foundational edge infrastructure: Secure Boot pipelines, firmware signature verification routines, and low-level cryptographic operations embedded inside Microcontroller Units (MCUs), Electronic Control Units (ECUs), System on Modules (SoMs), and System on Chips (SoCs). This domain is where stateful Hash-Based architectures inherently excel. The underlying primitives of Stateful HBS schemes rely on simple, efficient hash functions rather than the computationally heavy, complex lattice-based mathematics required by other quantum-resistant alternatives like ML-DSA.
Table 7 details a cross-section of prominent semiconductor and silicon-based vendors actively fielding LMS and XMSS support within their portfolio.
Vendor | Use Cases & Target Architecture | Algorithm(s) | Documentation | Evidence Maturity |
|---|---|---|---|---|
NVIDIA | Secure Boot for Jetson Linux (Multiple SoM/SoC Families) | XMSS | High: Verified via active implementation and deployment documentation. | |
AMD | Secure Boot for Versal Prime & Versal AI Edge (Gen 2 Devices) | LMS | High: Detailed in official hardware technical reference guides. | |
Microchip | Secure Boot & Firmware Update for TS1800 Platform Root of Trust | LMS | Medium: Product announcement and platform release data. | |
STMicro | Post-Quantum Embedded Security Library for STM32 Automotive MCUs | LMS & XMSS | Medium: Developer ecosystem integration brief. | |
Infineon | PQC-Protected Firmware Updates for OPTIGA™ TPM SLB 9672 | XMSS | High: Explicitly detailed in policies and product briefs. |
Table 7: Real-World Implementations of Hardware-Defined LMS/XMSS
Note on Evidence Hierarchy: As highlighted above, implementation and developer guides indicate a high tier of deployment readiness, followed by hardware product briefs, with generalised news releases occupying the baseline tier of implementation maturity
What can be done now
Although this blog has illuminated a number of challenges with the adoption of Stateful Hash-Based signatures, the intent is not to discourage the use of these algorithms. The intention is to provide practical insight to better inform a strategic decision on the adoption of these schemes. The blog has also highlighted that the use cases for LMS and XMSS sit in areas such as Secure Boot, Firmware signing/verification for systems such as MCUs, ECUs, SoMs, SoCs, and TPMs.
Prototyping
Although LMS and XMSS schemes must be implemented in appropriately vetted hardware capable of durably maintaining state information, there are a number of software libraries which support LMS and XMSS for the purposes of prototyping: WolfSSL, BouncyCastle, LibOQS.
Conclusion and Help
If you were an early adopter of LMS and XMSS signatures for software and hardware signing and are looking to improve your deployment then Innophia have a dedicated team of subject matter experts and developers keen to provide support and solutions in this challenging area.
If you are considering adopting Stateful HBS schemes as part of your quantum-resistant transformation strategy, please contact us to discuss your emerging requirements in this space as planning is the absolute foundation of implementing any cryptographic scheme, especially at Stateful HBS scheme due to the requirement to generate all signature keys up front and the need to enforce immutable key usage state tracking.
Author: Dr Angelique Faye Loe: aloe@innophia.co.uk
If you found genuine value in this blog then please consider Buying Me a Coffee. I also welcome you to reach out if you simply want to have an informal chat about cryptography. Some of the topics I am currently researching for upcoming blogs are: entropy sources, modern PKI (including X9), the use of Pre-shared Keys to achieve quantum-resistance, Certificate Lifecycle Management, and the realities of the Post-Quantum transition. I genuinely love this field, and diving into the unique, complex deployment challenges we all face only strengthens our collective knowledge and sense of community. Let's connect!