ML-DSA and SLH-DSA Post-Quantum Signatures Guide: Parameter Sets, Certificates and Migration Order

Every RSA and elliptic curve signature that protects a certificate chain, a software update or a firmware image will become forgeable once a cryptographically relevant quantum computer exists, and the signing keys behind the longest-lived trust anchors are already in service today. NIST published two post-quantum signature standards on 13 August 2024: FIPS 204 (ML-DSA, module-lattice based) and FIPS 205 (SLH-DSA, stateless hash based), and the IETF has since published the X.509 profiles for both. Signature migration is a different problem from key exchange: it touches PKI hierarchies, code signing, secure boot and document signing, and the sizes and performance differ enough to change designs. This guide covers how the two algorithms differ, which parameter set fits which job, how they appear in certificates, where stateful LMS and XMSS still belong, and in what order to migrate. It is for PKI owners, product security and firmware teams, and architects planning post-quantum work. For the programme view see the Post-Quantum Cryptography Migration Guide.

Key takeaways

• Two standards, two jobs. ML-DSA is the general-purpose replacement for RSA and ECDSA signatures; SLH-DSA is the conservative, hash-only option with tiny keys and very large signatures.
• Signatures are about future forgery, not past secrecy. There is no harvest-now-decrypt-later effect, so prioritise by how long a signature or trust anchor must stay valid.
• Use pure mode in certificates. RFC 9881 prohibits HashML-DSA in X.509 certificates and CRLs; RFC 9909 allows both pure and pre-hash SLH-DSA but a key must stick to one.
• Store the seed. RFC 9881 recommends the 32-byte seed as the ML-DSA private key format, which affects HSM import, export and backup design.
• Roots and firmware first. Long-lived roots of trust and boot keys must be in place years before devices retire, which is why stateful LMS and XMSS are already used in secure boot.

Why signature migration is different from key exchange

Key establishment (ML-KEM, covered in the ML-KEM Guide) is urgent because recorded traffic can be decrypted later. A signature cannot be "decrypted"; the threat is that an attacker with a quantum computer derives the private key from a public key and then signs whatever they like. That changes the priorities:

• Validity period drives urgency: a TLS handshake signature matters for seconds; a root CA certificate, a firmware signing key burnt into a boot ROM or a signed contract can matter for decades.
• Verifiers must change first: a new signature is useless until every relying party can verify it, so the long pole is updating verifiers in browsers, devices, bootloaders and validation services.
• Hardware roots of trust are slow: the NCSC notes that vendors already use LMS and XMSS for secure boot and that new standards are still needed for X.509 PKI, TPMs and UEFI Secure Boot.
• Revocation is the backstop: once traditional algorithms are distrusted, quantum-safe authentication is only achieved when traditional certificates have expired or been revoked, as the NCSC points out.

ML-DSA and SLH-DSA compared

For comparison, an ECDSA P-256 signature is 64 bytes and an RSA-2048 signature is 256 bytes. Even the smallest ML-DSA signature is roughly ten times an RSA-2048 signature, and a certificate chain carries several signatures and public keys, so expect handshakes, signed tokens and constrained-device protocols to grow noticeably.

Choosing a parameter set

ML-DSA

FIPS 204 does not mandate one set; it assigns each to a security category and sets random bit generator strength requirements (at least 128 bits for ML-DSA-44 with 192 recommended, 192 bits for ML-DSA-65 and 256 bits for ML-DSA-87). Practical guidance: ML-DSA-65 is a sensible default for enterprise PKI and code signing, ML-DSA-87 where a policy requires category 5 or the key protects a long-lived root, and ML-DSA-44 where size is tight and the data's lifetime is short.

• Hedged signing: the default variant mixes a fresh 32-byte random value into each signature. A deterministic variant exists, but FIPS 204 advises against it where side-channel attacks are a concern and cannot otherwise be mitigated. Verification is identical for both.
• Context strings: both standards accept a context string of up to 255 bytes (default empty), which lets a protocol bind a signature to its purpose. Use one where the protocol specification defines it; do not invent private values that other verifiers will not know.
• Pure versus HashML-DSA: FIPS 204 says pure ML-DSA is generally preferred and that a key pair should be used for only one of the two versions.

