Why is the name X25519MLKEM768 two algorithms glued together?

Because that's exactly what it is — a hybrid. X25519 is the elliptic-curve key exchange browsers have used for years; ML-KEM-768 is the post-quantum key encapsulation standardized by NIST as FIPS 203. The group runs both at once and combines their results, so the session is at least as strong as X25519 even if a flaw turns up in ML-KEM, and at least as strong as ML-KEM even if a quantum computer breaks X25519. You get the new protection without betting everything on brand-new math.

Is X25519MLKEM768 the same as X25519Kyber768?

Nearly, but not interchangeable on the wire. The earlier group was X25519Kyber768Draft00 (codepoint 0x6399), built on the draft Kyber before standardization. X25519MLKEM768 (codepoint 0x11EC) uses the final, standardized ML-KEM-768 and is the one that shipped as default — Chrome switched to it in version 131, and OpenSSL 3.5, Go 1.24, Firefox, and Apple's 2025 OS releases all speak it. A client and server have to agree on the same codepoint, so a modern client offering 0x11EC won't negotiate PQ with an old server that only knows 0x6399.

My browser says X25519MLKEM768 — does that mean my server supports it?

Not necessarily. The browser reports what it negotiated with whatever answered the connection, and for most sites that's a CDN edge, not the origin server. The hybrid key exchange can be terminated at Cloudflare or another CDN while the leg from that edge to your actual server still uses classical X25519. Cloudflare reported in September 2026 that about 67% of human HTTPS traffic reaching its network already used post-quantum key exchange, while only around 15% of the origins it connects to did. To know which half you have, you have to test the origin directly.

Do I need a post-quantum certificate to use X25519MLKEM768?

No. Key exchange and certificates are separate problems. X25519MLKEM768 protects the key agreement — the part worth stealing today to decrypt later — and works fine with your existing RSA or ECDSA certificate. Post-quantum signatures are a later migration, and public CAs don't issue post-quantum certificates yet anyway. Switch the key exchange now; leave the certificate alone.

X25519MLKEM768 Explained: The Hybrid TLS Key Exchange

What X25519MLKEM768 actually is

If you opened Chrome’s DevTools Security panel, ran openssl s_client, or read a Cloudflare dashboard and saw X25519MLKEM768, you were looking at the key exchange your connection negotiated. The name looks like a cat walked across the keyboard, but it’s just two algorithms stated back to back:

X25519 — the elliptic-curve Diffie-Hellman key exchange browsers have leaned on for years. Fast, small (a 32-byte public key), and completely breakable by a large quantum computer, if one ever exists.
ML-KEM-768 — the post-quantum key encapsulation mechanism NIST standardized in 2024 as FIPS 203, at the middle (Level 3) parameter set. It’s designed to resist both classical and quantum attacks, and it’s the successor to the algorithm you may have seen called Kyber.

Put them together and you have a hybrid key exchange: a single TLS 1.3 named group (codepoint 0x11EC, marked Recommended in the IANA registry) that performs both at once. The client offers one key share that packs an ML-KEM-768 encapsulation key and an X25519 public key; the server replies with an ML-KEM ciphertext and its own X25519 key. Each side derives a shared secret from each algorithm and feeds the combination into TLS 1.3’s key schedule. The resulting session key depends on both — which is the whole point.

Why pair two algorithms instead of just shipping the new one

Because nobody fully trusts the new one yet, and they’re right not to.

ML-KEM is young. It’s been through NIST’s competition and standardization, which is about as much scrutiny as a cryptographic primitive can get, but “survived the process” is not the same as “survived twenty years of people trying to break it in the wild.” Lattice cryptography could still have a bad day. So instead of replacing X25519 with ML-KEM and praying, the hybrid runs them side by side. An attacker has to break both to recover the session: the old, battle-tested curve and the new, quantum-resistant lattice. If either one holds, your traffic stays secret.

The urgency behind all of this is a threat with an unglamorous name: harvest now, decrypt later. An adversary who can’t break X25519 today can still record your encrypted traffic today and sit on it. The day a cryptographically relevant quantum computer arrives — years out, maybe, but the recording is cheap and patient — they decrypt the backlog. Anything with a long secrecy shelf life (health records, source code, state secrets, the contents of a password manager sync) is already exposed to that bet. Hybrid key exchange is the defense you deploy before the computer exists, because deploying it afterward is too late by definition. That’s also why key exchange went first and signatures can wait: a signature only has to resist forgery at the moment of the handshake, but a key agreement has to stay secret for as long as the data matters.

What it looks like on the wire

The hybrid isn’t free, and the cost is size. X25519’s public key is 32 bytes. ML-KEM-768’s encapsulation key is 1,184 bytes and its ciphertext 1,088. So the client’s key share balloons from 32 bytes to well over a kilobyte, and the ClientHello that used to fit comfortably in a single packet now often spills past the ~1,500-byte path MTU into a second one. For the overwhelming majority of connections this is invisible. But it’s a real reason a handful of broken middleboxes and buggy servers — the ones that choke on a ClientHello split across packets — started failing right as hybrid rolled out, which is its own kind of recon signal about who runs fragile network gear.

Where you already have it (and where you might not)

This stopped being experimental a while ago. X25519MLKEM768 is the default offer in a modern client stack:

Chrome since version 131 (November 2024), and other Chromium browsers.
Firefox and Apple’s 2025 OS releases (the iOS 26 wave pushed Apple-device adoption up sharply).
Go since 1.24 (February 2025), enabled by default in crypto/tls.
OpenSSL since 3.5.0 (April 2025), which not only understands the group but prefers it.

The gap is on the server side, and it’s wide. When a browser shows you X25519MLKEM768, it negotiated that with whatever terminated the TLS connection — and for most sites that’s a CDN, not the origin. The CDN edge can speak hybrid to your visitors while the hop from the edge to your actual server quietly falls back to classical X25519. That’s the CDN-inheritance trap: the half the public sees is protected, the half behind it may not be. Cloudflare’s own September 2026 figures captured the split — roughly 67% of human HTTPS traffic arriving at its edge used post-quantum key exchange, against only about 15% of the origins it connected to onward.

How to tell whether a connection really uses it

Three ways, in rough order of how much they tell you:

In a browser: open the site in a current Chrome, then DevTools → Security, and read the key exchange line. Fast, but it only shows what your browser negotiated with the edge — not your origin.
With OpenSSL 3.5+: openssl s_client -connect example.com:443 -groups X25519MLKEM768. If the handshake completes, that endpoint supports the hybrid; if it returns a handshake_failure alert, it doesn’t. Point it at your origin’s real address to see past the CDN.
With DechoNet’s PQC check: it offers only the hybrid group and reports whether the key exchange completed, flags when the support is coming from a CDN edge rather than the origin, and records the result over time. For the step-by-step version — including turning it on in nginx, Apache, or Go — see the companion guide, Post-Quantum TLS Check. For the deadlines driving the migration, see the post-quantum timeline.

Diagnose with DechoNet

PQC Check tests whether a host negotiates X25519MLKEM768 and tells you if the support stops at a CDN edge.
SSL Check shows the certificate and TLS version, so you can confirm the connection is TLS 1.3 — the only version this group exists in.

What this is not

It is not a certificate change. Your RSA or ECDSA certificate is fine and should stay.
It is not something you can “turn on” in DNS or a certificate — it’s a server TLS-library capability, which is why the fix is usually “upgrade OpenSSL to 3.5+ / Go to 1.24+ / your proxy to a build that offers the group.”
It is not a full post-quantum migration. It’s the first and most urgent step of one, because it’s the step that defends against recording done today.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.