![Post-Quantum Firmware Signing: 5 Schemes Ranked [2026]](https://shattered.io/wp-content/uploads/2026/11/post-quantum-firmware-signing-lms-xmss-ml-dsa-slh-dsa-2026-gen-1.webp)
Firmware is the first place a quantum computer would do real damage, and the hash-based answer has been approved since October 2020. NIST SP 800-208 approves the stateful schemes LMS and XMSS, while FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) became final on August 13, 2024. FN-DSA, the Falcon-derived option, still has no final FIPS 206. Anyone planning post-quantum firmware signing today therefore picks from four approved schemes and one that is still waiting in the wings.
The deadline pressure is real. NIST finalized IR 8547 on October 27, 2026, according to several trackers, and the roadmap marks RSA, ECDSA and EdDSA signatures as deprecated after 2030 and disallowed after 2035. A boot ROM that ships this year with an Ed25519 verifier will still be in the field when those dates pass. The five schemes below trade signature size, verify time, signing hazard and standards status very differently, and the three realistic picks for a Cortex-M class device cost anywhere from 1,452 to 7,856 bytes per signature.
The key-exchange side already has its own breakdown in the three-standard comparison of ML-KEM, ML-DSA and SLH-DSA. Firmware signing follows different rules, because the verifier ships inside the product and cannot be swapped like a TLS library on a server. That single fact drives almost every decision that follows.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
Why Firmware Signatures Move Before Everything Else #
Encrypted traffic faces a harvest-now, decrypt-later threat, so key exchange went first. Signatures face a different clock. A forged signature only matters once someone can forge it, which sounds like a reason to wait. Firmware flips that logic. A device verifies updates with the same algorithm and the same root key for its whole life, and a quantum attacker who derives an RSA or ECDSA signing key from a public key could sign malicious updates that every shipped unit would accept.
Three properties make firmware different from web certificates. First, verifiers are hard to change. A boot ROM, a secure element or a first-stage boot holds a public key or its hash, and replacing it in fielded hardware can mean a hardware revision. Second, roots of trust outlive certificates. A web certificate rotates every few months, while a firmware root key may sit in fuses for a decade or more. Third, the update channel is also the repair channel. If an attacker can forge the update signature, you cannot safely ship the patch that migrates the device.
DuoKey’s November 3, 2026 code-signing guide summarizes the NSA’s position the same way. In many firmware cases the validation algorithm is not easily updated, so it stays locked in for the life of the system, and update mechanisms likely cannot be transitioned after purchase. That is why the agency treats software and firmware signing as the most urgent slice of its CNSA 2.0 transition, with the suite required in new National Security Systems acquisitions from January 1, 2027.
Civilian policy points the same direction. The final IR 8547, as described by PostQuantum.com on October 28, 2026, identifies LMS and XMSS for software and firmware signing and expects hardware modules that protect firmware updates to use post-quantum algorithms. The full date table sits in the NIST IR 8547 timeline for RSA and ECDSA, but the short version is simple: classical signatures are deprecated after 2030 and disallowed after 2035.
The contrast with the web is stark. A Rosetta Quantum tracker dated November 1, 2026 found that roughly 70% of browser traffic to Cloudflare already negotiates a post-quantum key exchange, yet zero publicly trusted TLS certificates use ML-DSA or SLH-DSA. Web signatures wait on certificate authorities and browser vendors. Firmware signatures wait on nobody, because you own both the signer and the verifier. That control is the opportunity, and it explains why embedded teams are moving first.
The Five Contenders at a Glance #
Two families compete here. The hash-based family builds security on nothing but a hash function, which is the most conservative assumption in cryptography. It includes the stateful LMS and XMSS, plus the stateless SLH-DSA. The lattice family relies on structured lattice problems and includes ML-DSA and the Falcon-derived FN-DSA. Lattice schemes are faster and smaller than stateless hash-based ones, but they rest on newer math.
| Scheme | Standard | Type | Signer state | Status in November 2026 |
|---|---|---|---|---|
| LMS (and HSS) | RFC 8554, NIST SP 800-208 | Stateful hash-based | Yes, one-time keys | Approved since October 2020 |
| XMSS (and XMSS^MT) | RFC 8391, NIST SP 800-208 | Stateful hash-based | Yes, one-time keys | Approved since October 2020 |
| ML-DSA | FIPS 204 | Module-lattice | No | Final since August 13, 2024 |
| SLH-DSA | FIPS 205 | Stateless hash-based | No | Final since August 13, 2024 |
| FN-DSA (Falcon) | FIPS 206 pending | NTRU lattice | No | In development, no final release |
Note the naming history, because vendor datasheets still mix the names. ML-DSA was CRYSTALS-Dilithium, SLH-DSA was SPHINCS+, and FN-DSA is the planned NIST name for Falcon. A datasheet that says Dilithium or SPHINCS+ describes the pre-standard algorithm, and one that claims FIPS 206 certification describes something that does not exist yet.
The two stateful schemes are cousins. Both sign by consuming one-time keys arranged in a Merkle tree, and both come with the same operational hazard. The details of how their parameter sets differ are covered in the LMS and XMSS head-to-head, so the rest of this comparison treats them as a pair and splits them only where the numbers differ. XMSS dates to RFC 8391 in May 2018, and SP 800-208 landed in October 2020, so neither is a newcomer. What changed in 2026 is the ecosystem around them, from boots to silicon.
Full Specs Table: Key and Signature Sizes #
Sizes decide whether a scheme fits in a boot ROM, so they come first. The table below follows the published specifications, with ECDSA P-256 and Ed25519 as classical baselines. A lab write-up by Jacar Systems dated October 22, 2026 also measured ten ML-KEM, ML-DSA and SLH-DSA sizes byte for byte with OpenSSL 3.5.9, and every value matched the FIPS tables.
| Scheme and parameter set | Specification | Public key (bytes) | Signature (bytes) | Signatures per key |
|---|---|---|---|---|
| ECDSA P-256 | FIPS 186-5 | 64 | 64 | Unlimited |
| Ed25519 | RFC 8032 | 32 | 64 | Unlimited |
| LMS SHA256 M32 H10, LM-OTS W8 | RFC 8554, SP 800-208 | 56 | 1,452 | 1,024 |
| LMS SHA256 M32 H20, LM-OTS W8 | RFC 8554, SP 800-208 | 56 | 1,772 | 1,048,576 |
| XMSS-SHA2_10_256 | RFC 8391, SP 800-208 | 68 | 2,500 | 1,024 |
| XMSS-SHA2_20_256 | RFC 8391, SP 800-208 | 68 | 2,820 | 1,048,576 |
| ML-DSA-44 (category 2) | FIPS 204 | 1,312 | 2,420 | Unlimited |
| ML-DSA-65 (category 3) | FIPS 204 | 1,952 | 3,309 | Unlimited |
| ML-DSA-87 (category 5) | FIPS 204 | 2,592 | 4,627 | Unlimited |
| SLH-DSA-128s (category 1) | FIPS 205 | 32 | 7,856 | Up to 2^64 |
| SLH-DSA-128f (category 1) | FIPS 205 | 32 | 17,088 | Up to 2^64 |
| SLH-DSA-192s (category 3) | FIPS 205 | 48 | 16,224 | Up to 2^64 |
| SLH-DSA-256s (category 5) | FIPS 205 | 64 | 29,792 | Up to 2^64 |
| SLH-DSA-256f (category 5) | FIPS 205 | 64 | 49,856 | Up to 2^64 |
| Falcon-512 (basis of FN-DSA) | Falcon submission, FIPS 206 pending | 897 | 666 | Unlimited |
Three patterns stand out. First, the hash-based schemes have tiny public keys (32 to 68 bytes), which matters when the root key lives in fuses or a small one-time-programmable area. Second, ML-DSA public keys are much larger than the hash-based ones, but its signatures stay under 5 KB at every level. Third, SLH-DSA signatures start at 7,856 bytes and reach 49,856, which rules the f variants out for anything bandwidth-sensitive.
The SHA2 and SHAKE variants of each SLH-DSA set have identical sizes, and FIPS 205 defines 12 parameter sets in total. The robo2u engineering guide, published November 3, 2026, also lists the private-key side: ML-DSA private keys run 2,560 to 4,896 bytes, though FIPS 204 lets a device store only the 32-byte seed and regenerate the rest, which suits a secure element with little storage. For the classical baseline, see the Ed25519 and ECDSA breakdown, which covers why those 64-byte signatures became the default in the first place.
Benchmarks: Verify Cycles on a Cortex-M4 #
Boot code only verifies. Signing happens on a build server or inside an HSM, so the number that matters for secure boot is verify time. The robo2u guide to post-quantum security for robots and drones reproduces measurements from the pqm4 project, which benchmarks post-quantum schemes on a Cortex-M4 board (the Nucleo-L4R5ZI). The millisecond column is plain division of cycles by a 100 MHz clock, so treat it as a planning figure, not a lab result for your silicon.
| Scheme (pqm4 implementation) | Verify cycles | Verify stack (bytes) | At 100 MHz | Versus ML-DSA-44 (m4f) |
|---|---|---|---|---|
| ML-DSA-44 (m4f) | 1,421,623 | 8,912 | About 14 ms | 1.0x |
| ML-DSA-44 (m4fstack) | 3,242,333 | 2,712 | About 32 ms | 2.3x |
| ML-DSA-65 (m4f) | 2,415,944 | 9,888 | About 24 ms | 1.7x |
| ML-DSA-87 (m4f) | 4,193,104 | 12,060 | About 42 ms | 2.9x |
| SLH-DSA-SHA2-128s (clean) | 7,471,794 | 1,968 | About 75 ms | 5.3x |
| SLH-DSA-SHA2-128f (clean) | 21,923,628 | 2,664 | About 219 ms | 15.4x |
The table shows a clean trade. ML-DSA verifies quickly but wants up to 12,060 bytes of stack, while the stack-optimized m4fstack build of ML-DSA-44 cuts that to 2,712 bytes (3.3x less) at the price of 2.3x more cycles. SLH-DSA-128s needs under 2 KB of stack but burns 5.3x the cycles of ML-DSA-44. Pick the constraint that hurts more: RAM or boot time.
Signing tells a harsher story. The same source reports that ML-DSA-44 signing averages 3.9 million cycles in the m4f build, while SLH-DSA-128s signing takes 7.7 billion, roughly 1,970 times more. At 100 MHz that is about 39 ms against about 77 seconds. Signing a nightly build on a server hides that gap, but signing on a constrained HSM or a device that must self-sign does not. Hashing a multi-megabyte image usually costs more than the signature check itself, and a hardware SHA-256 accelerator speeds up both the hash-based schemes and the image digest.
The sourced benchmark set has gaps worth naming. It publishes no cycle counts for LMS, XMSS or Falcon on this board, so those rows are absent rather than guessed. Hash-based verification is cheap on silicon that already accelerates SHA-2, which is the design bet behind Infineon’s LMS support, but treat any per-scheme millisecond claim for LMS as unverified until you measure it on your part.
Two further data points round out the picture. The Jacar OpenSSL 3.5.9 lab measured a TLS 1.3 handshake in which the certificate grew from 382 bytes (P-256) to 5,506 bytes (ML-DSA-65) and the CertificateVerify signature from 71 to 3,309 bytes. Rosetta Quantum reports that a typical TLS handshake carries five signatures and two public keys, so swapping everything to ML-DSA would push one handshake above 10 KB. Firmware update agents that fetch signed manifests over constrained links face the same arithmetic.
What the Sizes Do to Your Flash and Boot Budget #
Raw sizes only help once you convert them into a budget. A verifier needs the public key (or its hash) and one signature per image. The table below adds those two numbers for each scheme and compares the total against Ed25519, which needs 96 bytes. This is arithmetic on the specification sizes above, with no measured data added.
| Scheme | Public key plus one signature (bytes) | Growth versus Ed25519 |
|---|---|---|
| Ed25519 | 96 | 1.0x |
| ECDSA P-256 | 128 | 1.3x |
| LMS H10 | 1,508 | 15.7x |
| Falcon-512 (FN-DSA basis) | Not listed | Not listed |
| XMSS-SHA2_10_256 | Not listed | Not listed |
| ML-DSA-44 | Not listed | Not listed |
| ML-DSA-65 | Not listed | Not listed |
| ML-DSA-87 | 7,219 | 75.2x |
| SLH-DSA-128s | Not listed | Not listed |
| SLH-DSA-128f | Not listed | Not listed |
For a firmware image header, the robo2u guide works through the same math. A header that reserved 64 bytes for an Ed25519 signature now needs about 2.4 KB for ML-DSA-44, 4.6 KB for ML-DSA-87 or 1.5 KB for LMS at height 10. If the boot also stores the public key in flash, add 1.3 to 2.6 KB for ML-DSA, against just 56 or 68 bytes for LMS and XMSS. On a part with 256 KB of flash that is rounding error. On a security MCU where the boot partition has 16 KB, it decides the architecture.
Bandwidth matters for the update channel too. A full firmware image dwarfs a 5 KB signature, but small signed messages do not. Mission uploads, signed telemetry and certificate chains over a 57.6 kbps radio all feel it. The same guide estimates that a chain of three ML-DSA-65 certificates carries roughly 15.8 KB of keys and signatures alone (3 x 1,952 plus 3 x 3,309 bytes), before any other certificate field. That is where flat signing, with one signature and a raw public key, beats a certificate hierarchy. The wider certificate problem, including attempts to compress it, is covered in the X.509 versus Merkle Tree Certificates comparison.
The takeaway for planners: LMS and Falcon sit in the 1.5 KB band, ML-DSA in the 3.7 to 7.2 KB band, and SLH-DSA at 7.9 KB and up. For context on how far RSA signatures fall behind in this table, the RSA versus ML-DSA signature comparison shows why a 256-byte RSA-2048 signature looks tiny next to any entry here, and why it still gives no quantum protection.
State Management: The Hidden Price of LMS and XMSS #
LMS and XMSS build a signing key from many one-time keys. Every signature consumes one leaf, and reusing a leaf lets an attacker who holds two signatures on different messages forge new ones. That sounds simple until you list how a leaf gets reused by accident. A restore from an old backup rewinds the counter. Two redundant signers sharing one key can pick the same leaf. A crash between signing and saving state can hand out a signature whose leaf was never marked as spent.
The quantumsequrity walkthrough of SP 800-208, dated October 22, 2026, stresses that the standard is stricter than most implementers expect. Key generation and signing are validated only inside hardware cryptographic modules, and the private key never leaves them. DuoKey adds that verify-only products, such as a boot ROM, need only CAVP-validated verification code. So the burden lands on the signing service, not on the device.
| Concern | Why it matters | Practical control |
|---|---|---|
| Backup and restore | An older key copy rewinds state and repeats leaves | Never back up state the classical way, use partitioned sub-trees or separate devices |
| High availability | Two signers on one key can pick the same one-time key | One active signer per key, or a separate key space per signer |
| Crash during signing | The signature may leave before state is saved | Use modules that persist state atomically before output |
| Key exhaustion | A spent key stops the release process | Monitor remaining signatures and roll keys early |
Capacity planning is the other half. The tree height fixes the signature budget at key generation. A height-10 LMS or XMSS key signs 1,024 times, and a height-20 key signs 1,048,576 times. Consider a hypothetical team that signs 20 artifacts a day. The small key lasts about 51 days. The large one lasts about 143 years, but it costs 320 extra bytes of signature for LMS (1,772 versus 1,452) and 320 for XMSS (2,820 versus 2,500). Sizing the tree to the product roadmap, with margin, is a design decision rather than an afterthought.
The standards ecosystem treats the operational problem as real. Current guidance says XMSS is stateful, so each one-time signing leaf must be used only once, and LMS is suitable only where a device can reliably preserve and advance signing state. The direction is clear: stateful signing is a managed service, and it needs an owner.
Stateless schemes avoid the whole category. ML-DSA has no cap on signatures per key. SLH-DSA caps each key at 2^64 signatures, and a footnote in FIPS 205 works out that signing 10 billion messages per second would take over 58 years to exhaust one. The draft SP 800-230 sets would cap keys at 2^24 signatures, a far smaller limit that NIST proposes for limited-signature uses such as firmware and software signing.
The Compliance Clock: CNSA 2.0, IR 8547 and Federal Dates #
Dates drive architecture more than elegance does. The table below collects the ones that touch firmware signing, with each source named. Rows marked as reported come from trackers or vendor summaries and should be checked against the primary document before you commit a roadmap.
| Date | Event | Source and status |
|---|---|---|
| October 2020 | SP 800-208 approves LMS, HSS, XMSS and XMSS^MT | NIST, final |
| August 13, 2024 | FIPS 204 and FIPS 205 become final | NIST, final |
| April 13, 2026 | Draft SP 800-230 proposes six extra SLH-DSA sets (levels 1, 3, 5, 2^24 signatures per key) | NIST CSRC, draft, comments closed June 12, 2026 |
| October 27, 2026 | IR 8547 finalized: deprecated after 2030, disallowed after 2035 | Reported by several trackers |
| January 1, 2027 | CNSA 2.0 required in new National Security Systems acquisitions | Reported by DuoKey and eCorpIT |
| December 31, 2030 | Reported federal deadline for post-quantum key establishment, and phase-out date for equipment that cannot support CNSA 2.0 | Reported by robo2u and eCorpIT |
| December 31, 2031 | Reported federal deadline for post-quantum signatures, and CNSA 2.0 mandatory | Reported (EO 14412 and OMB M-26-15 per robo2u) |
| After 2035 | RSA, ECDSA and EdDSA disallowed under NIST standards | IR 8547, reported |
The CNSA 2.0 details matter most for vendors who sell into US national security systems. DuoKey’s post-quantum code signing guide summarizes version 2.2 of the NSA’s CNSA 2.0 FAQ (October 2026) like this: LMS and XMSS from SP 800-208 are allowed with any parameters, and LMS with SHA-256/192 is preferred. ML-DSA-87 is approved for signing firmware and software. The multi-tree variants HSS and XMSS^MT are not allowed, and SLH-DSA is not part of CNSA and not approved for any use in those systems. If you ship into that market, confirm each point against the NSA text, because a vendor summary is not a compliance basis.
One more constraint hides in that summary. ML-DSA-87 is the only ML-DSA level named for CNSA 2.0 firmware signing, which means a bring-up on ML-DSA-44 in the lab does not carry over to a national security product. Its public key is 2,592 bytes and its signature 4,627, so the flash budget in the previous section has to be sized for the larger level from day one.
Outside defense, the dates are softer but still binding for anyone who sells to federal agencies. Hardware lives long, so a design frozen in 2027 will still be shipping when the 2030 and 2031 milestones arrive. The shift from draft to final also changed details, which the comparison of the IR 8547 final and the draft walks through, including how the final report simplified the draft’s schedule. The practical rule for firmware teams is short: choose algorithms now that your verifier can still run in 2035.
When Each Scheme Wins #
No single scheme wins every surface. The right pick depends on whether you control the signer, how tight the verifier is, and which regulator reads your datasheet. Each scheme below gets a verdict anchored to the numbers above.
LMS and XMSS: smallest footprint, strictest signer
LMS gives the most compact public key plus signature combination in the table that has a standard behind it, far smaller than ML-DSA-65. Public keys of 56 bytes (LMS) and 68 bytes (XMSS) fit in fuses. Verification is cheap on parts with SHA-2 hardware, and the schemes rest on nothing but a hash function. DigiCert, in guidance reported on October 9, 2026, describes XMSS as particularly suitable for firmware signing, secure boot and long-lived trust anchors, provided signing happens in a controlled environment with reliable state management.
The limits are just as clear. SP 800-208 is a NIST recommendation, not a FIPS standard, and LMS and XMSS are not recommended for general-purpose PKI or WebPKI issuance. The October 28, 2026 reporting on the final IR 8547 keeps them in the specialized niche of software, firmware and secure-boot signing. Choose them when one team owns a small number of signing keys, an HSM sits behind them, and the verifier has no room to spare. XMSS has little to offer over LMS unless your toolchain already supports it, since LMS has the smaller signature and DuoKey reports that CNSA 2.0 prefers LMS with SHA-256/192.
ML-DSA: the stateless default
ML-DSA is the one to pick when you cannot guarantee a single, well-guarded signer. It needs no state, fits existing signing services and build pipelines, and verifies in about 24 ms for ML-DSA-65 on the pqm4 Cortex-M4 setup at 100 MHz. FIPS 204 remains the August 13, 2024 text with no finalized revision confirmed, and NIST’s potential-errata notes tracked from July 31, 2026 are explicitly not official changes.
Library support is broad. DuoKey lists OpenSSL 3.5 (ML-DSA and SLH-DSA) and Java 24 (JEP 497, with JAR signing out of scope), and Intel’s Crypto Primitives Library documents key generation, signing and verification per FIPS 204. One caution applies to every integration. FIPS 204 defines a pure mode and a pre-hash mode (HashML-DSA), and the two are not interchangeable, so confirm which mode your verifier expects before you wire a remote signer to it. The cost is size: signatures from 2,420 to 4,627 bytes and public keys from 1,312 to 2,592.
SLH-DSA: the conservative hedge, with a draft fix on the way
SLH-DSA offers hash-only security without state, which makes it attractive for a root key that signs a handful of times in a decade. Its price is steep: 7,856 bytes at the smallest level, 5.3x the verify cycles of ML-DSA-44 and a signing run of 7.7 billion cycles. NIST knows the fit is poor for limited-signature uses, and on April 13, 2026 it released draft SP 800-230 with six additional parameter sets at levels 1, 3 and 5. They cap each key at 2^24 signatures, they are not approved for general use, and the draft remained an initial public draft after comments closed on June 12, 2026.
For the general trade-off between the two NIST-final signature standards, the SLH-DSA versus ML-DSA speed and size comparison has the full numbers. Remember the compliance wrinkle: per DuoKey’s reading of the NSA FAQ, SLH-DSA is outside CNSA 2.0, so it suits long-lived roots outside national security systems rather than products sold into them.
FN-DSA: small signatures, no final standard
Falcon-512 posts the best signature size of the lattice family, 666 bytes with a 897-byte public key, which beats even LMS on signature bytes. It is still unfinished. FIPS 206 is in development, no public NIST draft had been posted by early November 2026, and talk of a late 2026 or early 2027 release is a forecast rather than a NIST date. The initial FIPS would avoid floating-point arithmetic, and one report dated September 28, 2026 says NIST is moving to fixed-point math for key generation and signing, which could change implementation details.
Vendors treat it accordingly. wolfSSL announced native Falcon-512 and Falcon-1024 support in wolfCrypt on August 13, 2026 and labels it experimental, warning that the API, formats and naming may change once FN-DSA is final. Build a prototype if bandwidth rules your design, but do not freeze a boot ROM around it. The FN-DSA versus ML-DSA comparison tracks the standards gap in more detail.
Pricing and Cost: What Each Option Really Charges You #
None of the five schemes has a list price. They are standards and specifications, and the research found no official price for LMS, XMSS, SLH-DSA or FN-DSA as of November 6, 2026. The money goes elsewhere: validated hardware for stateful signers, engineering time for state control, flash and RAM on the device, and signing capacity in the cloud. The table sorts those costs by scheme.
| Scheme | Official price | Where the cost lands |
|---|---|---|
| LMS | None published | Validated HSM for signing, atomic state storage, CAVP-tested verifier code |
| XMSS | None published | Same as LMS, plus a reported ACVP test-suite gap |
| ML-DSA | None published | 3,309-byte signatures (level 3), KMS or HSM signing capacity, larger flash headers |
| SLH-DSA | None published | 7,856 to 49,856-byte signatures, slow signing, 75 ms or more per verify on the Cortex-M4 test |
| FN-DSA | None published | Experimental implementations only, rework risk when FIPS 206 lands |
Cloud signing is the one place with a live product. AWS documentation updated October 26, 2026 states that AWS KMS supports ML-DSA through ML-DSA-44, ML-DSA-65 and ML-DSA-87, and an AWS security post from October 12 shows how to enforce an ML-DSA algorithm policy with service control policies and IAM. Per-request pricing for those keys is not in the sourced material, so check the AWS pricing page before budgeting. For the three-cloud picture, the post-quantum key pricing comparison across AWS, Azure and Google lines up what each provider charges and supports.
Stateful signing cannot ride on a generic cloud key service. SP 800-208 needs hardware modules that persist state and block key export, which pushes teams toward dedicated HSMs or a vendor platform that bundles them. Budget for that hardware plus a second unit for disaster recovery that does not clone the key. The hidden cost of a mistake is far higher than the cost of the module: one reused leaf can compromise the key, and replacing a root key in the field is the exact problem this migration tries to avoid.
Real-World Deployments Shipping in 2026 #
Standards talk is cheap, so here are the products and libraries that already carry these schemes. Items based on vendor announcements are labeled as such, and anything that comes from a single secondary report is flagged.
- Lattice Sentry v5.0 (October 12, 2026). Lattice Semiconductor’splatform firmware resilience stack for AI infrastructure lists CNSA 2.0 post-quantum support with ML-DSA, LMS and XMSS for authentication and ML-KEM for key exchange. It adds anti-rollback protection and SPDM-based attestation, and its LMS and XMSS capability is verification-oriented. The mix shows how a vendor hedges: hash-based and lattice verification live side by side.
- Infineon PSOC Control C3 Performance Line. Infineon announced in 2025 that these microcontrollers meet CNSA 2.0 firmware-protection requirements, with LMS verification backed by SHA-2 hardware acceleration and PSA Level 3 compliance. Its Edge Protect Tools and ModusToolbox cover LMS key provisioning. Reports in early November 2026 describe the same capability as a CNSA 2.0-compliant MCU family.
- wolfCOSE HSS/LMS (September 29, 2026). wolfSSL’swolfCOSE release adds RFC 8778 HSS/LMS signatures under COSE algorithm -46, with verify-only build profiles for small devices. It brings stateful signing into the compact CBOR formats that secure boot and update flows already use.
- wolfCrypt Falcon (August 13, 2026). The same vendor ships native Falcon-512 and Falcon-1024 and labels the code experimental until FIPS 206 lands.
- wolfBoot and Microchip (reported). A November 3, 2026 industry overview says wolfBoot has supported LMS/HSS and XMSS/XMSS^MT since v2.0.0 and added an ML-DSA-87 signed-boot configuration in v2.10.0 for the NXP i.MX RT700. It also lists Microchip MEC175xB controllers with LMS verification alongside ML-DSA and ML-KEM. Treat both as secondary reporting.
- Cosmos Ledger Security 2026.1 (October 8, 2026). This ledger stack added native ML-DSA (FIPS 204) signing for consensus and account keys, with KMS and HSM signing and zero-downtime validator-key rotation. It is not firmware, but it proves a stateless ML-DSA signing pipeline works in production.
- Algorand and FN-DSA (October 27, 2026 report). Algorand says it will implement the NIST-approved version once the final standard appears, and notes that its existing deterministic Falcon implementation differs from the draft FN-DSA scheme. That is the rework risk in one sentence.
Library support fills the gaps. OpenSSL 3.5 and Java 24 handle ML-DSA, and Intel’s Crypto Primitives Library documents it as well. The pattern across all of these: stateful and lattice signatures arrive together, because customers want a stateless fallback next to the hash-based primary.
Use-Case Recommendations #
Pick by surface, not by brand loyalty. The seven cases below cover most firmware and update scenarios.
- Boot ROM or MCU boot, one controlled signer. Use LMS. A 56-byte public key fits in fuses, and the 1,452-byte signature (height 10) is the smallest approved option. Put the signer behind a validated HSM with atomic state.
- Server BMC and platform firmware. Use LMS or XMSS plus ML-DSA, as Lattice Sentry does. The dual path lets you fall back if one security assumption weakens.
- OTA updates with many artifacts and CI/CD signing. Use ML-DSA-65. It is stateless, signs fast, and ties into KMS-style services. At 3,309 bytes per signature it costs little against a full image.
- Long-lived offline root that signs a few times a decade. Use SLH-DSA-128s and consider waiting for SP 800-230 once it is final. A 32-byte public key and hash-only security suit a root. Slow signing does not hurt when you sign twice a year.
- Bandwidth-bound telemetry or radio links. Prototype Falcon-512 (666-byte signatures) and plan on LMS H10 (1,452 bytes) as the standardized fallback. Avoid certificate chains, since three ML-DSA-65 certificates alone weigh about 15.8 KB.
- Product sold into US national security systems from January 1, 2027. Follow the CNSA 2.0 reading above: LMS (SHA-256/192 preferred) or XMSS for firmware, or ML-DSA-87. Skip SLH-DSA, HSS and XMSS^MT for those systems, and verify against the NSA text.
- Containers, packages and software releases. Use ML-DSA for artifacts you also verify yourself, and wait for platform vendors on Authenticode, app stores and package managers. Track pre-hash mode compatibility.
Teams that want the wider algorithm map around these picks can browse the cryptography section, which keeps the key-exchange, hash and signature comparisons in one place.
Migration Guide: From Ed25519 to a Post-Quantum Verifier #
The steps below follow the order of DuoKey’s migration plan, with added detail from the size and cycle data above. The principle: ship the verifier before you need it, because the update channel stops being trustworthy the day signatures can be forged.
- Inventory every signing key and verifier. List the algorithm, storage location, what it signs and which verifiers check it, including boot ROMs, update agents and the timestamping service.
- Rank by verifier lifetime. Products that will still be in the field in the 2030s and cannot update their verifier come first.
- Choose a scheme per verifier. Use the use-case list above. Constrained boot chains lean toward LMS, software pipelines toward ML-DSA.
- Size the flash and RAM. Run the budget script below with your parameter sets. Include the stack figures from the pqm4 table.
- Ship the post-quantum verifier and public key now. Deliver them through a classically signed update while that channel is still trustworthy.
- Build the signing service. Keep keys non-exportable in an HSM, add approval policies, and for LMS and XMSS enforce state control, with one active signer per key.
- Dual-sign during the transition. Attach a classical and a post-quantum signature where the image format allows it, so old and new verifiers both pass.
- Retire the classical path on a date. Set it ahead of the 2030 and 2035 milestones that apply to your market, then remove the old verifier in a later release.
You can test the stateless path today with OpenSSL 3.5. The commands below, taken from the Jacar lab method, generate an ML-DSA-65 key pair, sign a file and verify it. PQ signatures use the -rawin option because the algorithm processes the whole message. A successful run prints a verification message, and the signature file measures 3,309 bytes.
openssl genpkey -algorithm ML-DSA-65 -out sign.key
openssl pkey -in sign.key -pubout -out sign.pub
openssl pkeyutl -sign -rawin -inkey sign.key -in firmware.bin -out firmware.sig
openssl pkeyutl -verify -rawin -pubin -inkey sign.pub -in firmware.bin -sigfile firmware.sig
wc -c firmware.sig
For the budget step, a few lines of Python turn the specification sizes into a table you can drop into a design review. Change the dictionary to match the parameter sets you shortlist.
SIZES = {
"Ed25519": (32, 64),
"LMS H10": (56, 1452),
"XMSS 10": (68, 2500),
"Falcon-512": (897, 666),
"ML-DSA-44": (1312, 2420),
"ML-DSA-65": (1952, 3309),
"ML-DSA-87": (2592, 4627),
"SLH-DSA-128s": (32, 7856),
}
BASE = sum(SIZES["Ed25519"])
for name, (pk, sig) in SIZES.items():
total = pk + sig
print(f"{name:14} {total:>7} bytes {total / BASE:6.1f}x Ed25519")
Two pitfalls deserve a warning. First, mixing pure and pre-hash modes breaks verification silently, so test the exact pair of signer and verifier you will ship. Second, do not paper over state with a script. A shell wrapper that increments a counter in a file is not a validated module, and a restored VM snapshot will reuse leaves without a single error message.
Pros and Cons Side by Side #
| Scheme | Pros | Cons |
|---|---|---|
| LMS | Smallest approved footprint (56-byte key, 1,452-byte signature at H10), hash-only security, CNSA 2.0 listed | Stateful signer, hardware module required, signature cap per key, not for general PKI |
| XMSS | Hash-only security, 68-byte key, approved under SP 800-208 | Same state hazard, larger signatures than LMS (2,500 bytes at height 10), reported ACVP gap |
| ML-DSA | Final FIPS 204, no state, about 14 to 42 ms verify on a Cortex-M4 at 100 MHz, wide library support | 3,309-byte signature at level 3, up to 12,060 bytes of verify stack, mode mismatch risk |
| SLH-DSA | Final FIPS 205, no state, hash-only security, 32 to 64-byte keys | 7,856 to 49,856-byte signatures, 7.7 billion signing cycles, outside CNSA 2.0 per DuoKey |
| FN-DSA | Smallest lattice signature (666 bytes), no state | No final FIPS 206, experimental code, spec still changing, complex implementation |
The table hides one dependency: every pro for the hash-based schemes assumes you control a hardened signer. If your pipeline signs from many CI runners or contractors, the stateful row loses most of its advantage, because the risk moves from the device into your process. In that world the stateless rows beat their larger sizes.
Verdict: Pick LMS for Tight Boot ROMs, ML-DSA for Everything Else #
The data points to a two-lane answer. In the first lane, LMS wins when a controlled signer, an HSM and a tiny verifier meet. Its key plus signature total is far smaller than that of ML-DSA-65 or SLH-DSA-128s. In the second lane, ML-DSA wins everywhere else: stateless, final since August 13, 2024, and verifying in about 14 ms for level 2 and 24 ms for level 3 in the pqm4 numbers.
| Criterion | Winner | Evidence |
|---|---|---|
| Smallest key plus signature (standardized) | LMS H10 | 1,508 bytes |
| Smallest lattice signature | FN-DSA (Falcon-512) | 666 bytes, but no final FIPS 206 |
| Fastest verify on Cortex-M4 | ML-DSA-44 (m4f) | 1,421,623 cycles, about 14 ms at 100 MHz |
| Lowest verify RAM | SLH-DSA-128s | 1,968 bytes of stack |
| No signer state | ML-DSA, SLH-DSA, FN-DSA | Stateless by design |
| CNSA 2.0 firmware signing (per DuoKey) | LMS, XMSS, ML-DSA-87 | NSA FAQ v2.2 summary |
| Final FIPS standard today | ML-DSA, SLH-DSA | FIPS 204 and 205, August 13, 2024 |
SLH-DSA earns a niche role. Its 75 ms verify and 7,856-byte signature are acceptable for a root that signs rarely, and the SP 800-230 sets may sharpen that case once NIST finalizes them. FN-DSA earns a watch item. Prototype it, measure it, and do not tie a boot ROM to it until FIPS 206 exists. One successor note applies: FIPS 206 is announced as work in progress but not released, with no confirmed publication date.
The takeaway: decide who owns the signer before you pick an algorithm. A team with an HSM, a small release cadence and a 16 KB boot partition should choose LMS. Everyone else should ship ML-DSA-65 now, size flash for ML-DSA-87 if national security customers might follow, and revisit SLH-DSA and FN-DSA when their standards firm up.
Frequently Asked Questions #
Can ML-DSA replace LMS for secure boot?
Yes, if the flash and RAM budget allows it. ML-DSA-65 needs a 1,952-byte public key and a 3,309-byte signature, far more than LMS, and its verify stack in the m4f build is considerably larger than in the stack-optimized ML-DSA-44 build, which uses 2,712 bytes. If the boot ROM is tight or CNSA 2.0 applies, LMS or ML-DSA-87 is the safer lane.
Why is LMS considered risky?
LMS signs with one-time keys, and reusing one lets an attacker forge signatures. A backup restore, a cloned signer or a crash before state is saved can cause reuse. SP 800-208 therefore confines signing to validated hardware modules that persist state and never export the private key.
How big are post-quantum firmware signatures?
LMS at height 10 is 1,452 bytes, XMSS-SHA2_10_256 is 2,500, ML-DSA runs 2,420 to 4,627, and SLH-DSA runs 7,856 to 49,856. Falcon-512, the basis of FN-DSA, is 666 bytes. Ed25519 is 64 bytes, so every option is at least ten times larger.
Is FN-DSA ready for production firmware?
No. FIPS 206 is still in development, no public NIST draft had been posted by early November 2026, and wolfSSL labels its Falcon support experimental. A late 2026 or early 2027 release is a forecast only.
Does SLH-DSA qualify under CNSA 2.0?
According to DuoKey’s summary of version 2.2 of the NSA FAQ, no. SLH-DSA is not part of CNSA and not approved for any use in national security systems, while LMS, XMSS and ML-DSA-87 are named for firmware signing. Check the NSA document directly before relying on that reading.
When do classical firmware signatures stop being allowed?
Under NIST IR 8547, as reported after its October 27, 2026 finalization, RSA, ECDSA and EdDSA signatures are deprecated after 2030 and disallowed after 2035. Reported federal deadlines set post-quantum signatures for December 31, 2031, and CNSA 2.0 is required in new national security acquisitions from January 1, 2027.
Should I dual-sign with a classical and a post-quantum signature?
During the transition, yes where the image format allows it, because older verifiers keep working while new ones check the post-quantum signature. Composite ML-DSA with ECDSA or RSA remains an IETF draft, and the NSA does not require it.
What does post-quantum firmware signing cost?
The schemes themselves have no list price. Costs land in validated HSMs for stateful signers, engineering time, extra flash and bandwidth, and KMS capacity. AWS KMS supports ML-DSA-44, ML-DSA-65 and ML-DSA-87, but per-request pricing was not in the sourced material.