Engineering · 2026-06-16

ML-DSA-87 vs SLH-DSA-256: Choosing the Right Post-Quantum Signature for Long-Lived Identity Assertions

By J. W. Bouckaert

Most of the post-quantum migration conversation in 2026 stops at "deploy ML-DSA and move on." That advice is correct for the median signature workload—JWT issuance, TLS certificates, webhook authentication—where the signing key rotates within weeks and the signature itself lives for hours. It is the wrong advice for a different class of credential whose properties invert every assumption behind the median.

A notarial verifiable credential signed in 2026 may need to verify in 2056. An enterprise SSO root key signed today may anchor a federation trust chain for fifteen years. An eIDAS Qualified Electronic Signature on a land registry transfer must remain admissible for the lifetime of the property record—often longer than the signer's lifetime. For this class of long-lived assertion, choosing a post-quantum signature algorithm is a multi-decade cryptographic bet, not a routine engineering decision, and the bet is being made under uncertainty about which mathematical assumptions will survive forty years of cryptanalysis we have not yet performed.

This article is the case for taking that bet deliberately. It compares the two FIPS-standardised algorithms that matter for this class of credential—ML-DSA-87 at NIST security category 5, and SLH-DSA-SHAKE-256 at the same category—across the five axes that actually determine fitness for decade-scale credentials: cryptographic conservatism, signature size, verification cost, stateless deployment characteristics, and alignment with CNSA 2.0 and the evolving eIDAS cryptographic catalogue.

Terminology

A small terminology note matters before the comparison. "ML-DSA-87" is the highest-security parameter set of the Module-Lattice-Based Digital Signature Algorithm standardised in FIPS 204, finalised by NIST in August 2024. The "87" refers to the rank parameter (k, ℓ) = (8, 7) of the underlying lattice, and the scheme targets NIST security category 5—equivalent to AES-256 against classical and quantum adversaries.

"SLH-DSA-256" is industry shorthand for the highest-security parameter sets of the Stateless Hash-Based Digital Signature Algorithm in FIPS 205. The full names are SLH-DSA-SHA2-256s, SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-256s, and SLH-DSA-SHAKE-256f—four variants over two hash functions and two trade-offs (the "s" for small signature, the "f" for fast signing). The "256" again denotes category 5. Throughout this article we use SLH-DSA-256s as the canonical comparator because the small variant is the one that matters for long-lived storage: signing happens once, verification happens forever, and the size penalty of the fast variant is unjustifiable for archival use.

Both algorithms are stateless. Both reached final FIPS publication in August 2024. Both are NIST-approved for general digital signature use. The differences are everywhere else.

The five axes that matter for long-lived credentials

The first three lines are the cryptographic bet. The next five are the operational consequences of that bet. The final two are the policy framing that will determine what becomes admissible in regulated jurisdictions over the next decade.

Cryptographic conservatism

ML-DSA's security rests on the conjectured hardness of Module Learning With Errors and the related Module Short Integer Solution problem. Both problems sit inside the lattice family, which is the most cryptanalytically active area of post-quantum research and has been since Regev's foundational LWE work in 2005. The lattice family is well-studied, but well-studied is not the same as long-studied. Module-LWE specifically was placed on a worst-case to average-case footing in Langlois and Stehlé's 2015 paper, and the parameter selection for ML-DSA was finalised in the early 2020s during NIST's standardisation. Roughly two decades of intensive cryptanalysis on the lattice family is a substantial body of work, and no polynomial-time attack—classical or quantum—is known. The mathematical community's confidence in lattice hardness is well-founded.

But confidence is bounded by the depth of the assumption stack. ML-DSA's reduction goes: signature security → Module-LWE/SIS hardness → general lattice hardness conjecture. Each step is reasonable; the chain is finite and intelligible. SLH-DSA's reduction is simpler: signature security → SHAKE-256 preimage and second-preimage and collision resistance. SHAKE-256 is the Keccak-based extendable-output function standardised in FIPS 202 in 2015, but the underlying Keccak design has been studied since 2008, and the broader class of cryptographic hash functions—preimage-resistant, collision-resistant compression primitives—has been studied since the 1970s. If SHAKE-256 preimage resistance fails, the cryptographic apocalypse extends to every Bitcoin block, every Ethereum contract, every Linux package signature, every container image digest, and every TLS certificate fingerprint that any party has ever issued.

This is the actual content of the "more conservative" claim. SLH-DSA is not conservative because hash-based cryptography is intrinsically safer than lattice cryptography. It is conservative because the failure mode is correlated with civilisational cryptographic failure. An attacker capable of breaking SHAKE-256 preimage resistance has bigger problems to occupy them than your notarial signature. An attacker capable of breaking Module-LWE has, by contrast, broken exactly your post-quantum signatures and nothing else.

For a one-hour bearer token, this distinction is irrelevant. For a forty-year notarial credential, it is the entire point.

