Read this first
Chrome and Chromium-based browsers have negotiated the X25519MLKEM768 hybrid post-quantum key agreement by default since version 131, released 6 November 2024. Chrome first shipped a pre-standard hybrid (X25519Kyber768Draft00) on by default in version 124 (April 2024), then migrated to the standardized ML-KEM version once FIPS 203 was final. The construction is deliberately hybrid: it runs classical X25519 and post-quantum ML-KEM-768 together, so the session stays secure as long as either holds.
The most consequential change to how the web encrypts traffic in a decade shipped with almost no announcement most users would notice: a browser point release. When Chrome 131 went out in November 2024, hybrid post-quantum key agreement became the default for the largest browser on the internet, and the majority of TLS handshakes quietly started carrying a lattice-based key exchange. No setting, no prompt, no migration for the user.
Draft to standard, in two releases
The path is worth remembering because it is a model for how these transitions actually land. Chrome enabled a hybrid by default first in version 124 (April 2024), but that build used X25519Kyber768Draft00, based on a pre-standard draft of Kyber, the algorithm before NIST finalized it as ML-KEM in FIPS 203. Once the standard was final, Chrome moved the default to X25519MLKEM768 in version 131. The lesson is the one we keep finding in audits: a pre-standard Kyber and the final ML-KEM are close relatives but not the same thing, and they do not interoperate, so shipping the draft was a bridge, not the destination.
It did not stay a Chrome story. The standardized X25519MLKEM768 is now enabled by default across the other major browsers and in widely used libraries and platforms, including OpenSSL, Go, and recent Apple operating systems. That breadth is what turns a browser default into an internet default.
What the hybrid protects, and what it does not
Two things are easy to over-read. First, hybrid is a choice, not a hedge born of doubt: X25519MLKEM768 combines the classical and the post-quantum exchange so an attacker would have to break both, which protects against a flaw in the new algorithm and against the quantum threat at once. Second, and more important, this migrates key exchange only. It defends the confidentiality of the session against harvest-now-decrypt-later. It does nothing for authentication, the certificate signatures that are still classical RSA and ECDSA almost everywhere, and it only covers the hop the browser actually makes. What happens past the edge is a separate migration.
The point
The point
The browser key-exchange migration is a quiet success story: a default changed, and post-quantum key agreement became the norm without asking users to do anything. But it is one layer, key exchange, on one hop, browser-to-edge. Reading it as the migration being over is the mistake it invites.
The useful takeaway is the shape of a good transition: standardize, ship the standard as a hybrid default, and let the ecosystem follow. The layers still waiting for that treatment are authentication and everything behind the edge. For the wider state of adoption, and where the 4% of origins that keep up sit, the numbers tell the rest of the story.
References
- Google Online Security Blog: a new path for Kyber on the web (security.googleblog.com) - Chrome's move to standardized ML-KEM.
- Cloudflare: State of the post-quantum Internet in 2025 (blog.cloudflare.com) - default status across browsers and libraries.
- NIST FIPS 203, ML-KEM (csrc.nist.gov) - the finalized standard behind X25519MLKEM768.