up:: In the Protocols MOC

Cloud and Browser PQC Status

This note is a snapshot of where the platforms most of the internet runs on actually stand with post-quantum cryptography, meaning which cloud services and which browsers negotiate a hybrid post-quantum key exchange in production today. The short answer for 2026 is that hybrid post-quantum TLS key exchange, almost always the X25519MLKEM768 group, has moved from experiment to default across the browsers and the major CDNs, and it is spreading through cloud provider service endpoints. Two cautions frame the whole map. Live adoption percentages change month to month, so any figure below is a point-in-time reading rather than a fixed fact, and a platform “supporting” a group is a different claim from a given connection actually negotiating it, which you confirm on the wire.

Source: Cloudflare Radar, “Post-Quantum Encryption Adoption,” radar.cloudflare.com/post-quantum.

The short version:

• The dominant deployed mechanism is hybrid TLS key exchange with X25519MLKEM768, codepoint 0x11EC, pairing classical X25519 with ML-KEM-768. It carries the overwhelming majority of real post-quantum traffic.
• Browsers: Chrome and Edge ship X25519MLKEM768 on by default, having switched from the pre-standard Kyber draft group in Chrome 131 (November 2024). Firefox added mlkem768x25519 for HTTP/3, reaching release in Firefox 135 (February 2025).
• Cloudflare: it has enabled hybrid post-quantum key agreement by default across its network and reports the share of human HTTPS traffic protected by post-quantum encryption on Cloudflare Radar. That figure is fast-moving and must be read live.
• AWS: AWS-LC and s2n-tls carry the ML-KEM support, and service endpoints including AWS KMS, ACM, and Secrets Manager negotiate hybrid ML-KEM TLS, with AWS-LC being the first open-source module to include ML-KEM in a FIPS 140-3 validation.
• The universal caveat: a library or a browser shipping a group is not proof a connection used it. Verify the negotiated group on the wire, and for regulated systems track the validated-module date separately from the release date.

Think of a new safety standard for shipping containers rolling out across the world’s ports. The standard is published, the container makers have shipped conforming units, and now the question is coverage: which ports load the new containers by default, which still handle only the old design, and what fraction of cargo actually moves in the new units this quarter. That last number climbs every month, so a figure quoted in a report is already stale by the time you read it. Post-quantum TLS is at exactly that stage. The design is settled and the default is spreading, and the live adoption number is a moving reading you check against the source rather than a fact you memorize.

Which post-quantum mechanism is actually deployed?

Almost all real post-quantum traffic on the web today rides one mechanism: the hybrid TLS 1.3 key-exchange group X25519MLKEM768, codepoint 0x11EC (decimal 4588). It combines classical X25519 elliptic-curve Diffie-Hellman with ML-KEM-768, and it derives the session key from both, so the connection holds if either half survives. This is the same hybrid combiner covered in depth in TLS 1.3 Hybrid Key Exchange, and the platform map below is largely the story of who has turned that one group on.

The ecosystem passed through a pre-standard phase first. Chrome and Firefox shipped an earlier draft group, X25519Kyber768Draft00 (codepoint 0x6399), built on the pre-final Kyber, in 2023 and 2024. When NIST finalized ML-KEM in FIPS 203, the wire format changed enough that the draft group and the standardized group are incompatible and carry different codepoints, so the industry migrated to X25519MLKEM768 and retired the draft.

Source: Google Security Blog, “A new path for Kyber on the web,” September 13, 2024, security.googleblog.com.

The practical consequence is that when you read a modern packet capture or a platform’s PQC announcement, X25519MLKEM768 is the group to look for, and the presence of the old X25519Kyber768Draft00 is a sign of a stack that has not finished migrating to the standardized algorithm.

Where do the major browsers stand?

The browsers moved first and moved fast, and as of 2026 the two largest engines negotiate hybrid post-quantum key exchange by default against any server that offers it. The details differ by engine.

Browser	Post-quantum group	Status
Chrome / Edge (Chromium)	X25519MLKEM768	On by default; switched from the pre-standard X25519Kyber768Draft00 in Chrome 131, November 2024
Firefox	mlkem768x25519	Added for HTTP/3 in Firefox 135, February 2025
Safari	X25519MLKEM768 [OPERATOR VERIFY]	Apple has stated intent for post-quantum TLS; confirm the current shipped default and version live before citing

Source: Google Security Blog, “A new path for Kyber on the web,” September 13, 2024, security.googleblog.com; Mozilla, “Firefox 135.0 release notes,” February 4, 2025 (“Added support for a post-quantum key exchange mechanism (mlkem768x25519) for HTTP/3”), mozilla.org Firefox 135 release notes.