Signature size and long-term storage

The most visible operational cost of SLH-DSA is signature size: 29,792 bytes for SLH-DSA-SHAKE-256s versus 4,627 bytes for ML-DSA-87, a 6.4× expansion. For high-throughput signature workloads (TLS, JWT, attestation), this expansion is prohibitive. For long-lived credentials, the calculus is different.

A notarial VC is signed once and stored for the lifetime of the underlying record. A typical enterprise long-term preservation service charges between US$0.01 and US$0.05 per credential per year for indexed, integrity-verified storage. Across a forty-year retention window, the differential storage cost of a 30 KB SLH-DSA signature versus a 5 KB ML-DSA signature is, in round numbers, somewhere between two and twelve US dollars per credential—and that figure assumes constant per-gigabyte storage pricing rather than the roughly 8% annual decline that has prevailed for storage media since the 1980s. Against the legal value of a notarial credential, that cost is a rounding error.

What matters more than absolute size is transport cost during verification. A wallet presenting a long-lived credential over a constrained network (a mobile data session, a satellite link, an NFC near-field exchange) pays the signature size every time the credential is shown. For credentials shown rarely—once or twice per legal lifecycle—this is irrelevant. For credentials shown thousands of times (an enterprise SSO root that anchors millions of session tokens), it matters. The architectural answer for the latter case is a layered model rather than a choice of ML-DSA over SLH-DSA: the root signs intermediate certificates whose own signatures are smaller and verified more frequently—the same delegated-trust pattern PKI has used for thirty years.

Verification cost

Numbers above are from one-million-iteration runs on AWS Graviton4 (c8g.4xlarge, single-thread, reference implementations from pq-crystals/dilithium for ML-DSA and sphincs/sphincsplus for SLH-DSA, both built with -O3 and no AVX-512 optimisation to keep the comparison representative of generic deployment).

The sign-side disparity is enormous and is the structural reason SLH-DSA-256s is not a general-purpose signature primitive. Signing a credential at 2.2 seconds per operation is incompatible with any synchronous request path. For long-lived credentials this is acceptable because signing is rare—once per notarial act, once per root rotation, once per qualified seal application—and can be moved off the request path entirely.

The verify-side numbers are the more interesting story. SLH-DSA-256s verification at roughly 3 ms is competitive with classical signatures (ECDSA P-384 is around 2 ms; RSA-3072 verification is around 0.1 ms but key validation is more expensive). Three milliseconds is well inside the budget of any human-interactive verification flow, and it is a tiny fraction of the round-trip network cost that dominates real-world signature verification. The verification cost is not the deployment blocker; the signing cost is.

This asymmetry—slow sign, fast verify—is precisely the operational signature of a credential that is signed rarely and verified often. Long-lived credentials are signed once at issuance and verified across decades of usage. The economics align.

Stateless versus stateful

A common source of confusion is the contrast between stateful and stateless hash-based signatures. LMS and XMSS, standardised in NIST SP 800-208, are stateful—the signer must remember which one-time-key indices have been used, and a single state-reuse event is mathematically catastrophic. SLH-DSA, by contrast, is stateless. It uses the same WOTS+ and FORS hash-based primitives internally but addresses them via a hypertree keyed by a message-dependent randomiser, so no state must be persisted between operations.

For long-lived credential signers, statelessness is non-negotiable. The threat model includes:

• HSM migration across decades. The HSM that signs a notarial credential today will be retired, replaced, and possibly cloned during the credential's verification lifetime. A stateful signer would require provable state continuity across every such migration, which is essentially impossible to guarantee over forty years.
• Disaster-recovery restore. Long-lived signing keys live in escrow, in geographic replicas, and in offline backups. A stateful signer that is restored from a backup that predates the most recent signature immediately enables silent forgery. This is the failure mode that motivates the entire "stateful only for firmware and append-only logs" restriction in SP 800-208.
• Multi-party signing for qualified seals. eIDAS Qualified Trust Service Providers may shard a signing operation across multiple HSMs for separation-of-duties. Stateful schemes are incompatible with this without careful sub-tree allocation; stateless schemes are oblivious.

ML-DSA-87 is also stateless, so this argument does not distinguish it from SLH-DSA-256. It does, however, exclude LMS and XMSS from the long-lived-credential conversation entirely. Those algorithms are correct for append-only audit logs; they are not correct for archival credentials.

CNSA 2.0 and the policy pull

The U.S. National Security Agency's CNSA 2.0 suite, published as a Cybersecurity Information Sheet in September 2022, sets the cryptographic baseline for National Security Systems. The suite, as updated through 2024, lists:

• ML-KEM-1024 for key establishment;
• ML-DSA-87 for general digital signatures;
• LMS and XMSS (SP 800-208 parameters) for firmware and software signing;
• AES-256 for symmetric encryption;
• SHA-384 and SHA-512 for hashing.

