What are ML-KEM, ML-DSA and SLH-DSA — and which one does your browser use today?

What did NIST actually standardize on August 13, 2024?

Three algorithms, each with its own federal standard: FIPS 203 (ML-KEM), a key-encapsulation mechanism derived from CRYSTALS-Kyber; FIPS 204 (ML-DSA), a digital signature scheme derived from CRYSTALS-Dilithium; and FIPS 205 (SLH-DSA), a hash-based signature scheme derived from SPHINCS+ (NIST announcement, 2024-08-13). That date matters: it is the moment post-quantum cryptography stopped being a research menu and became a compliance object — exact parameter sets, exact byte formats, test vectors, and a FIPS validation path that procurement departments can write into contracts.

The names confuse people, so Rosetta Quantum will state the mapping once, plainly: Kyber became ML-KEM (Module-Lattice Key-Encapsulation Mechanism), Dilithium became ML-DSA (Module-Lattice Digital Signature Algorithm), and SPHINCS+ became SLH-DSA (Stateless Hash-based Digital Signature Algorithm). A vendor datasheet that still says «Kyber» is describing the pre-standard algorithm; the deployed, standardized object is ML-KEM (FIPS 203, 2024-08-13).

One number frames everything below, and it is the asymmetry of this transition: of those three standards, exactly one is running in your browser today — and it is not a signature.

What is ML-KEM — the one you are already using?

ML-KEM is the key-exchange workhorse: a key-encapsulation mechanism (KEM) whose job is to let two machines that have never met agree on a shared secret key, which then encrypts the session. Its security rests on structured lattice problems (Module-LWE), and FIPS 203 (2024-08-13) defines three parameter sets — ML-KEM-512, ML-KEM-768 and ML-KEM-1024 — at NIST security categories 1, 3 and 5 respectively.

What your browser actually runs is X25519MLKEM768: a hybrid that performs both a classical X25519 exchange and an ML-KEM-768 encapsulation and mixes the two secrets, so an attacker would have to break both at once (IETF draft-ietf-tls-ecdhe-mlkem). Chrome has shipped it by default since Chrome 131 (Google security blog, 2024-09), Firefox since 132, and Safari since version 26; the per-stack support matrix, with versions and dates, is in the Rosetta adoption piece published yesterday: how much Internet traffic already negotiates post-quantum encryption.

The measured result, not the promise: ≈70% of browser-generated HTTPS traffic to Cloudflare's network already negotiated post-quantum key agreement as of the 2026-09-29 reading, about 45 billion post-quantum connections per day, while only ≈15% of scanned origin servers supported it on their side (Cloudflare blog, 2026-09-29). If you did nothing, your users' browsers are already asking for ML-KEM; whether your servers answer is the part you control.

What are ML-DSA and SLH-DSA — and why do they protect nothing in your browser yet?

They are the signature standards, and the direct answer is: zero publicly trusted TLS certificates use them today. Signatures do a different job than key exchange — they prove who you are talking to. Every TLS connection you make today is still authenticated by RSA or ECDSA certificates; the post-quantum part of your connection, where it exists, is only the key agreement.

ML-DSA (FIPS 204, 2024-08-13) is the general-purpose successor: lattice-based, fast, with signatures of 2,420 to 4,627 bytes depending on parameter set. SLH-DSA (FIPS 205, 2024-08-13) is the conservative backup: it relies only on hash functions — the most battle-tested assumption in cryptography — at the price of signatures from ≈7.9 KB up to ≈49 KB, which points it at firmware and code signing rather than TLS handshakes.