The important read is that browser support is now the common case rather than the exception, so for a large share of web connections the client half of the handshake is already post-quantum-capable, and whether a given connection is actually protected comes down to the server and the middleboxes in the path. That is the weakest-endpoint rule in action: a post-quantum-ready browser reaching a classical-only origin still falls back to classical key exchange, so the browser figures below are a ceiling on coverage rather than a measure of it.

Where does Cloudflare stand, and how do you read its numbers?

Cloudflare is the most useful public vantage point on real-world post-quantum adoption, because it sits in front of a large fraction of internet traffic and publishes live telemetry on Cloudflare Radar. It enabled hybrid post-quantum key agreement by default server-side for inbound connections years ago, and has been extending post-quantum key agreement to outbound connections to origin servers, which is what lets it report the share of human HTTPS traffic that is post-quantum-protected.

The number moves, and it moves quickly. Cloudflare reported the share of human-generated web traffic secured with post-quantum encryption reaching a majority through 2025 and climbing further into 2026. Because that figure is a live reading that rises month over month, this note deliberately does not pin a single percentage as a durable fact. The specific current value is [OPERATOR VERIFY]: read it directly from Cloudflare Radar’s post-quantum page at citation time rather than quoting a number from any secondary write-up, which will lag.

Source: Cloudflare Radar, “Post-Quantum Encryption Adoption,” radar.cloudflare.com/post-quantum; Cloudflare, “Defending against future threats: Cloudflare goes post-quantum,” blog.cloudflare.com.

The reason this matters for a migration is that Cloudflare’s default-on posture is a large part of why the browser numbers translate into actual protected traffic. When a post-quantum-capable Chrome reaches a site behind Cloudflare, both ends offer X25519MLKEM768 and the connection negotiates it, so the CDN layer is doing much of the work of closing the harvest-now-decrypt-later window for sites that never touched their own configuration.

Where does AWS stand?

AWS carries its post-quantum support in two open-source pieces that its services build on, and it has begun turning on hybrid ML-KEM TLS at the service-endpoint level. The foundation is AWS-LC, the cryptographic library, and s2n-tls, its TLS implementation, both of which support ML-KEM-based hybrid key exchange.

1. The library layer. AWS-LC contains ML-KEM (and the ML-DSA signature), and s2n-tls, a C implementation of TLS, supports post-quantum key exchange for TLS 1.3 by building on AWS-LC. AWS-LC was the first open-source cryptographic module to include ML-KEM in a FIPS 140-3 validation, which matters for any regulated deployment.
2. The service layer. AWS enabled ML-KEM hybrid TLS on the endpoints of AWS Key Management Service, AWS Certificate Manager, and AWS Secrets Manager, combining classical ECDH with ML-KEM, so traffic to those control-plane endpoints gets post-quantum key exchange. Other services, including S3 and CloudFront, have deployed post-quantum hybrid key establishment as well.

Source: AWS, “Post-Quantum Cryptography,” aws.amazon.com/security/post-quantum-cryptography; AWS Security Blog, “AWS-LC FIPS 3.0: first cryptographic library to include ML-KEM in FIPS 140-3 validation,” aws.amazon.com.

The pattern to hold is that a cloud provider’s post-quantum status has two layers, and they migrate on different clocks. The library layer ships the algorithm, and the service layer decides which endpoints actually negotiate it, so “AWS supports ML-KEM” is true at the library layer well before every service endpoint offers it. Which specific endpoints your architecture touches, and whether each negotiates the hybrid group, is the real question for a migration, and it is a per-service check rather than a single provider-wide yes.

Why does a live adoption figure need a verify caveat?

Because these numbers are moving targets by design, and a figure that was accurate when a report was written is stale by the time it is read. Post-quantum adoption is climbing steeply as defaults flip on across browsers and CDNs, so the percentage of traffic protected this month is higher than last month, and a note that hard-codes a single value would be wrong within weeks.

1. Adoption keeps rising. Every browser that turns the group on by default and every CDN that enables it server-side moves the number up, so the trajectory is steep and continuous rather than settled.
2. Secondary sources lag. A blog post, a vendor slide, or a news article quotes a figure from the moment it was written. The primary telemetry (Cloudflare Radar) updates continuously, so citing the source directly is the only way to get a current number.
3. The figure depends on what is measured. “Human HTTPS traffic,” “all requests,” and “traffic to a specific platform” are different denominators that yield different percentages, so a number without its exact scope is easy to misquote.

Source: Cloudflare Radar, “Post-Quantum Encryption Adoption,” radar.cloudflare.com/post-quantum.

This is why every live percentage in this note is flagged [OPERATOR VERIFY]. The durable facts (which group is deployed, which browsers and services ship it, which library holds the validated module) belong in the guide, and the specific current adoption number belongs to a live check against the primary source at the moment of citation.

