Read this first
Switching TLS 1.3 to X25519MLKEM768 is the single highest-leverage post-quantum change most organizations can make. It concatenates a classical X25519 share with an ML-KEM-768 share, so a recorded handshake stays secure even against a future quantum computer, while peers that do not support it negotiate down to a classical group. Support is already broad, the code change is a config change, and the main operational cost is a slightly larger ClientHello. Enable it on public endpoints, keep the classical fallback, and monitor.
Hybrid key exchange is the first concrete step in almost every serious post-quantum plan, and for good reason: it defends against harvest-now-decrypt-later — the recording of encrypted traffic today for decryption once a quantum computer exists — without requiring you to touch certificates, identities, or the rest of your estate first. This guide walks through what actually changes when you move TLS 1.3 to the X25519MLKEM768 group, where support stands, what it costs, and how to roll it out safely.
What changes on the wire
In TLS 1.3 the client advertises which key-exchange groups it supports in the ClientHello's supported_groups extension and speculatively sends key material for its preferred groups in key_share. Hybrid adds one new named group, X25519MLKEM768, whose IANA TLS codepoint is 0x11EC (4588). When a client offers it, the key_share carries two concatenated shares: a classical X25519 public key and an ML-KEM-768 encapsulation key. The server, if it supports the group, responds with its own X25519 share plus an ML-KEM ciphertext; the two shared secrets are combined into the handshake secret. Break either component and the attacker still learns nothing — so the exchange is secure as long as at least one half holds.
The key property for rollout is backward compatibility. X25519MLKEM768 is just one more entry in supported_groups. A peer that does not recognize it simply selects a classical group both sides do support — X25519 or a NIST curve — and the handshake completes as it always did. There is no flag day and no hard cutover.
Where support already stands
As of 2025 the hybrid group is no longer experimental. It is available across a broad enough footprint to enable on production public endpoints:
- **Libraries:** OpenSSL 3.5+ ships X25519MLKEM768 as a built-in group; BoringSSL and AWS-LC support it (and drove much of the deployment).
- **Browsers:** Chrome and Firefox negotiate the hybrid group by default against servers that offer it.
- **Infrastructure:** Cloudflare and AWS support it at the edge and on load balancers, so a large share of the public web already handshakes post-quantum.
The cost and the risks
Hybrid is not free: the extra ML-KEM material makes handshakes bigger. An ML-KEM-768 encapsulation key is 1184 bytes and the ciphertext is 1088 bytes, so the client's key_share and the server's response each grow by roughly a kilobyte — on the order of ~1.1 KB added to the ClientHello. That is small in absolute terms but crosses two thresholds that matter.
The larger ClientHello can span multiple packets
A classical ClientHello usually fits in one packet; a hybrid one often does not, so it is split across TCP segments (or, over QUIC, constrained by the initial congestion window / initcwnd). Watch MTU, and be aware that a small population of middleboxes are intolerant of large or split ClientHellos and will drop or reset the connection. This is rare, but it is exactly why you must keep and actively TEST the classical fallback path rather than assuming it works.
The failure modes are almost entirely interoperability, not cryptography. Plan for them by treating the classical group as a first-class configuration you verify, not a leftover you tolerate.
Rolling it out
- Enable X25519MLKEM768 on the components that terminate TLS: servers, load balancers, and terminating/reverse proxies. Traffic past the termination point is unaffected.
- Prefer the hybrid group in the server's group ordering, but keep classical groups (X25519, P-256) configured so unknown clients still connect.
- Monitor handshake success rate and handshake latency before and after; a drop in success rate points at middlebox or MTU issues, not the cryptography.
- Roll out progressively — a canary fleet or a fraction of endpoints first — and sequence the wider effort against your migration roadmap.
How quantakrypto helps
The mechanics of enabling a group are the easy part; knowing which endpoints terminate TLS, which libraries they link, and which clients still need the classical path is the work. We build the cryptographic inventory that maps every TLS termination point and its key-exchange configuration, plan and execute the change through our migration practice sequenced by exposure, and verify the deployed handshakes — including fallback behavior — through certification so you can prove the rollout is both post-quantum and non-breaking.