ML-DSA (FIPS 204) explained: the post-quantum signature most systems will use

Published 12 October 2026 · 9 min read · By Ali Korsi ML-DSA is the general-purpose post-quantum replacement for RSA and ECDSA signatures. It is fast, but its keys and signatures are much larger, and that size is what shapes certificates, handshakes and the order of migration.

ML-DSA in one paragraph

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the NIST standard for digital signatures that resist quantum computers. It was published as FIPS 204 in August 2024 and is derived from CRYSTALS-Dilithium. Like ML-KEM, its security rests on module-lattice problems. It replaces RSA, ECDSA and EdDSA wherever they are used to prove who signed something: certificates, TLS authentication, code and firmware signing, documents and tokens.

Why signatures are a different kind of urgent

Signatures are not exposed to harvest-now-decrypt-later attacks in the way key exchange is: a signature recorded today cannot be “decrypted” later. The risk is forgery once a cryptographically relevant quantum computer exists. That sounds less pressing, until you look at how long signing keys and trust anchors live:

• Root certificates are often valid for 20 years or more, and replacing them across every relying party takes years.
• Devices verify firmware with keys burned in at manufacture. A device shipped in 2027 may still be in the field in 2040.
• Signed documents and archives may need to remain verifiable, and unforgeable, for decades.

So the urgency comes from lead time, not from data already being harvested. Anything you sign or ship today that must still be trusted after 2035 needs a post-quantum plan now.

The three parameter sets

For comparison: an Ed25519 public key is 32 bytes and its signature 64; an ECDSA P-256 signature is about 64–72 bytes; RSA-2048 keys and signatures are 256 bytes. ML-DSA signing and verification are fast — often faster than RSA signing — so, as with ML-KEM, the real cost is size.

Which one to choose? ML-DSA-65 is a common general-purpose choice; ML-DSA-44 is used where size matters most; CNSA 2.0 requires ML-DSA-87 for US national security systems. European agencies such as ANSSI and BSI generally ask for category 3 or above, and for hybrid use during the transition.

FIPS 204 also defines a “pre-hash” variant (HashML-DSA) for signing a digest rather than the full message, an optional context string, and both hedged (randomised, the default) and deterministic signing. Make sure the variant you deploy matches what your verifiers expect.

What the size does to certificates and TLS

Every certificate carries a public key and its issuer’s signature, and a TLS 1.3 server also signs the handshake. With ECDSA, that authentication data is a few hundred bytes. With ML-DSA-44 throughout a two-certificate chain, it grows to roughly 10 KB (two public keys, two certificate signatures and the handshake signature). That has knock-on effects:

• Handshakes grow beyond the initial congestion window on some connections, adding round trips.
• Constrained devices and protocols — smart cards, IoT links, some industrial and payment protocols — may not have room for ML-DSA signatures without redesign.
• Certificate Transparency and chains multiply the effect: each additional signature in the path adds kilobytes.

This is why post-quantum certificates are moving more slowly than post-quantum key exchange on the web, and why the order of migration usually puts ML-KEM first and ML-DSA in internal PKI, code signing and firmware before public web PKI.

Hybrid and composite signatures

During the transition, many organisations want a signature that stays valid if either the classical or the post-quantum algorithm fails. There are two broad approaches:

• Composite signatures combine, for example, ML-DSA and ECDSA in one key and one signature that verifies only if both parts verify. The IETF LAMPS working group is standardising composite ML-DSA for X.509.
• Parallel or dual certificates issue a classical and a post-quantum certificate side by side and let each relying party use what it supports.

ANSSI and BSI recommend hybrid approaches during the transition (see our ANSSI guide, in French). Whichever route you take, it has to be supported by your CA software, HSMs and every verifier — which is where planning time goes.

Library and platform support

As of this writing, ML-DSA is available in, among others:

• OpenSSL 3.5 and later;
• Java (JDK 24 and later), through the standard signature and key-pair APIs;
• AWS-LC, Bouncy Castle and the Open Quantum Safe project’s liboqs.

HSM, smart-card and CA product support is uneven and moves with firmware and certification cycles. Check the exact versions in your path — and that the parameter set and variant match on both the signing and the verifying side.

Planning the migration to ML-DSA

1. Inventory every signature use. Certificate signature algorithms across your PKI, code and firmware signing, document and token signing (JWT, SAML, S/MIME), and signature calls in application code. A CBOM records algorithm, key size and location.
2. Rank by trust lifetime. Root and intermediate CAs, firmware keys and long-term document signatures first; short-lived tokens and session authentication later.
3. Check the size budget. Identify protocols, devices and storage formats that cannot absorb kilobyte signatures, and decide between redesign, ML-DSA-44 or a different scheme.
4. Prepare the PKI. CA software, HSMs, certificate profiles and relying-party support; plan root and intermediate rollover, including hybrid or composite options.
5. Start where you control both ends. Internal PKI, code signing and firmware updates are usually easier than public web certificates.
6. Keep it swappable. Algorithms selected by configuration and signing behind central services — crypto-agility — so the next change is cheaper.

Where CRYPTAGION fits

CRYPTAGION covers step 1 and supports step 2. It finds RSA, ECDSA, EdDSA and other quantum-vulnerable signatures in Python, JavaScript/TypeScript, Java, Go and C/C++ source, records the signature algorithm, issuer and validity of X.509 certificates, and inspects live TLS endpoints. Each finding carries its location, a quantum status, a risk score and a recommended replacement — ML-DSA or SLH-DSA for signatures — with a migration year and a roadmap wave, and the inventory exports as a CycloneDX 1.6 CBOM.

Sources

• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
• NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards (November 2024)
• IETF LAMPS working group documents (ML-DSA and composite signatures in X.509)
• Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography

Sizes are taken from FIPS 204; the chain estimate is approximate and excludes extensions and Certificate Transparency data. Library and platform support is summarised as of October 2026 and changes often.

← All resources · Home