Two of the internet’s biggest infrastructure providers have taken opposite approaches to the same problem. A sufficiently powerful quantum computer could one day break the math behind today’s encrypted connections, and both Cloudflare and AWS have spent the past two years shipping real, production post-quantum encryption to stop that from mattering. The question for engineers planning 2026 and 2027 roadmaps is which approach actually protects traffic today, which one costs more, and which one fits a given stack.
This comparison pulls from Cloudflare’s own published rollout data, AWS’s security blog and documentation, an independent academic measurement of internet-wide adoption, and reporting on Cloudflare’s daily connection volume. It covers specs, benchmarks, pricing, real deployments, a migration path, and a verdict based on the numbers rather than marketing copy.
Neither company is working from a blank slate. Both built their post-quantum programs on the same three algorithms that NIST spent close to a decade vetting, and both had to decide how aggressively to push those algorithms into live traffic before the rest of the internet caught up. That decision, more than any single benchmark number, explains why the two rollouts look so different today.
Why Post-Quantum Encryption Became Urgent in 2026
In August 2024, the National Institute of Standards and Technology finalized its first three post-quantum cryptography standards: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a backup signature scheme. That gave cloud and CDN providers a stable target to build against, after nearly a decade of draft algorithms and competing candidates.
The urgency comes from a specific attack pattern security teams call harvest now, decrypt later. An adversary records encrypted traffic today and simply waits for a quantum computer capable of breaking classical key exchange like RSA or elliptic-curve Diffie-Hellman. Data that needs to stay confidential for years, think medical records, government communications, or long-lived credentials, is already exposed to that future risk even though no quantum computer can break it yet. That is the reason providers are rolling out hybrid key exchange now instead of waiting for the threat to materialize.
Cloudflare and AWS both frame their work around hybrid key exchange, meaning a classical algorithm and a post-quantum algorithm run side by side, so a connection stays safe even if one of the two is later broken. Where they differ is in how fast, how broadly, and how automatically that hybrid exchange has actually reached production traffic.
There is also a quieter driver behind the timing: government procurement rules. US federal agencies and their contractors face migration deadlines tied to the NSA’s Commercial National Security Algorithm Suite 2.0, and similar guidance is spreading through financial regulators outside the US. A cloud or CDN vendor that cannot show a working post-quantum story risks losing contracts it would otherwise win on price and performance alone, which is part of why both Cloudflare and AWS have been so vocal about publishing rollout dates rather than treating this as internal plumbing.
The NIST Standards Both Companies Are Building On
Every rollout discussed in this comparison traces back to the same three documents. FIPS 203 defines ML-KEM, the key-encapsulation mechanism both Cloudflare and AWS use for hybrid key exchange. FIPS 204 defines ML-DSA, the primary post-quantum signature algorithm. FIPS 205 defines SLH-DSA, a stateless hash-based signature scheme kept as a structurally different backup in case a future weakness is found in the lattice math underneath ML-KEM and ML-DSA. NIST published all three as final standards in August 2024, closing out a selection process that started with dozens of candidate algorithms in 2016 and narrowed over multiple elimination rounds.
Key exchange and signatures are migrating on separate clocks, which is a detail easy to miss in vendor announcements. ML-KEM protects the session key for a connection as it is being established, which is the piece Cloudflare and AWS have both prioritized because it directly defeats harvest now, decrypt later. ML-DSA and SLH-DSA protect certificates and signed data instead, and that transition is moving more slowly across the industry because certificate authorities, browsers, and hardware security modules all need to agree on new certificate formats before broad trust can roll out. That is exactly why Cloudflare’s own roadmap separates “key exchange is live now” from “certificates are still years away” rather than bundling the two under one release date.
Cloudflare’s Six-Year Path to General Availability
Cloudflare has published on post-quantum cryptography since 2017, and the company has treated the transition as a default-on infrastructure change rather than an opt-in feature. Cloudflare said in its general-availability announcement, “Today, we have hit a milestone after six years and 31 blog posts in the making: we’re starting to roll out General Availability of post-quantum cryptography support to our customers, services, and internal systems.”
The core mechanism Cloudflare rolled out is a hybrid group combining the classical X25519 elliptic-curve exchange with ML-KEM-768, written as X25519MLKEM768. Cloudflare described the rollout plainly: “We are happy to announce that we are rolling out support for X25519+Kyber for most inbound and outbound connections as Generally Available.” Kyber was the pre-standardization name for what became ML-KEM once NIST finalized FIPS 203, and Cloudflare migrated its production deployment from Kyber to the standardized ML-KEM as the spec matured.
Adoption climbed fast once the hybrid group was live. Cloudflare reported that more than a third of human-generated HTTPS traffic was using post-quantum key agreement by March 2025, and that figure rose to roughly 43% of human-generated connections by September 2025. By late September 2026, Cloudflare’s own dashboard tooling showed close to 70% of browser-generated traffic hitting its network on the visitor-to-Cloudflare leg already negotiating post-quantum key exchange, a number pulled directly from Cloudflare’s PQC product status page.
That growth curve matters more than any single snapshot. A jump from roughly a third of traffic to roughly 43% in six months, followed by a climb toward 70% over the following year, shows the hybrid group moving from early-adopter territory into the default path for most modern browsers hitting Cloudflare’s network. Because Cloudflare terminates TLS for such a large share of the public web, that curve functions as a rough proxy for how fast the broader internet is actually moving toward post-quantum defaults, not just how fast one company’s engineering team is shipping.
How Cloudflare’s Hybrid ML-KEM Actually Works
Cloudflare’s post-quantum key agreement only applies to protocols built on TLS 1.3, which includes HTTP/3. TLS 1.2 connections are not covered by this mechanism, so legacy clients still negotiate classical key exchange regardless of server-side readiness. That scoping decision kept the rollout simple but means full coverage depends on the slow decline of TLS 1.2 traffic across the wider internet.
A visitor can check which key-exchange group a connection actually used with a single OpenSSL command against a PQC-enabled origin:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3 2>/dev/null | grep -i "server temp key"In November 2025, Cloudflare extended the rollout to origin servers with a feature called Automatic Key Exchange, which detects when an origin supports hybrid post-quantum negotiation and prioritizes it, falling back to classical algorithms only when necessary. The operational payoff was immediate: connections that previously required a costly TLS HelloRetryRequest fell from roughly 52% to 3.7% after the automatic selection logic shipped, according to reporting from SDxCentral. That single fix reportedly cut 90th-percentile handshake latency by more than 150 milliseconds and pushed the share of post-quantum TLS 1.3 connections completing in a single network round trip up to 99.2%, with the feature now protecting around 45 billion connections per day.
By early 2026, Cloudflare had pushed the hybrid ML-KEM exchange beyond the CDN edge into Cloudflare One, its Zero Trust and SASE platform, covering every major on-ramp and off-ramp, plus Cloudflare IPsec with confirmed interoperability against Cisco and Fortinet hardware. Cloudflare’s stated roadmap target is full post-quantum security across its entire product suite by 2029, and the company has said the first post-quantum TLS certificates are expected sometime in 2026, though broad browser trust for those certificates likely will not arrive before 2027.
Worth noting: none of this required customers to open a support ticket or flip a dashboard toggle. Cloudflare’s architecture terminates TLS on behalf of the customer’s domain, so a change at the edge propagates to every site on the network simultaneously once Cloudflare decides it is safe to ship. That centralization is precisely what makes a six-year, incrementally-staged rollout possible without breaking compatibility for the millions of sites sitting behind it, and it is also why Cloudflare’s adoption numbers look so different from a platform like AWS, where each customer owns their own TLS termination point.
AWS Takes a Service-by-Service Approach
AWS’s rollout looks nothing like Cloudflare’s network-wide default. Instead, AWS has shipped hybrid post-quantum support service by service, starting with the identity and secrets layer rather than the network edge. On April 7, 2025, AWS announced that Key Management Service, Certificate Manager, and Secrets Manager endpoints would support ML-KEM for hybrid post-quantum key agreement on non-FIPS endpoints across every AWS Region in the standard aws partition.
That announcement also set a retirement date for the pre-standard algorithm: AWS kept CRYSTALS-Kyber support running alongside ML-KEM through 2025 before removing Kyber from its service endpoints in 2026, giving customers a full year to move clients over without a hard cutover. For Secrets Manager specifically, AWS says hybrid post-quantum negotiation is automatically preferred once a customer upgrades to Workload Credentials Provider version 2.0.0 or later, the Secrets Manager Lambda extension version 19 or later, or the Secrets Manager CSI Driver version 2.0.0 or later.
AWS extended the same Kyber-to-ML-KEM migration to AWS Transfer Family on September 5, 2025, giving managed file-transfer customers two new SSH security policies, TransferSecurityPolicy-2025-03 and TransferSecurityPolicy-FIPS-2025-03, both built on the standardized FIPS 203 algorithm. Underneath all of this sits AWS-LC, AWS’s own open-source cryptographic library, which already implements ML-KEM, ML-DSA, and SLH-DSA, and s2n-tls, the TLS implementation AWS says has supported post-quantum key exchange experimentally since 2020, years before NIST finalized the standards it now implements.
Unlike Cloudflare’s default-on edge rollout, most AWS services require a client capable of negotiating the hybrid group, meaning the protection only activates when a customer’s own SDK, application, or library has been updated. AWS has publicly tied this migration effort to a specific external deadline, stating on its migration guidance page that “AWS is migrating to PQC and helping our customers do the same ahead of timelines specified by regulations like CNSA 2.0,” the NSA’s Commercial National Security Algorithm Suite that sets hard migration dates for US national security systems.
That customer-owns-the-endpoint model is the real reason AWS cannot publish a single adoption percentage the way Cloudflare does. KMS, ACM, and Secrets Manager each sit behind a customer’s own application code, so AWS controls the server side of the handshake but not the client side. A customer running an old AWS SDK simply never attempts the hybrid exchange, and AWS has no mechanism to force an upgrade the way Cloudflare can push a change across its entire edge fleet overnight. AWS’s public messaging reflects that reality: rather than claiming a percentage, the company focuses on documenting exactly which SDK, extension, and policy versions unlock the protection, leaving the actual adoption timeline in each customer’s hands.
Cloudflare vs AWS: Post-Quantum Encryption Specs Compared
Laid side by side, the two providers’ approaches diverge on almost every axis except the underlying algorithm.
| Dimension | Cloudflare | AWS |
|---|---|---|
| Primary key-exchange algorithm | ML-KEM-768 (hybrid X25519MLKEM768) | ML-KEM (hybrid with ECDH) |
| NIST standard | FIPS 203 | FIPS 203 |
| First GA milestone | Six-year rollout, GA announced progressively from 2023 | April 7, 2025 (KMS, ACM, Secrets Manager) |
| Protocol scope | TLS 1.3 and HTTP/3 only | TLS 1.2 and 1.3, service-dependent |
| Default vs opt-in | Default for compatible edge and origin connections | Opt-in, requires updated client or SDK version |
| Legacy algorithm phase-out | Migrated from Kyber to ML-KEM ahead of standardization | Kyber supported through 2025, removed in 2026 |
| Measured adoption (edge/network) | ~70% of browser traffic by late September 2026 | Not publicly disclosed as a percentage |
| Enterprise/SASE coverage | Cloudflare One, IPsec with Cisco and Fortinet interop | Transfer Family, NLB/ALB TLS listeners |
| Open-source crypto library | Not publicly named as separate from edge stack | AWS-LC (FIPS 140-3 validated) |
| Signature algorithm readiness | Certificates targeted for 2026, broad trust unlikely before 2027 | ML-DSA/SLH-DSA implemented in AWS-LC, rollout ongoing |
| Stated full-rollout target | 2029 across entire product suite | No single company-wide date published |
| Extra charge for enabling PQC | None, confirmed free across supported products | None documented in current pricing pages |
Benchmark Data: Handshake Overhead and Latency, Three Sources Compared
Raw cryptographic overhead for ML-KEM-768 is well understood: it adds roughly 1.1 kilobytes of data from server to client and about 1.2 kilobytes from client to server compared with a classical-only exchange, and Cloudflare’s own operational measurement put the resulting TLS handshake slowdown at approximately 4% once the hybrid group was deployed at scale.
That 4% figure, though, gets overshadowed by a configuration problem Cloudflare only fixed in late 2025. Before Automatic Key Exchange shipped, more than half of origin connections, around 52%, were triggering an extra TLS HelloRetryRequest round trip because clients and servers could not agree on a key-exchange group on the first try. After the fix, that rate dropped to 3.7%, and the resulting drop in p90 handshake latency, over 150 milliseconds, dwarfs the intrinsic ~4% cryptographic cost of ML-KEM itself. SDxCentral’s reporting on the change makes clear this was a deployment-behavior fix, not a change to the underlying math.
The third data point comes from outside either company. An independent academic measurement, published as a 2026 paper on arXiv, tracked hybrid post-quantum key-exchange adoption across the broader internet rather than any single vendor’s network. It found 31.26% of measured domains negotiated a hybrid post-quantum group by default in July 2025, rising to 47.37% by November 2025 and 49.22% by March 2026. The same paper attributed nearly 70% of all observed post-quantum TLS adoption on the internet to two providers combined: Cloudflare and Fastly. AWS does not appear as a comparable share of that measurement, which fits its service-by-service rather than network-wide rollout strategy.
Put the three sources together and a clear picture forms. ML-KEM’s raw overhead is small and manageable at roughly 4% on the handshake and a couple of kilobytes of bandwidth. The bigger latency wins come from deployment engineering, not the algorithm. And measured against the rest of the internet, Cloudflare’s network effect is doing most of the heavy lifting on global adoption numbers right now.
It is worth separating two kinds of overhead that often get lumped together in casual benchmark talk: computational overhead and network overhead. ML-KEM-768’s computational cost, the actual CPU cycles spent generating and decapsulating the key, is small enough on modern hardware that it rarely shows up as a bottleneck on its own. The bytes-on-the-wire cost is the bigger practical concern, especially for clients on constrained mobile connections or satellite links, since every additional kilobyte in the handshake adds real transmission time on a slow link even if the server processes it instantly. That is the overhead Cloudflare’s 1.1 to 1.2 kilobyte figures describe, and it is also why the HelloRetryRequest fix mattered so much: an unnecessary extra round trip costs far more on a slow connection than the extra bytes ever would.
Pricing: What Post-Quantum Protection Costs on Each Platform
Neither company charges extra for the cryptography itself, but the two pricing models reach that outcome differently.
| Product or Service | Provider | PQC Surcharge | Notes |
|---|---|---|---|
| Free/Pro/Business/Enterprise plans | Cloudflare | None | Cloudflare said PQC “will be included for free in all Cloudflare products and services that can support it” |
| Cloudflare One (SASE/Zero Trust) | Cloudflare | None | Hybrid ML-KEM across all on-ramps and off-ramps included |
| Cloudflare IPsec | Cloudflare | None | GA with Cisco and Fortinet interoperability confirmed |
| Key Management Service | AWS | None documented | Standard KMS usage pricing applies regardless of key-exchange group |
| Certificate Manager | AWS | None documented | Public certificates remain free of charge |
| Secrets Manager | AWS | None documented | Requires updated client libraries (v19+ Lambda extension, v2.0.0+ CSI driver) |
| Transfer Family | AWS | None documented | Requires selecting the new 2025-03 security policy |
The practical difference is not price, it is effort. Cloudflare’s model bundles the upgrade into existing plans with no action required for most customers. AWS’s model keeps the base service price flat but shifts the work of enabling protection onto the customer, who has to update SDKs, Lambda extensions, or security policies before the hybrid exchange actually activates.
That effort difference has a real dollar value even without a line-item surcharge. Updating Lambda extensions and CSI drivers across a large fleet of services takes engineering time, testing cycles, and a change-management process that a lot of teams underestimate until they actually schedule it. Cloudflare’s customers pay for that work implicitly through the subscription they already hold, since Cloudflare’s own engineers absorbed the equivalent effort once, centrally, instead of every customer repeating it independently.
Real-World Deployments: Who’s Already Running This
This is not theoretical infrastructure. Several concrete deployments are already running hybrid post-quantum encryption in production.
- Cloudflare’s global edge: Automatic Key Exchange now protects roughly 45 billion connections per day between Cloudflare and origin servers, per SDxCentral’s reporting on the rollout.
- Enterprise WAN traffic through Cloudflare One: Organizations tunneling corporate network traffic through Cloudflare’s Zero Trust platform get quantum-resistant protection without touching their own infrastructure, a capability Cloudflare describes directly: organizations “can now protect their sensitive corporate network traffic against quantum threats by tunneling it through Cloudflare’s Zero Trust platform.”
- Cloudflare IPsec customers running Cisco and Fortinet hardware: Confirmed interoperability testing means branch-office and WAN-as-a-service traffic can negotiate hybrid ML-KEM without replacing existing network appliances.
- AWS Secrets Manager users on updated SDKs: Any customer running Workload Credentials Provider 2.0.0+, Lambda extension v19+, or CSI Driver 2.0.0+ gets hybrid post-quantum TLS automatically preferred for credential retrieval.
- Managed file-transfer operations on AWS Transfer Family: Customers who switch to the TransferSecurityPolicy-2025-03 or FIPS variant get ML-KEM-protected SFTP and SSH sessions for partner and vendor file exchanges.
- Financial institutions under regulatory pressure: AWS’s public-sector and industry blogs point to banks operating under Hong Kong’s HKMA DART framework building on AWS-LC and s2n-tls specifically because both already implement the NIST-standardized algorithms.
What stands out across these six examples is how little overlap there is between them. Cloudflare’s deployments cluster around infrastructure the company fully controls, the edge, the SASE platform, the IPsec gateway. AWS’s deployments cluster around services that sit closer to application code, secrets, file transfers, identity. Neither list looks like a direct substitute for the other, which is the strongest practical argument for why most organizations end up using pieces of both rather than picking a single winner.
Where Google Cloud, Azure, and the Browsers Stand
Cloudflare and AWS are not operating in isolation. Recent versions of every major browser now support the X25519MLKEM768 hybrid group by default, along with widely used TLS libraries and platforms including OpenSSL, Go’s standard library, and recent Apple operating system releases, according to Cloudflare’s own State of the Post-Quantum Internet research. That client-side readiness is exactly why server-side rollouts like Cloudflare’s and AWS’s can show up as real adoption numbers rather than sitting unused.
Fastly is the other major piece of the puzzle. The arXiv measurement cited earlier found Cloudflare and Fastly together account for close to 70% of all observed post-quantum TLS adoption on the internet, which says as much about CDN market concentration as it does about either company’s specific engineering choices. Google Cloud and Microsoft Azure both participate in the broader NIST-standard ecosystem through their own TLS stacks and certificate services, though neither has published rollout percentages or latency figures comparable to what Cloudflare has disclosed, making a direct apples-to-apples comparison against those two providers difficult to responsibly report right now.
That gap in published data is itself useful context for anyone evaluating vendors. A provider that discloses adoption percentages, latency deltas, and specific fixes like the HelloRetryRequest change is giving customers something concrete to audit. A provider that only states a capability exists, without a measured rollout number, is asking for more trust up front. Neither posture is wrong on its own, but it does mean a security team comparing vendors on post-quantum readiness needs to ask for the underlying numbers rather than accepting a feature checkbox at face value.
Migrating Your Infrastructure to Post-Quantum TLS: A Step-by-Step Guide
Whether a stack sits behind Cloudflare, runs on AWS, or spans both, the migration path follows roughly the same sequence.
- Inventory every TLS termination point, load balancer, and API gateway currently in production, and note which protocol version (1.2 or 1.3) each one negotiates.
- Check client-side readiness: confirm application dependencies use OpenSSL 3.2 or newer, Go 1.23 or newer, or an equivalent TLS library with ML-KEM support.
- If running behind Cloudflare, check the PQC status dashboard for each zone and confirm Automatic Key Exchange is active for origin connections.
- If running on AWS, update to Secrets Manager Lambda extension v19+, Workload Credentials Provider 2.0.0+, or CSI Driver 2.0.0+ to get hybrid key exchange preferred automatically.
- For AWS Transfer Family workloads, switch endpoints to the TransferSecurityPolicy-2025-03 or FIPS-2025-03 policy.
- Test the new configuration in staging and capture handshake latency before and after, watching specifically for HelloRetryRequest rates, since that is where most real-world latency problems hide.
- Roll out gradually and monitor connection success rates, not just latency, since older clients without ML-KEM support still need a working classical fallback.
- Separately plan for the signature-algorithm transition to ML-DSA or SLH-DSA, since key exchange and signatures migrate on different timelines.
- If operating under a compliance mandate such as CNSA 2.0, align internal migration deadlines with the specific dates that regulation sets rather than general industry momentum.
- Re-audit annually, since both NIST guidance and vendor support continue to shift as additional algorithms and parameter sets mature.
Teams running AWS workloads can sanity-check whether a given endpoint is advertising the hybrid group with the same OpenSSL approach used earlier, just pointed at an AWS-fronted hostname instead of a Cloudflare one:
openssl s_client -connect secretsmanager.us-east-1.amazonaws.com:443 -groups X25519MLKEM768 2>&1 | grep -i "negotiated\|server temp key"Cloudflare: Pros and Cons
Cloudflare’s biggest strength is that most customers do not have to do anything. Protection activates at the network layer, coverage already reaches roughly 70% of browser traffic, and the HelloRetryRequest fix shows the company is actively tuning performance rather than just flipping a switch and walking away. The tradeoff is that Cloudflare’s customers inherit the company’s scoping decisions, including the TLS 1.3 limitation, whether they would have made the same call or not.
- Pro: Default-on protection with no customer action required for most zones.
- Pro: Confirmed free across every plan tier, from Free to Enterprise.
- Pro: Extends past the CDN edge into Zero Trust, SASE, and IPsec with real third-party hardware interop.
- Con: Limited to TLS 1.3 and HTTP/3, so TLS 1.2 traffic gets no benefit.
- Con: Broad browser trust for post-quantum certificates is not expected before 2027.
AWS: Pros and Cons
AWS’s strength is depth rather than breadth. The service-by-service rollout gives customers granular control and ties directly into compliance frameworks that enterprise security teams already have to track, with AWS-LC’s FIPS 140-3 validation mattering a great deal to regulated industries. The tradeoff is that depth comes at the cost of reach, since none of that careful, dated engineering helps a connection that never gets a chance to negotiate it in the first place.
- Pro: FIPS 140-3 validated cryptographic library (AWS-LC) suitable for regulated workloads.
- Pro: Clear, dated migration path with a hard Kyber-to-ML-KEM cutover already scheduled for 2026.
- Pro: Explicit alignment with CNSA 2.0 compliance timelines for government and defense customers.
- Con: Opt-in by design, meaning unmigrated clients get no protection at all.
- Con: No published company-wide adoption percentage comparable to Cloudflare’s dashboard figures.
Which Platform Fits Your Use Case
The right choice depends heavily on what is actually being protected and who controls the endpoints. Treat the list below as a starting point for a conversation with a security team rather than a final answer, since most production environments mix several of these scenarios at once.
- Public websites and APIs behind a CDN: Cloudflare’s default-on rollout means zero-effort protection for most sites already proxied through its network.
- Secrets and credential storage on AWS: Update to the newer Secrets Manager client libraries and the hybrid exchange activates automatically on every credential fetch.
- Regulated finance or government workloads: AWS’s explicit CNSA 2.0 alignment and FIPS 140-3 validated AWS-LC library give compliance teams a documented paper trail.
- Managed file transfer with external partners: AWS Transfer Family’s 2025-03 security policies cover SFTP and SSH sessions specifically, something neither Cloudflare nor most CDNs touch.
- Branch-office and enterprise WAN connectivity: Cloudflare One’s confirmed interoperability with Cisco and Fortinet hardware makes it the practical choice for distributed enterprise networks.
- Custom origin servers with non-standard TLS stacks: Cloudflare’s Automatic Key Exchange detects compatibility and falls back safely, reducing the risk of a broken rollout on unusual infrastructure.
- Organizations running both platforms: Treat Cloudflare as the default network-edge layer and AWS as the service-specific layer for anything touching KMS, Secrets Manager, or managed file transfer, since the two are not mutually exclusive.
The Verdict: Who’s Actually Ahead
On raw adoption numbers, Cloudflare is clearly ahead. Close to 70% of browser-generated traffic hitting its network now negotiates post-quantum key exchange, 45 billion connections get protected every day through Automatic Key Exchange, and the company did the work to fix its own HelloRetryRequest problem rather than leaving a 150-millisecond latency tax on the table. Cloudflare and Fastly together account for nearly 70% of all post-quantum TLS adoption measured across the broader internet, a figure that says Cloudflare’s default-on strategy is doing more to move the needle on global encryption than any opt-in program could.
AWS is not behind on engineering, it is behind on exposure. ML-KEM support in KMS, ACM, Secrets Manager, and Transfer Family is real, dated, and backed by a FIPS 140-3 validated library, but it only protects traffic once a customer updates a client library or picks a new security policy. For a regulated enterprise with a dedicated security team tracking CNSA 2.0 deadlines, that is a feature, not a flaw. For the median website operator, it means the protection sits unused until someone goes looking for it.
The practical takeaway: if traffic already flows through Cloudflare, post-quantum protection is very likely already active with no further action needed. If workloads run on AWS services like KMS, Secrets Manager, or Transfer Family, the protection exists but will not activate until SDKs and security policies get updated, so that update should move onto every 2026 infrastructure checklist now rather than later.
Neither company’s approach is a finished product. Cloudflare still has to solve the certificate side of the equation before it can call the job done, and its own roadmap admits broad browser trust is years away. AWS still has to get customers to actually update their SDKs, which history suggests is the slowest part of any security migration regardless of how good the underlying engineering is. The algorithm war is effectively over, ML-KEM won, NIST finalized it, and every major vendor builds on it now. What is left is a rollout problem, and on that specific question, the data in this comparison points to one company moving faster than the other.
Frequently Asked Questions
Is post-quantum encryption actually necessary today if quantum computers can’t break current encryption yet?
Yes, because of harvest now, decrypt later. Encrypted traffic recorded today can be stored and decrypted once a sufficiently powerful quantum computer exists, so data with a long confidentiality window needs protection now, not when the threat becomes immediate.
Does enabling post-quantum TLS slow down my website?
The intrinsic overhead is small, around 4% on the handshake and roughly 2 kilobytes of extra data per connection, based on Cloudflare’s measurements. Most reported latency problems trace back to misconfiguration, like unnecessary HelloRetryRequest round trips, rather than the cryptography itself.
Do I need to do anything if my site is behind Cloudflare?
In most cases, no. Cloudflare’s hybrid ML-KEM key exchange is on by default for compatible TLS 1.3 connections, and Automatic Key Exchange extends that to origin servers without manual configuration.
Which AWS services currently support post-quantum key exchange?
As of the April 2025 announcement, AWS Key Management Service, Certificate Manager, and Secrets Manager support ML-KEM hybrid key agreement on non-FIPS endpoints. AWS Transfer Family added support in September 2025, and AWS documentation also describes post-quantum key exchange support for Application and Network Load Balancer TLS listeners.
Will enabling post-quantum encryption cost more?
No documented surcharge exists on either platform. Cloudflare has stated publicly that post-quantum cryptography is included free across every supported product, and AWS’s published pricing pages for KMS, ACM, Secrets Manager, and Transfer Family do not list any additional charge tied to hybrid key exchange.
What’s the difference between ML-KEM and the older term Kyber?
Kyber was the pre-standardization candidate algorithm. Once NIST finalized FIPS 203 in August 2024, the standardized version became ML-KEM. Both Cloudflare and AWS ran Kyber in production before migrating to ML-KEM, and both have set or passed deadlines to fully retire Kyber support.
Is TLS 1.2 traffic protected by any of this?
Not through Cloudflare’s current mechanism, which is scoped specifically to TLS 1.3 and HTTP/3. Organizations still running significant TLS 1.2 traffic need a separate upgrade path to TLS 1.3 before hybrid post-quantum key exchange becomes available to them at all, and that upgrade is worth prioritizing on its own merits given how much faster TLS 1.3’s handshake already is.
Should I wait for post-quantum certificates instead of migrating key exchange now?
No. Key exchange and signatures protect against different risks and migrate on different timelines. Hybrid ML-KEM key exchange is already live and defeats harvest now, decrypt later today, while post-quantum certificates are still a 2026-and-beyond rollout. Waiting on one has no bearing on deploying the other.
How can I verify a connection is actually using post-quantum key exchange?
Run an OpenSSL client command specifying the X25519MLKEM768 group against the target host and inspect the negotiated server temporary key in the output, as shown in the code examples earlier in this guide. Cloudflare also provides a per-domain PQC visibility dashboard for zones on its network.