ML-KEM vs ML-DSA: which do you deploy first? That’s how the question usually gets posed, as a head-to-head between two NIST-standardised post-quantum algorithms, as if one should win and the other wait. Here’s the fact that doesn’t fit that story. The ML-KEM-based hybrid X25519MLKEM768 already carries most browser-to-edge web traffic, while ML-DSA certificates remain effectively at zero. A simple “which algorithm is better” answer can’t explain that gap.
TLS has always done two jobs. It establishes session keys so traffic can’t be read, and it authenticates identity so you know who you’re talking to. The two algorithms in the question serve those two different jobs. Once you see that, “which first” is a sequencing decision. By the end you’ll know why the sequence falls the way it does, how to read the adoption numbers, and where your stack sits between the two migrations.
ML-KEM, ML-DSA or SLH-DSA: which do you actually need first, and why are signatures the later problem?
Deploy ML-KEM (FIPS 203) first. Key establishment is retroactively breakable; authentication isn’t. Traffic you secure today with RSA or Diffie-Hellman can be recorded now and decrypted later once a quantum computer exists, the harvest-now-decrypt-later pattern. A forged signature can only be produced in real time, once a quantum computer exists. That difference in exposure direction dictates the order.
The two jobs TLS actually does
ML-KEM is the confidentiality primitive, a module-lattice key encapsulation mechanism that two parties use to agree a shared secret. ML-KEM-768 puts roughly 2.3 KB of wire data where X25519 needs 64 bytes. ML-DSA (FIPS 204) is the authentication primitive, with signatures around 2.4 KB at ML-DSA-44 (the 44-parameter set) against roughly 70 bytes for ECDSA. SLH-DSA (FIPS 205) is the conservative hash-based fallback, resting only on hash-function assumptions, with signatures from 7,856 bytes up to 49,856 bytes.
That size gap is the first hint of why the two migrations move at different speeds. Signatures lag for operational reasons. Certificates are long-lived, chained, cached, embedded in firmware and validated by trust stores on devices that won’t be updated. Migrating the PKI is the slow part because it touches X.509, certificate authorities and trust at once, which is why PKI migration is often the most complex part of post-quantum preparation.
On the standards: FIPS 203, 204 and 205 were finalised in August 2024. NIST IR 8547 is a separate document, an Internal Report rather than a FIPS, and it sets the deprecation path: RSA and elliptic-curve algorithms deprecated by 2030 and disallowed by 2035 (proposed dates that already work as the baseline for procurement and audit).
Should you wait for a better signature scheme?
ML-DSA isn’t the smallest or most elegant signature scheme. FN-DSA, formerly Falcon, has smaller keys and signatures on paper, and newer candidates like MAYO, SNOVA and SQIsign have their attractions, but none is likely to be standardised before 2028 and FN-DSA isn’t expected to be widely available until around 2033. Certificates live for years, trust stores update slowly, and hardware validation cycles are long. As TLS 1.3 editor Eric Rescorla puts it, you go to war with the algorithms you have, not the ones you wish you had, and Cloudflare’s companion position in the same post is that ML-DSA is available today and will have to do for the first migration. Google’s roadmap points the same way.
SLH-DSA earns a narrow place. It’s the diversity play for code signing and firmware root keys, where a long-lived key you can’t easily replace argues for hash-based conservatism, but it’s too large to be a general-purpose certificate replacement. That leaves RSA, ECDH, ECDSA, Diffie-Hellman and DSA as the primitives being displaced, which your own inventory will already have found.
Hybrid versus pure post-quantum key exchange: why X25519MLKEM768 already carries most web traffic
X25519MLKEM768 concatenates a classical X25519 ECDH share with an ML-KEM-768 encapsulation and mixes both shared secrets into the TLS 1.3 key schedule, so the session survives unless an attacker breaks both. That single property is why it could ship before anyone was confident about lattice cryptanalysis: it is strictly no worse than the classical cryptography it replaced.
Why it shipped before anyone trusted lattices
The change lives in the ClientHello key share. TLS 1.3 negotiates that key share at the very start of the handshake, so a client and a server can enable the hybrid independently, with no certificate changes, roughly a kilobyte of extra handshake bytes, and a graceful fallback for anything that doesn’t understand it. Signatures need new certificate types, CA support and device trust-store updates, so they can’t move the same way, and TLS 1.2 can’t carry the hybrid at all, because its handshake predates the flexible key_share extension.
Where adoption is real, and where it isn’t
Browser-to-edge traffic is largely hybrid: around 70% of browser traffic reaching Cloudflare is protected, while only about 15% of the origins it connects to used hybrid ML-KEM in the same measurement. Edge percentages flatter the estate. Origin connections, service meshes, API gateways and non-HTTP protocols lag behind, and the same trackers publish live numbers for both directions if you want to check.
The hidden costs are worth naming. The larger ClientHello interacts with MTU and fragmentation on some paths, some middleboxes mishandle large ClientHellos, and TLS-terminating appliances can strip or reject the key share. There’s also a regulatory fork, mostly for government buyers: CNSA 2.0 mandates pure ML-KEM-1024 in the US, and Australia’s ASD ISM prefers ML-KEM-1024 while calling hybrid schemes “not recommended; however, it is not prohibited”. Regulated buyers can’t copy the civilian default, and the CNSA 2.0 versus ASD ISM split matters for anyone selling to government.
Conclusion
So “ML-KEM vs ML-DSA, which first” is a sequence: ML-KEM now, ML-DSA and SLH-DSA as the certificate ecosystem catches up. Production has already voted in that order, because key exchange shipped as a no-regret handshake change while certificates waited on the slower PKI migration.
You don’t pick a side; you locate where your business sits between the two migrations, and a cryptographic inventory makes that placement concrete. Read edge percentages sceptically, check your own origin connections and non-HTTP paths, and audit for what is enforced rather than what appears on a feature list. With the 2030 deprecation and 2035 disallowance clock running, shipping the good-enough scheme now beats waiting for the perfect one. The hybrid already proved that rule, and signatures will have to follow it too.
Frequently Asked Questions
Is ML-KEM just a renamed Kyber?
No. ML-KEM is the standardised descendant of CRYSTALS-Kyber, published as FIPS 203 in 2024, and the final specification changed several details from the competition version. Code and documentation that still say Kyber may not match the standard on the wire. When you see X25519MLKEM768, the ML-KEM half is the FIPS 203 algorithm at the 768 parameter set, combined with a classical X25519 share.
What actually breaks if the key exchange is post-quantum but the certificate signature is not?
The session keys stay protected against a future quantum computer, but authentication does not. An attacker with a cryptographically relevant machine could forge the certificate signature and impersonate the server during a live handshake. They could not go back and decrypt traffic recorded today, because the hybrid key exchange has already closed that exposure. Real-time impersonation is the remaining risk, and it is the one the signature migration addresses.
How do I check whether my own site is negotiating X25519MLKEM768?
Open the connection in a current browser and inspect the security panel, or use a TLS scanner that reports the negotiated key exchange group. From the command line, OpenSSL 3.5 and later can show the group with openssl s_client -connect host:443. Check the origin as well as the edge, because a hybrid browser-to-CDN hop tells you nothing about the CDN-to-origin connection.
What happens to clients and devices that do not support the hybrid? Are they locked out?
No. X25519MLKEM768 is negotiated, not enforced, so a client that does not offer it falls back to a classical group and the connection still completes. That fallback is also the weakness: an attacker who can strip the offer can force the downgrade. Treat support as the first step, preference as the second, and disable classical-only negotiation wherever your client estate allows it.
What does “fully post-quantum” actually mean, and is supporting ML-KEM enough?
Supporting ML-KEM is not the same as being migrated. A system is only fully post-quantum when every hop that carries or authenticates the data uses quantum-resistant algorithms and classical-only negotiation is disabled. If a load balancer offers the hybrid but still accepts X25519-only handshakes, the downgrade path remains open. Audit for what is enforced, not for what appears on a feature list.
Are backups and archived data covered by post-quantum TLS, or only live traffic?
Post-quantum TLS protects data in transit, so it covers the moment a backup is written to remote storage but not the stored copy itself. Data at rest encrypted with AES-256 is already considered quantum-resistant, because Grover’s algorithm only halves the effective key length. The retroactive exposure sits in traffic recorded without hybrid key exchange, not in archives you encrypted with strong symmetric ciphers.
Can I run ML-DSA certificates in a private PKI today?
Yes. Private certificate authorities, including AWS Private Certificate Authority and OpenSSL 3.5, can issue and validate ML-DSA certificates now, and internal mutual TLS is the easiest place to build operational experience. Public trust is the constraint: browsers and public certificate authorities have not yet enabled ML-DSA chains at scale. Start private, learn the chain sizes and rotation mechanics, and keep the public migration separate.
Does hybrid key exchange need TLS 1.3, or does it work on TLS 1.2?
X25519MLKEM768 is defined for TLS 1.3 and QUIC, and it relies on the TLS 1.3 key schedule and key share extension. TLS 1.2 does not carry it. That matters because legacy endpoints, older appliances and some internal services still terminate TLS 1.2, so they cannot negotiate the hybrid at all. Upgrading those endpoints is part of the migration, not a separate tidy-up.
What happens if ML-KEM is broken by a cryptanalysis breakthrough? Does the hybrid collapse?
No. The hybrid combines X25519 and ML-KEM-768 secrets, so an adversary would need to break both to recover the session. A weakness in the lattice half leaves the classical half holding, which is the point of the design. That is a temporary reprieve rather than a permanent answer: if ML-KEM falls, you need to move to another post-quantum KEM before X25519 itself becomes breakable.
Do we actually need to act now, or is this vendor noise?
The deadlines are real and close enough to plan against. NIST IR 8547 deprecates RSA and elliptic-curve algorithms by 2030 and disallows them by 2035, and recorded traffic is already exposed to harvest-now-decrypt-later collection. The honest position is that key exchange is urgent, public certificate migration is not yet, and inventory plus agility work is what makes both affordable. Waiting is a decision with a cost.
