X25519MLKEM768 explained: post-quantum key exchange in TLS today

X25519MLKEM768 is a hybrid TLS 1.3 key exchange group that runs classical X25519 and the post-quantum ML-KEM-768 side by side and mixes both results into one session key. If you see it in browser dev tools or a server log, the connection is already protected against a future quantum computer reading recorded traffic. The session stays secure as long as at least one of the two algorithms holds.

This page explains what the name means, who supports it as of October 2026, what it changes on the wire, and how to check your own servers.

What the name means

The string is a TLS "named group", the identifier a client and server use to agree on how to exchange keys. It has two halves:

• X25519 is the elliptic-curve Diffie-Hellman exchange that most TLS 1.3 connections have used for years. A large quantum computer running Shor's algorithm could break it.
• MLKEM768 is the Module-Lattice-Based Key-Encapsulation Mechanism at the 768 parameter set, standardised by NIST as FIPS 203 (final on August 13, 2024). It was previously known as Kyber.

The group has the codepoint 0x11EC (decimal 4588) in the IANA TLS registry. It is defined in RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", a Proposed Standard that grew out of draft-ietf-tls-ecdhe-mlkem. The IETF datatracker page lists it as published in August 2026.

Why a hybrid and not ML-KEM alone

There are two reasons, both about not betting everything on a young algorithm.

1. Cryptanalysis risk. Lattice cryptography is far newer than elliptic curves. If someone finds a weakness in ML-KEM, X25519 still protects the session against everyone who does not have a quantum computer.
2. Implementation risk. Bugs such as the KyberSlash timing attacks show that a correct algorithm can leak through a flawed implementation. Cloudflare discusses both points in its post on post-quantum key agreement.

The combined secret is 64 bytes: 32 from each component, fed into the TLS 1.3 key schedule.

The threat it addresses: harvest now, decrypt later

An attacker who records encrypted traffic today can store it and decrypt it years later if a quantum computer becomes available. That makes key exchange the urgent part of the migration. Signatures and certificates only need to resist forgery at the moment of the handshake, so they are less time-critical. Hybrid key exchange fixes the recording problem without waiting for post-quantum certificates.

It does not change your certificates. The server certificate is still RSA or ECDSA, and authentication is unchanged.

Who supports it (as of October 2026)

Support is broad on the client side and growing on servers. Sources are linked where I could verify them.

• Browsers. According to Cloudflare's 2025 review, Chrome enabled post-quantum key agreement by default on desktop in March 2024, Android Chrome and desktop Firefox followed in November 2024, and Apple enabled it with iOS, iPadOS and macOS 26 in October 2025. The early Chrome version used the pre-standard Kyber name; current builds offer the final X25519MLKEM768 group.
• OpenSSL. Since 3.5.0 (April 8, 2025) the default key shares offer X25519MLKEM768 and X25519, and the default group list prefers hybrid groups, per the OpenSSL 3.5 NEWS. OpenSSL 3.5 is a long-term release supported until April 8, 2030 according to the release announcement.
• Go. Since Go 1.24, X25519MLKEM768 is on by default in crypto/tls when CurvePreferences is nil. The Go 1.24 release notes also document the GODEBUG setting tlsmlkem=0 to turn it off.
• Java. JEP 527 adds the hybrid group to the JDK's TLS 1.3 implementation and places it first in the default client preference list. JEP 527 is marked as delivered in JDK 27.
• CDNs and servers. Cloudflare says it enabled post-quantum key agreement on its edge for basically all customers in October 2022, at first with the pre-standard Kyber variant rather than the final group. It reports that by the last week of October 2025 a majority of human traffic on its network used post-quantum encryption. Connections from Cloudflare back to customer origins are far lower, at 3.7% in 2025.

I could not confirm Windows SChannel status from a primary source, so check Microsoft's documentation for your build before relying on it.

What changes on the wire

The main cost is size, not computation. According to the RFC registry entry, the client key share is 1216 bytes (1184 for ML-KEM-768 plus 32 for X25519) and the server share is 1120 bytes. An X25519-only share is 32 bytes.

That pushes the ClientHello past a single typical TCP packet. Most software handles this, but some middleboxes, load balancers and older TLS stacks assume the ClientHello fits in one packet and drop or stall the connection. Cloudflare reports that its fast method for connections to origins broke about 0.05% of connections, too many to enable by default, so it uses a safer method for non-enterprise customers.

Symptoms of a broken path look like handshake timeouts that only affect clients offering the hybrid group. Go documents tlsmlkem=0 as a workaround for servers that mishandle large records. Treat it as a temporary fix and look for the device that cannot reassemble the ClientHello.

FIPS and compliance

ML-KEM itself is a NIST standard, so the algorithm is approved for use. Whether a given product is validated depends on its cryptographic module, not on the group name. A FIPS-validated build must include a validated ML-KEM implementation, and the hybrid construction with X25519 is a separate question for your compliance team. NIST's page for FIPS 203 also carries a note, dated November 17, 2025, that an issue will be corrected in a future revision, so watch for updates.

How to test your own setup

1. OpenSSL 3.5 or later: run openssl s_client -connect example.com:443 -groups X25519MLKEM768. If the handshake succeeds, the output shows the negotiated group.
2. Browser: open a site you control, check the Security tab in Chrome DevTools and look for the key exchange line. Names can differ slightly between versions.
3. Cloudflare Radar: the adoption and usage page shows global post-quantum adoption figures for Cloudflare traffic.
4. Your own logs: if your reverse proxy logs the negotiated group, filter for it to see how many clients already use it.

If you run an older OpenSSL, check which release you are on first. Our note on OpenSSL 3.4 reaching end of life explains which version to move to.

Related reading

SSH has its own version of this change. See the SSH post-quantum key exchange warning. Certificate lifetimes are shrinking at the same time, covered in the TLS certificate validity schedule. For more on this topic, browse our Security and Networks sections.

Frequently asked questions

What is the difference between X25519MLKEM768 and X25519?

X25519 is a classical key exchange that a large quantum computer could break. X25519MLKEM768 performs X25519 and ML-KEM-768 together, so the session key stays safe unless both are broken.

Does X25519MLKEM768 work with OpenSSL?

Yes, from OpenSSL 3.5.0 onward, which offers it by default alongside X25519. Older releases do not include ML-KEM unless built with an external provider.

Is X25519MLKEM768 FIPS approved?

ML-KEM is standardised in NIST FIPS 203, but approval of a product depends on its validated cryptographic module. Check the module certificate and your auditor's guidance for the hybrid group.

Can X25519MLKEM768 break my connections?

Occasionally. The larger ClientHello, over 1.2 KB for the key share alone, can fail through middleboxes or servers that cannot handle it. Cloudflare measured about 0.05% of connections failing with its fast origin method.

Is X25519MLKEM768 slower?

The extra cost is mostly bytes on the wire rather than CPU. I have no first-party benchmark to quote here, so measure on your own traffic.