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 non-FIPS 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 (announced)	Apple has stated intent for post-quantum TLS. No primary source is cited for this row, and neither source below mentions Apple or Safari; confirm the shipped default and version against Apple’s own release notes 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 should be read directly from Cloudflare Radar’s post-quantum page at citation time rather than quoting a number from any secondary write-up, which will lag.

As a dated anchor rather than a current value, Cloudflare’s own post-quantum roadmap post of 7 April 2026 stated that over 65% of human traffic to its network was using post-quantum encryption. Cite it with the date attached, or read the live figure instead.

The durable fact from that same post is the commitment rather than the percentage: Cloudflare set 2029 as its target to be fully post-quantum secure including post-quantum authentication, which is the harder half and the one most roadmaps leave until last. It named the reason explicitly, being Google’s improved algorithm against elliptic-curve cryptography together with Oratomic’s estimate that breaking P-256 on a neutral-atom machine takes only about 10,000 qubits, because neutral atoms need roughly 3 to 4 physical qubits per logical qubit against roughly a thousand for superconducting. Read the underlying results carefully before leaning on them: by Cloudflare’s own account Google published a zero-knowledge proof that it has the improved algorithm rather than the algorithm, and Oratomic “leave out crucial details on purpose.” A vendor moving its own deadline forward and naming the specific results that moved it is stronger evidence than a vendor timeline that only ever slips.

Source: Cloudflare, “Cloudflare targets 2029 for full post-quantum security,” April 7, 2026, blog.cloudflare.com.

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 non-FIPS 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.

What does independent measurement say about who is driving adoption?

Everything above records what each platform has enabled. Two questions stay open after reading a platform map: how far the provider effect reaches into ordinary organizations that configured nothing themselves, and whether the pattern holds outside the web. A national-scope scan published in August 2026 measured both. Researchers at Newcastle University probed 4,665 UK organizations across 10 sectors on June 30, 2026, testing port 443 for HTTPS and port 25 for SMTP STARTTLS against 4 post-quantum key-exchange groups, then attributed each reachable endpoint to the infrastructure provider actually serving it.

What was measured	HTTPS	SMTP STARTTLS
Reachable endpoints	4,063	3,858
Negotiated a post-quantum group	1,788 (44.0%)	246 (6.4%)
Provider-only prediction (AUC)	0.957	0.994
Sector-only prediction (AUC)	0.573	0.156
Share held by the top provider	Cloudflare, 69.7%	Google, 98.4%
Post-quantum certificate signatures	0	0

Source: K. Loizou and E. Ghadafi, “Measuring Post-Quantum TLS Deployment Across UK Internet Sectors,” School of Computing, Newcastle University, arXiv:2608.02147, submitted August 3, 2026, arxiv.org/abs/2608.02147. A preprint rather than peer-reviewed work; figures verified against the primary PDF on August 10, 2026.

Four readings come out of that table, and each is worth more than the headline percentage:

1. Which provider you sit behind predicts your posture; which industry you are in barely does. A model using only the infrastructure provider predicted HTTPS support at an AUC of 0.957, against 0.573 for a model using only the organization’s sector, and adding sector on top of provider moved the number to 0.962. AUC runs from 0 to 1 and 0.5 is what pure guesswork scores, so 0.573 is a hair above a coin flip. Sector was statistically associated with deployment and the effect size stayed modest, so raw sector rankings mostly reflect which providers each industry tends to buy from.
2. The email path runs far behind the web path on the same estates. Among the 3,510 organizations reachable over both protocols, 144 supported a post-quantum group on both services, 1,419 on the web only, 84 on mail only, and 1,863 on neither. Web support was 16.89 times more likely than mail support in the paired comparison.
3. Adoption is concentrated in very few hands. Cloudflare, Amazon AWS, and Fastly together accounted for 86.9% of post-quantum-supporting HTTPS endpoints. On the mail side, all 242 reachable Google-hosted endpoints supported a post-quantum group, which is 98.4% of every supporting SMTP endpoint found, while Microsoft’s 1,714 reachable mail endpoints supported none of the evaluated groups.
4. Certificates have not moved at all. All 7,921 leaf certificates collected across both protocols used classical signature algorithms, dominated by SHA-256 with RSA. Deployment so far lives entirely in key establishment. The Two-Lane Split explains why those two halves migrate on different clocks.

The email row of that AUC table is the sharpest number in the study, and it reads as a typo until you know what it means. Provider alone reached 0.994 while sector alone reached 0.156, which sits below the 0.5 that pure guesswork scores. A model performing that far under chance is running against the outcome it was asked to predict, so on the email lane, knowing an organization’s industry is worse than knowing nothing about it.

The reason is in how the email models were tested. Cross-validation was grouped by mail host, keeping organizations that share a mail provider inside the same fold, which closes the route by which a model quietly learns the provider through the industry label. The authors also report a 0.699 for email sector alone under ordinary splitting, and they decline to use it as their headline for exactly that reason: ordinary splitting lets shared mail infrastructure leak into the answer, so the 0.699 was reading the provider all along. The web pair makes the same point more gently, because web hosting spreads across more providers and leaks less.

Five boundaries belong with any restatement of those figures. The study covers UK organizations only, sampled by UK Standard Industrial Classification code. It is a single-day snapshot, so it sets a baseline and cannot show a trend. It reaches only publicly observable HTTPS and SMTP, leaving internal systems and every other protocol out. Provider attribution is an approximation the authors describe as identifying the major providers rather than guaranteeing every endpoint. And the commercial-sector samples are the first 500 eligible records from a company database rather than probability samples of UK industry.