SLH-DSA

FIPS 205 defines twelve parameter sets: SHA2 or SHAKE, at category 1, 3 or 5 (128, 192 or 256), each in an "s" (small signature, slower signing) and an "f" (fast signing, larger signature) form. The X.509 profile, RFC 9909, lists the sizes:

Choose "s" sets where signatures are created rarely and verified often (root CA certificates, firmware releases, archives) and "f" sets only where signing throughput matters more than size. Choose SHA2 or SHAKE to match what your HSMs and verifiers accelerate.

Post-quantum signatures in certificates

• Seed format and HSMs: confirm that your HSM or KMS can generate, store and back up ML-DSA keys in the seed form and can export or import in the format your PKI software expects. A mismatch between seed-only and expanded-key systems is a likely early interoperability failure. See the HSM Deployment and Operations Guide.
• External mu: where a signing service receives only a digest (remote signing, HSM-bound keys with large files), use the external mu mechanism defined in RFC 9881 Appendix D rather than HashML-DSA.
• Composite certificates: the IETF composite signatures draft, draft-ietf-lamps-pq-composite-sigs-19, pairs ML-DSA with RSA, ECDSA, Ed25519 or Ed448 in a single public key and signature. When checked on 27 October 2026 it was in the RFC Editor queue pending final approval, so treat identifiers and details as subject to change until the RFC is published. The draft notes it provides EUF-CMA rather than SUF-CMA security.
• Public web PKI: the NCSC notes there is not yet an agreed way to add post-quantum signatures to the WebPKI while staying compatible with existing components. Enterprise and private PKI can move earlier than public TLS certificates.

Where stateful hash-based signatures still fit

NIST SP 800-208 (October 2020) approves LMS and its multi-tree HSS form, and XMSS and XMSS^MT. They are mature and already used for secure boot, but every one-time key in the tree must be used once only: reusing state, for example after restoring an HSM from backup or cloning a signing VM, can break security entirely.

• Use them when: the signing volume is known and small (firmware releases), signing happens in one controlled place, and the verifier is a boot ROM or bootloader that benefits from small, simple hash-based verification.
• Avoid them when: signing is distributed, high volume, automated in CI at scale, or depends on VM snapshots and backups that could roll state back. Use SLH-DSA, which gives a hash-based assurance argument without state.
• Plan capacity: choose tree heights that cover the product's whole signing life with margin, and monitor remaining signatures as an operational metric.

See the Firmware and Boot Security Guide.

Migration order and decision guidance

Choosing between ML-DSA and SLH-DSA: pick ML-DSA when signatures travel often and size and speed matter (handshakes, tokens, frequent code signing). Pick SLH-DSA when you sign rarely, verification is cheap enough, and you want an assurance argument that does not depend on lattice assumptions, which is why it suits roots and firmware. Some organisations deliberately use both, so a weakness in one family does not break every trust anchor.

Small vs large organisations: most small organisations will not run their own post-quantum PKI; their job is to inventory where signatures are verified, ask suppliers for roadmaps and keep certificate and signing tooling current. Large organisations and product vendors must design new roots, update HSM estates and change build pipelines, and should start with a lab PKI now. The NCSC timeline expects discovery and planning by 2028, priority migrations by 2031 and full migration by 2035. NIST IR 8547, which proposes transition dates for quantum-vulnerable algorithms, was still an initial public draft when checked on 27 October 2026, so plan to its direction rather than to exact dates.

Implementation steps