Why the delay in the Web PKI? Arithmetic, mostly. A typical TLS handshake today carries five signatures and two public keys; swapping them all to ML-DSA would push a single handshake above 10 KB (Let's Encrypt roadmap coverage, Help Net Security, 2026-06-05). Two escape routes are being built in public: putting ML-DSA into classic X.509 certificates anyway, and Merkle Tree Certificates (MTC) — a redesign that collapses the handshake to one signature, one key and one inclusion proof, which Let's Encrypt will target with a staging environment in late 2026 and production in 2027 (Help Net Security, 2026-06-05). Both of those dates are declared plans, not shipped systems.

The regulators already priced this asymmetry in: the US federal deadline for post-quantum key exchange on high-value assets is 2030-12-31, while signatures get until 2031-12-31 (EO 14412 / OMB M-26-15, read 2026-06-22). And if you want a reminder of why signing infrastructure deserves the attention, the largest theft in history five days ago — ≈US$6.36B from Binance (TRM Labs, 2026-10-30) — compromised the conventional signing layer, with zero quantum computers involved: what the largest hack in history changes for your security.

What are HQC and FN-DSA — the two still in the pipeline?

HQC is the insurance policy. NIST selected it on 2025-03-11 as a fifth algorithm and backup KEM precisely because it is built on error-correcting codes, a different mathematical family from ML-KEM's lattices — so a mathematical breakthrough against one would not take down both (NIST PQC bulletin, 2025-03-11). NIST announced a draft standard for 2026 and a final standard expected in 2027; as of Rosetta's documentary scan of 2026-11-01, no published HQC draft was found yet, so both dates remain declared, not delivered.

FN-DSA (Falcon, the future FIPS 206) is the compact-signature candidate — public keys of 897 bytes and signatures of ≈666 bytes at its smallest parameter set, per the Falcon submission. Its draft has still not been published: NIST wrote on 2026-04-13 that FIPS 206 was «in the administrative approval chain for publication» with no concrete release date (NIST pqc-forum, consulted 2026-11-01). If a vendor tells you their product is «FIPS 206 certified», that certificate does not exist yet.

Which algorithm runs at which layer of your stack?

This is the table Rosetta Quantum suggests you keep. The five algorithms, what each one is for, and what is true in production today:

And the sizes, because they explain the deployment order better than any roadmap — key exchange went first partly because its post-quantum penalty is small, while signatures multiply:

The full engineering consequences of those numbers — what they will break in DNSSEC, in constrained devices, in certificate chains — will get their own piece in this series.

Where does the PQC board stand today?

The Rosetta PQC board, one row per indicator, latest reading per row, re-verified where dated today:

What should a security manager do with these four names?

First, inventory by layer, not by slogan. «Post-quantum readiness» is not one checkbox; it is at least three: key exchange (FIPS 203 — already deployable, often already deployed client-side), TLS certificates (FIPS 204/205 — nothing to deploy in the public Web PKI yet), and code/firmware signing (FIPS 204/205 — where data lives longest and where the Binance lesson about signing infrastructure applies with no quantum computer anywhere in sight).

Second, use one question on every vendor: which FIPS number, at which layer, in which mode? «Quantum-safe» without a standard number is marketing; «ML-KEM, hybrid, for transport» is an answer you can verify. A claimed FIPS 206 or HQC certification today is a claim about a standard that has not been published.

Third, sequence by the measured clock, not the loud one. Hybrid key exchange is cheap to turn on now, and the harvest-now-decrypt-later arithmetic — how long your data must stay secret versus when a cryptographically relevant quantum computer might exist — is the honest way to pick your own deadline: what is harvest-now-decrypt-later and what data is at risk today. For signatures, the regulator calendars above are the binding dates; the house walkthrough is when do RSA and ECC actually expire.

Fourth, keep the zeros in view. The public record still shows 0 RSA-2048 keys broken by a quantum computer and 0 breaches attributed to a quantum attack (both re-verified 2026-11-01, Rosetta documentary review). Rosetta's own Q-Day position — floor of 2031, central window 2033–2039 (sealed judgment RQ-PRED-QDAY-001, 2026-10-09) — is exactly that: a sealed, refutable judgment, not a measurement, published so it can be scored later: when is Q-Day coming, based on what can be measured today. Anyone selling you urgency without numbers next to it is selling boxes.

What we don't know

• Whether the HQC draft will in fact appear before 2026 ends, and whether the final-in-2027 expectation will hold. Both are NIST declarations (2025-03-11); our 2026-11-01 scan found no published draft.
• When FIPS 206 (FN-DSA) will be released — NIST itself gives no date (pqc-forum, 2026-04-13).
• Which signature path the Web PKI will converge on — ML-DSA in classic X.509, Merkle Tree Certificates, or both. The answer will change what a migration plan looks like, and MTC production is a 2027 target, not a product.
• Whether Cloudflare's ≈70% generalizes beyond Cloudflare's network — it is the best public instrument we will have until someone else publishes a comparable series, and the instrument caveats are detailed in the adoption piece.
• Whether structured-lattice assumptions, which ML-KEM and ML-DSA share, hold over decades. That uncertainty is not a rumor of a break — none is public — it is the stated reason HQC and SLH-DSA exist as backups on different math.

Rosetta Quantum publishes verdicts with raw, reproducible data and dated sources. This is educational content, not a product claim and not purchasing advice; Rosetta recommends no vendor.