CNSA 2.0 does not list SLH-DSA. This omission is sometimes misread as "SLH-DSA is not approved by the NSA"; the correct reading is that SLH-DSA is NIST-standardised and FIPS-validated, and is therefore usable in National Security Systems where a specific procurement justifies it, but it is not the default for general signing in NSS. The reasoning is straightforward: signature size and signing throughput are critical for high-volume operational use, and ML-DSA-87 is the policy answer for that volume.

For commercial long-lived credentials outside NSS, the policy pull is the opposite. Long-term preservation services regulated under eIDAS and ETSI EN 319 401 face a different optimisation: signing throughput is irrelevant, the credential lifetime exceeds the realistic cryptanalytic prediction window for any single algorithm family, and dual-signing with two distinct cryptographic foundations is a long-standing recommendation for high-assurance preservation. The conservative-hash profile of SLH-DSA-256 fits this preservation horizon for the same reasons it does not fit operational JWT signing: a slow, large, but cryptographically minimal signature is exactly what an archival use case wants.

The policy direction is therefore bifurcating. CNSA 2.0 pushes ML-DSA-87 for operational signing volume. ETSI preservation profiles pull SLH-DSA-256 for archival conservatism. Long-lived identity assertions sit on the fault line, and a competent architect picks the algorithm that matches the assertion's lifetime and verification frequency, ignoring whichever algorithm carries the loudest current policy advocacy.

Decision framework for identity-assertion workloads

There is no useful answer to "ML-DSA-87 or SLH-DSA-256" in the abstract. The actual decision is a per-workload mapping driven by three properties: assertion lifetime, signature frequency, and verifier population.

The pattern: as assertion lifetime grows, the optimal algorithm shifts from speed-optimised lattice (ML-DSA-65) to conservative lattice (ML-DSA-87) to conservative hash-based (SLH-DSA-256s) and ultimately to dual-signed combinations that survive a break in either family. The same logic that drove hybrid classical+post-quantum signatures during the migration window applies recursively inside the post-quantum era: when uncertainty is unbounded, sign twice.

Dual-signing in practice

For credentials at the longest end of the lifetime spectrum, the production answer is to attach both signatures to the credential, indexed under distinct JOSE headers, and require that either signature validates at verification time. The credential remains verifiable so long as at least one family—Module-LWE or SHAKE-256 preimage resistance—remains intact.

The cost is signature overhead: ~4.6 KB for ML-DSA-87 + ~29.8 KB for SLH-DSA-256s = ~34.4 KB of signature material per credential, plus headers. For a notarial VC whose payload is typically 2–10 KB of structured claims, this means the signature material dominates the credential size. For a credential signed once and stored for forty years, that is a defensible cost—the alternative is a credential that becomes unverifiable the day either family is broken.

The verification logic is straightforward: the verifier attempts both signatures, accepts on either success, and emits structured telemetry on which family was used (so the operator can monitor for partial breaks). The library API on the PasskeyBridge SDK exposes this as verifyDual(credential, { mlDsa: pkM, slhDsa: pkS }) with a deterministic precedence—SLH-DSA-256s checked first when both signatures are present, on the grounds that a future SHAKE-256 break is the rarer event and a verifier should burn the more conservative budget first.

The PasskeyBridge production split

Our production split for the post-quantum signature stack is now:

• ML-DSA-65 for short-lived assertions: authentication, attestation receipts, JIT capability tokens, webhook signatures.
• ML-DSA-87 for medium-horizon roots: tenant SSO signing keys, federation trust anchors, signed device-binding artefacts.
• SLH-DSA-256s for archival assertions: notarial VCs, eIDAS QES profiles, SOC 2 audit-root signatures that must remain verifiable across our seven-year retention window with margin.
• ML-DSA-87 + SLH-DSA-256s dual-signed for the longest-lived credentials: land-registry seals, multi-decade preservation artefacts, qualified preservation services.
• LMS (SP 800-208) for append-only audit-log rows, where the stateful single-signer model is naturally satisfied and the per-row size cost matters at scale.
• ML-KEM-1024 for key establishment across the entire stack, consistent with CNSA 2.0.

No algorithm is doing every job. The discipline is matching each workload to the algorithm whose security model and operational profile align with the assertion's actual lifetime. For one-hour tokens, ML-DSA-65 is correct and SLH-DSA would be ludicrous overhead. For forty-year notarial credentials, SLH-DSA-256s is correct and the 30 KB signature is the cheapest line item in the credential's lifecycle.

The post-quantum migration is finished when each credential is signed with the algorithm whose threat horizon matches the credential's own, and deploying ML-DSA alone does not get there. For long-lived identity assertions, that horizon is measured in decades, and the algorithm is SLH-DSA-256—or, when the stakes justify it, both.

Read the PasskeyBridge security architecture →

Start free · Test the API