1. Inventory signatures and verifiers: list every place a signature is created and, more importantly, verified: CAs, code signing, package repositories, boot chains, SAML and JWT signers, document signing. Record the algorithm, key location and how long the signature must stay valid. See the Cryptographic Inventory and CBOM Guide.
2. Rank by lifetime and updatability: anything verified by code that cannot be updated in the field, or trusted for more than ten years, goes first.
3. Check the platform: confirm FIPS 204 and FIPS 205 support in your HSMs, KMS, crypto libraries and PKI software, including the RFC 9881 seed format and the module's validation status. See the FIPS 140-3 and Cryptographic Module Validation Guide.
4. Build a lab PKI: create a test post-quantum root and issuing CA, issue certificates, and test path validation, CRL and OCSP signing, and certificate size limits in every relying application. Record failures as supplier requirements.
5. Dual-sign where formats allow: for code and packages, add a post-quantum signature alongside the existing one so old verifiers keep working. Roll back by dropping the new signature; nothing that verified before breaks.
6. Introduce the new root: distribute it to trust stores well before issuing production certificates from it, using a parallel hierarchy or cross-signing as the NCSC describes.
7. Retire traditional signatures: once verifiers are updated, stop issuing traditional certificates and let them expire or revoke them. Until then, authentication is not quantum-safe.

Detection and measurement

• Signing logs: log every use of root, code signing and firmware keys in the HSM, with the requesting identity and the artefact hash, and alert on use outside release windows.
• Verification failures: monitor certificate validation and signature verification errors after each change; size limits and unknown OIDs show up here first.
• Stateful key capacity: track remaining one-time signatures for LMS and XMSS keys.

Framework mapping

Common failure patterns

• Treating signatures like KEMs: starting with short-lived TLS certificates because that is where the tooling is, while boot ROM keys and roots, which cannot be changed later, wait.
• State reuse: running LMS or XMSS signing in a VM or HSM that is snapshotted, cloned or restored, silently reusing one-time keys.
• Size surprises: certificates or signed tokens that exceed header, packet or field limits in older middleware, load balancers or constrained devices, found only in production.
• Using HashML-DSA in certificates: choosing pre-hash for convenience when RFC 9881 prohibits it in X.509, instead of using the external mu approach.
• No re-signing capability: organisations that cannot re-sign and redistribute their software quickly struggle with any signing change. The AnyDesk breach forced a code signing certificate revocation and moves to newly signed versions; post-quantum migration needs the same capability, planned rather than forced.
• Waiting for drafts to settle everywhere: composite and protocol drafts are still moving, but FIPS 204, FIPS 205, RFC 9881 and RFC 9909 are final; lab work on those can start now.

Practitioner checklist

• Inventory every signature creation and verification point with its algorithm, key location and required validity period.
• Rank migration by trust lifetime and whether the verifier can be updated in the field.
• Default to ML-DSA-65 for general signing; use ML-DSA-87 or SLH-DSA "s" sets for long-lived roots and firmware.
• Use pure ML-DSA in certificates and external mu for digest-based signing; never HashML-DSA in X.509.
• Confirm HSM and KMS support for FIPS 204 and FIPS 205, including the RFC 9881 seed private key format.
• Restrict LMS and XMSS to controlled, low-volume signing with no snapshots or restores of state.
• Stand up a lab post-quantum PKI and test every relying application for size and OID handling.
• Dual-sign code and packages during transition and plan root distribution years ahead of issuance.
• Track composite signature and IR 8547 status and record the date each was last checked.

Standards and references

• NIST: FIPS 204 Module-Lattice-Based Digital Signature Standard
• NIST: FIPS 205 Stateless Hash-Based Digital Signature Standard
• NIST: SP 800-208 Recommendation for Stateful Hash-Based Signature Schemes
• IETF: RFC 9881 Algorithm Identifiers for ML-DSA in X.509
• IETF: RFC 9909 Algorithm Identifiers for SLH-DSA in X.509
• IETF: Composite ML-DSA for use in X.509 PKI and CMS (Internet-Draft)
• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards (Initial Public Draft)
• NCSC: Timelines for migration to post-quantum cryptography

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Crypto-Agility Guide · Digital Signatures Guide · Code Signing Security Guide · Post-Quantum Migration for NHIs Guide