The finding to carry forward is that externally visible post-quantum support is shaped mostly by provider configuration decisions, measured now at national scale and across 2 protocols. The authors are explicit that observable support is evidence of externally visible infrastructure capability rather than evidence of a completed migration. It matches what earlier longitudinal blog measurements and a concurrent Tranco-based study found, so the provider effect is replicated rather than isolated, and 2 studies fall short of establishing it as a universal rule. The Three-Way Map is the tool for separating what your provider covers from what remains yours to migrate.

Which industries were furthest ahead in the UK measurement?

Government led the web side and Technology led the email side, and the reading of both is that they describe hosting choices rather than industry effort. The study publishes a support count for every one of its 10 sectors on both protocols, plus the number of reachable web endpoints per sector, which makes a web percentage computable. It publishes no per-sector count of reachable mail endpoints, so a mail percentage cannot be worked out for any single industry and the mail column below stays as counts.

Sector	Web endpoints supporting PQC	Web endpoints reachable	Web rate	Mail endpoints supporting PQC
Government	255	455	56.0%	6
Retail	230	454	50.7%	57
Technology	212	437	48.5%	72
Telecommunications	186	407	45.7%	30
Legal	188	430	43.7%	21
Healthcare	187	445	42.0%	17
Finance & Insurance	177	425	41.6%	13
Utilities & Environmental Services	169	417	40.5%	13
Construction	145	445	32.6%	11
University	39	148	26.4%	6
All 10 sectors	1,788	4,063	44.0%	246

Source: K. Loizou and E. Ghadafi, “Measuring Post-Quantum TLS Deployment Across UK Internet Sectors,” School of Computing, Newcastle University, arXiv:2608.02147, submitted August 3, 2026, arxiv.org/abs/2608.02147. A preprint rather than peer-reviewed work. Support counts are the data labels on the study’s Figure 1 and reachable counts are the denominators in its Table 4, both verified against the primary PDF on August 10, 2026; the rate column is computed from those two. The columns check out against the study’s own totals: the web counts sum to 1,788 and the mail counts to 246, which are the figures it states in prose.

Four things to hold onto before quoting any row of that table:

1. A sector number reports a provider mix at the industry level. The sector-only models scored 0.573 on the web and 0.156 on mail, so knowing an organization’s industry tells you almost nothing about that organization. Government topping the web column describes which hosting the GOV.UK estate runs on, and Technology and Retail topping the mail column describes estates more likely to run mail through Google, which was the one provider carrying nearly all observable mail support.
2. The mail column has no percentage and one cannot be built. Dividing a sector’s mail count by its web denominator produces a number with no meaning, because the 2 protocols had different reachability. Only the all-sector mail rate of 6.4% (246 of 3,858) is real.
3. The University row rests on a much smaller base. It covers 148 reachable web endpoints against roughly 410 to 455 for every other sector, because the study enumerated all 165 eligible UK institutions instead of drawing 500 records. Its 26.4% is the least stable figure in the column.
4. The gap between best and worst is 29.6 percentage points on the web, and 0 on certificates. Every sector sat at 0 post-quantum certificate signatures, because the whole 7,921-certificate sample did. The Two-Lane Split is why the 2 halves look so different.

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 the live percentages in this note are intentionally not pinned as durable facts and should be read from the primary source at the moment of citation. 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 non-FIPS service endpoints including AWS KMS, ACM, and Secrets Manager negotiate hybrid ML-KEM TLS, which is the qualifier a federal or regulated reader on FIPS endpoints most needs. 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.

Is company email as far along as the website? No, and the gap is wide. A June 2026 scan of 4,665 UK organizations found 44.0% of reachable HTTPS endpoints negotiating a post-quantum key-exchange group against 6.4% of reachable SMTP STARTTLS services, and only 144 organizations supported one on both. Google-hosted mail accounted for 98.4% of the supporting mail endpoints observed, so mail-side coverage in that sample tracked a single provider almost entirely.

Does my industry predict how post-quantum-ready my organization is? Barely on the web, and worse than guessing on email. In that same study a provider-only model predicted HTTPS support at an AUC of 0.957 against 0.573 for sector alone, and adding sector to the provider model produced only marginal improvement. On mail, once organizations sharing a mail host were held together during testing, provider alone reached 0.994 while sector alone fell to 0.156, below the 0.5 that pure guesswork scores. Sector rankings in this kind of data largely reflect provider preference within each industry.

What percentage of my industry supports post-quantum key exchange? For the web, the UK measurement gives a figure for each of its 10 sectors, ranging from 26.4% for universities to 56.0% for government, and the per-sector table above carries all of them. For email, no per-industry percentage exists in that data, because the study published support counts per sector without publishing how many mail endpoints per sector were reachable. Only the all-sector email figure of 6.4% is a real rate.

My sector scored well. Does that mean my organization is fine? It means the industry average was pulled up by whichever hosting providers that industry tends to buy. Two organizations in the same sector on different providers land at opposite ends of the range, which is what an AUC of 0.573 for sector-only prediction is telling you. The number that describes your estate is the group your own endpoints negotiate on your own traffic.

Have post-quantum certificates started showing up in the wild? Not in public measurement so far. All 7,921 leaf certificates collected across HTTPS and SMTP in the June 2026 UK scan used classical signature algorithms, mostly SHA-256 with RSA. Public deployment sits entirely in key establishment, and certificate authentication stays classical until the certificate authorities and trust stores move. PQC in the Web PKI (CA-Browser Forum) covers that side.

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.

Go deeper

• The Three-Way Map: separates provider-covered crypto from what’s yours to migrate and from already-harvested traffic.

---

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 a working session with your team.

Last verified 2026-08-10 · Updated 2026-08-27 · Maintained by Addie LaMarr, LaMarr Labs.