How do you verify a platform’s real posture?

You verify it the same way you verify any applied-PQC claim: on the wire and in the configuration, because a platform’s marketing status and a given connection’s actual cryptography are two different things. Three concrete checks separate “supported” from “in use.”

1. Confirm the negotiated group. A packet capture or a TLS client that reports the selected group shows whether a connection actually used X25519MLKEM768 or fell back to a classical curve. Offering the group and negotiating it are separate events, and only the negotiated group is proof.
2. Read the current source for live figures. For any adoption percentage, read Cloudflare Radar’s post-quantum page directly rather than quoting a secondary write-up, so the number reflects today rather than the date some article was published.
3. Separate the release date from the validated-module date. For a regulated deployment, a service or library shipping ML-KEM is not the same as its FIPS 140-3 module being validated for it, so track the CMVP-validated date as the compliance gate, the same CAVP-versus-CMVP distinction that governs every PQC library.

Source: Cloudflare Radar, “Post-Quantum Encryption Adoption,” radar.cloudflare.com/post-quantum.

The takeaway is that a platform PQC status map is a starting point for a migration and never the finish line. It tells you where to expect the group to be available; the negotiated group on your own traffic, read against a live source, tells you where it is actually protecting you.

Common misconceptions

• “My browser supports post-quantum, so my connections are protected.” Browser support is the client half. A connection negotiates the hybrid group only when the server and every middlebox in the path also support it, so a post-quantum-ready browser reaching a classical-only origin still falls back to classical key exchange.
• “Cloudflare says X% of traffic is post-quantum, so that’s the number.” That figure is a live reading that rises month over month, and it depends on exactly which traffic is measured. Read it from Cloudflare Radar at the moment you cite it rather than quoting a value from a secondary source, which lags.
• “AWS supports ML-KEM, so every AWS endpoint uses it.” The library layer ships ML-KEM ahead of every service endpoint offering it. Which specific endpoints your architecture touches, and whether each negotiates the hybrid group, is a per-service check.
• “X25519Kyber768Draft00 and X25519MLKEM768 are interchangeable.” They are the pre-standard and standardized groups, built on pre-final Kyber and finalized ML-KEM, and they carry different codepoints and incompatible wire formats. Only the standardized X25519MLKEM768 should be deployed now.
• “A library shipping ML-KEM means a regulated system can use it.” A FIPS 140-3-bound deployment needs a CMVP-validated module, and an algorithm present in source code is a separate event from the module carrying it being validated. Track the validated-module date as the compliance gate.

Questions people ask

Does Chrome support post-quantum cryptography? Yes. Chrome and Edge ship X25519MLKEM768 on by default, having switched from the pre-standard X25519Kyber768Draft00 group in Chrome 131 in November 2024, so a modern Chrome negotiates hybrid post-quantum key exchange against any server that offers it.

Does Firefox support post-quantum cryptography? Yes. Firefox added the mlkem768x25519 post-quantum key exchange for HTTP/3, reaching release in Firefox 135 in February 2025. Confirm the current status for TLS over TCP and later versions live, since browser coverage keeps expanding.

Does AWS support post-quantum TLS? Yes, at two layers. AWS-LC and s2n-tls carry ML-KEM hybrid key exchange, and service endpoints including AWS KMS, ACM, and Secrets Manager negotiate hybrid ML-KEM TLS. AWS-LC was the first open-source module to include ML-KEM in a FIPS 140-3 validation.

What percentage of internet traffic is post-quantum-protected? A majority of human HTTPS traffic on Cloudflare’s network as of 2025, climbing through 2026. That figure moves continuously, so read the current value directly from Cloudflare Radar’s post-quantum page rather than quoting a fixed number, which will be stale.

Which post-quantum group should I look for on the wire? X25519MLKEM768, codepoint 0x11EC (decimal 4588). It is the standardized hybrid group carrying nearly all real post-quantum web traffic. Seeing the older X25519Kyber768Draft00 instead means a stack that has not finished migrating to the finalized algorithm.

Is “the platform supports it” the same as “my connection uses it”? No. Support means the option is available; use means a specific connection negotiated it. Confirm the negotiated group on your own traffic with a packet capture or a group-reporting client, because a connection can silently fall back to classical key exchange and still succeed.

Why won’t this note give me one adoption number to cite? Because adoption is rising steeply and the figure depends on what is measured, so any single value is a point-in-time reading rather than a durable fact. The live number lives at the primary source, Cloudflare Radar, and belongs to a verify-at-citation check.

---

Everything here is the map, given freely. When your team needs its own cloud endpoints, CDN edges, and client fleet assessed for which connections actually negotiate a post-quantum handshake and which quietly fall back, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.