Cloudflare’s edge now sees roughly half of all human-generated HTTPS traffic negotiate a post-quantum key exchange, up from about 2% in March 2024. That jump happened in under two years, and it’s forcing a question that used to sound theoretical: should you turn on post-quantum TLS 1.3 today, or wait? This comparison lays out the real numbers, classical X25519/ECDHE against hybrid ML-KEM, so you can make that call with data instead of guesswork.
The short version: hybrid post-quantum TLS 1.3 costs you a few extra milliseconds and a couple of kilobytes per handshake, and in exchange it protects today’s traffic against “harvest now, decrypt later” attacks that quantum computers could unlock a decade from now. Whether that trade makes sense depends heavily on your stack, your traffic volume, and how much you care about a threat model that hasn’t arrived yet but is already shaping procurement rules at NIST and inside the Department of Defense.
What Changed: Classical TLS 1.3 vs Post-Quantum TLS 1.3 in 2026
Classical TLS 1.3 key exchange has run on elliptic-curve Diffie-Hellman since the protocol shipped in RFC 8446 back in 2018. X25519 is the workhorse: a 32-byte public key, single-digit-microsecond math, and a handshake that fits in one network round trip. It has held up against every classical attack thrown at it for over a decade. What it can’t survive is a large enough quantum computer running Shor’s algorithm, which would recover the private key from the public one in polynomial time instead of the astronomical time classical computers need.
Post-quantum TLS 1.3 doesn’t replace X25519, at least not yet. It pairs it with ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism that NIST finalized as FIPS 203 in August 2024. The combination is called a hybrid key exchange: the client and server run both algorithms and combine the two shared secrets into one session key. If ML-KEM turns out to have some undiscovered flaw, X25519 still protects the connection. If a quantum computer someday breaks X25519, ML-KEM still protects it. You need both to fail before the session is exposed.
As of July 20, 2026, NIST treats FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) as its stable post-quantum cryptography baseline, according to a Neura Parse summary of NIST’s 2026 status. On the IETF side, the standards track caught up fast: RFC 10024, the Post-Quantum Traditional (PQ/T) hybrid key exchange spec for ML-KEM, published as a Proposed Standard in August 2026, per the IETF datatracker entry. Three hybrid groups now exist for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, combining a post-quantum KEM with an elliptic-curve exchange, as described in the IETF TLS working group draft that RFC 10024 formalized.
Why the Quantum Threat Is Real Before Quantum Computers Are
No quantum computer today can break RSA-2048 or X25519. NIST is direct about that on its own explainer page: “No one knows how long it will take to build a cryptographically relevant quantum computer,” and “experts’ estimates range from a few years to a few decades.” What’s shifted isn’t the existence of such a machine, it’s the resource estimate for building one. In 2019, researchers projected a quantum computer would need about 20 million noisy qubits to factor a 2048-bit RSA key. A May 2025 preprint from Google researchers cut that estimate to under 1 million noisy qubits running for about a week, a roughly 20-fold reduction in three years. Some newer architecture proposals suggest the number could fall further, toward 100,000 qubits, though that remains theoretical rather than built hardware.
That downward trend is why “harvest now, decrypt later” has moved from a theoretical footnote to a budget line item. Keyfactor defines it plainly: “Harvest Now, Decrypt Later (HNDL) is a cyberattack strategy in which adversaries intercept and store encrypted data today with the intent of decrypting it in the future.” An older NIST internal report (NISTIR 8105) cited a researcher estimate that a machine capable of breaking RSA-2048 in hours could exist by 2030 for roughly a billion dollars, an optimistic but not fringe projection. Whether the real date lands closer to 2030 or 2040, encrypted data captured today with classical-only key exchange will still be sitting on someone’s disk when that day arrives.
The industries most exposed aren’t limited to intelligence agencies. Government and diplomatic communications, defense and aerospace R&D, financial services (which often carry 7+ year regulatory retention mandates), healthcare records (6 to 30 years under HIPAA-style rules), and manufacturing IP tied to 20-year patent lifecycles all generate data whose confidentiality window outlives the current cryptographic threat model. That’s the actual argument for enabling hybrid post-quantum TLS 1.3 now rather than waiting for a quantum computer to exist: the decision isn’t about protecting today’s traffic from today’s attackers, it’s about protecting today’s traffic from tomorrow’s decryption capability.
Post-Quantum TLS 1.3 vs Classical TLS 1.3: Specs Table
Here’s the side-by-side breakdown of every metric that matters when you’re deciding which key exchange group to run in production.
| Metric | Classical (X25519) | Hybrid PQ (X25519MLKEM768) | Pure PQ (ML-KEM-1024) |
|---|---|---|---|
| Client public key size | 32 bytes | 1,216 bytes (32 + 1,184) | 1,568 bytes |
| Server response size | 32 bytes | 1,120 bytes (32 + 1,088) | 1,568 bytes |
| Total added handshake data vs X25519 | Baseline | ≈2.27 KB | ≈3.07 KB |
| Client ops/sec (Cloudflare bench) | 19,000 | ~19,000 (X25519) + 29,000 (ML-KEM-768) | 20,000 |
| Server ops/sec (Cloudflare bench) | 19,000 | ~19,000 (X25519) + 45,000 (ML-KEM-768) | 30,000 |
| Median handshake latency add (lab) | 0 ms (baseline ≈0.3 ms) | +1.5-1.9 ms | +1.5-1.9 ms |
| Median added latency at internet scale | 0 ms | ~1.5 ms median, 7 ms tail | Not widely deployed |
| Quantum resistance | None | Yes (needs both breaks to fail) | Yes |
| NIST FIPS status | Not a PQC standard | ML-KEM = FIPS 203 (Aug 2024) | FIPS 203 |
| IETF TLS standard | RFC 8446 (2018) | RFC 10024 (Aug 2026) | Informational RFC, IETF Last Call closed Aug 13, 2026 |
| Browser default support | Universal | Chrome (since v124), Edge, Firefox default on | Not enabled by default anywhere |
| Cloudflare edge adoption (late 2025) | — | ~52% of inbound TLS traffic | Negligible |
Two rows deserve a second look. First, ML-KEM’s raw operations-per-second actually beat X25519 in Cloudflare’s own benchmark table, published in the Cloudflare 2024 state-of-post-quantum blog post: ML-KEM-768 handled 29,000 client ops/sec and 45,000 server ops/sec versus X25519’s 19,000 on both sides. The bottleneck in hybrid mode isn’t CPU time, it’s the extra 2.27 KB of handshake payload that has to cross the wire. Second, “pure” post-quantum TLS 1.3 (ML-KEM with no classical component) exists as a draft but isn’t production-ready. Every major deployment today runs the hybrid mode, keeping the classical algorithm as a safety net.
Benchmark Data: How Much Slower Is Post-Quantum TLS 1.3?
Three independent sources converge on a similar answer: the overhead is small, but it’s not zero, and it scales differently depending on where you measure it.
At the CDN edge, a 2025 recap covering deployments at Cloudflare, Google Frontend, and Apple’s iCloud Private Relay found the added handshake overhead runs about 1.5 ms at the median and 7 ms at the tail, with no measurable drop in connection success rate, according to EverTrust’s analysis of hybrid post-quantum certificates. That’s the number that matters most for anyone running a public-facing service: a single-digit millisecond tax that most users will never notice.
Lab conditions tell a slightly different story because they isolate the handshake from network jitter. A 2026 experimental paper on classical, hybrid, and pure post-quantum key exchange measured median TLS handshake latency rising from about 0.3 ms for X25519 alone to 1.8-1.9 ms for both hybrid and pure post-quantum configurations. In end-to-end connection timing (TCP setup plus TLS handshake), the same study found X25519MLKEM768 added roughly 18.7% to total connection time compared to X25519 alone, moving median connection time from about 16.5 ms to 19.6 ms, per the arXiv paper on post-quantum TLS 1.3.
On the size side, Cloudflare’s own developer documentation confirms the deployed default: X25519MLKEM768 is Cloudflare’s recommended hybrid group across its entire edge network. That single group choice matters, because it’s become the de facto industry default that Chrome, Edge, Firefox, and most server implementations converged on rather than fragmenting across the three available combinations.
| Benchmark source | Measurement | X25519 (classical) | X25519MLKEM768 (hybrid) | Overhead |
|---|---|---|---|---|
| Cloudflare/Google/Apple 2025 field data | Median handshake latency at scale | Baseline | +1.5 ms median | ~1.5 ms median, 7 ms tail |
| arXiv 2026 lab study | Median TLS handshake latency | 0.3 ms | 1.8-1.9 ms | +1.5-1.6 ms |
| arXiv 2026 lab study | Total connection time (TCP+TLS) | 16.53 ms | 19.63 ms | +18.7% |
| Cloudflare 2024 benchmark table | Server-side key ops/sec | 19,000 | 45,000 (ML-KEM-768 component) | ML-KEM faster in isolation |
The takeaway across all three sources: hybrid post-quantum TLS adds low single-digit milliseconds to a handshake and 10-20% to total connection setup time under lab conditions, but that overhead nearly disappears at internet scale once you account for network latency, TCP slow start, and TLS session resumption, which most repeat connections use anyway.
Adoption Numbers: Who’s Actually Running Post-Quantum TLS 1.3
Adoption moved faster than almost anyone expected. Cloudflare measured about 2% of TLS 1.3 connections using post-quantum key exchange in March 2024. A year later, after Chrome and other browsers flipped their defaults, more than a third of human-generated traffic reaching Cloudflare’s network used hybrid post-quantum handshakes. By mid-September 2025, that figure hit roughly 43% of human connections, and by late 2025, Cloudflare’s own reporting put inbound post-quantum hybrid traffic at approximately 52%, per the State of the Post-Quantum Internet in 2025 report.
| Date | Post-quantum TLS 1.3 adoption (Cloudflare edge) |
|---|---|
| March 2024 | ~2% of TLS 1.3 connections |
| March 2025 | Over one-third of human HTTPS traffic |
| Mid-2025 | Over 30% of TLS 1.3 connections; over 50% on modern browsers/devices |
| September 2025 | ~43% of human-generated connections |
| Late 2025 | ~52% of inbound TLS traffic |
Chrome enabled ML-KEM hybrid TLS by default starting with Chrome 124 (April 2024), and that single decision, combined with Cloudflare’s edge deployment, effectively set the industry default overnight. Firefox followed with X25519MLKEM768 enabled by default starting in Firefox 132, extending to QUIC/HTTP/3 traffic in Firefox 135. Edge and OpenSSL 3.5 (released April 2025) added the same hybrid default, and Go 1.24+ enables X25519MLKEM768 by default in its crypto/tls package, which covers every Go-based server including Caddy, Traefik, and CoreDNS. Apple’s iCloud Private Relay is also running hybrid post-quantum TLS at scale, alongside Google Frontend, based on the deployments tracked in the EverTrust analysis cited above.
The picture on the server and cloud side has caught up too. Microsoft shipped post-quantum TLS support to Windows in July 2026: update KB5089573 for Windows 11 24H2/25H2 and KB5099536 for Windows Server 2025 added the three hybrid key exchange groups, though they ship disabled by default and need to be turned on through Group Policy, MDM, or TLS PowerShell cmdlets, according to Tech Times’ coverage of the Windows update. That default-off posture matters: even fully patched Windows machines get no post-quantum protection until an administrator flips the switch, and it only helps connections that negotiate TLS 1.3, not TLS 1.2 or earlier.
Cloud and Platform Support: AWS, Java, and Beyond
Cloud providers moved from “roadmap” to “shipped” over the past year. AWS added ML-KEM hybrid post-quantum key agreement to AWS Key Management Service, AWS Certificate Manager, and Secrets Manager endpoints. “Today, AWS Key Management Service (AWS KMS), AWS Certificate Manager (ACM), and AWS Secrets Manager endpoints now support Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for hybrid post-quantum key agreement in non-FIPS endpoints in all AWS Regions in the aws partition,” AWS’s security team wrote in its ML-KEM post-quantum TLS announcement. That’s a meaningful shift: it means any application calling those AWS APIs over TLS can now get quantum-resistant key exchange without changing application code, just by connecting to endpoints that support the hybrid groups.
Oracle brought the same capability to the JDK. “This feature enhances the security of Java applications by implementing hybrid key exchange algorithms for TLS 1.3,” the Oracle Java team explained when announcing the feature, adding that “by combining quantum-resistant ML-KEM with traditional elliptic-curve algorithms, the JDK implementation of TLS 1.3 is protected against such attacks,” per the Inside Java post from February 2026. For the millions of backend services still running on Java, that’s a drop-in upgrade path rather than a rewrite.
Google Cloud has moved the furthest among the big three. Public endpoints at google.com and *.googleapis.com already run ML-KEM in hybrid mode, and Google Cloud Load Balancing added X25519MLKEM768 support for Application and Proxy Load Balancers on a staged rollout: opt-in starting June 2, 2026, enabled by default from October 2026, and permanently on with no opt-out from October 2027. Cloud KMS reached general availability for ML-KEM-768, ML-KEM-1024, and a hybrid X-Wing construction combining X25519 with ML-KEM-768, and Google’s internal ALTS service-to-service protocol completed its own quantum-safe migration in 2025.
Azure’s rollout is more fragmented. Post-quantum cryptography APIs for ML-KEM and ML-DSA became generally available on Windows Server 2025 and Windows 11 in November 2025, and TLS hybrid key exchange using those groups reached Windows via Schannel starting with the July 2026 update. On the application layer, ASP.NET Kestrel supports hybrid TLS 1.3 when running on Windows Server 2025, and .NET 10’s HttpClient supports it on Windows Server 2025 or on Linux paired with SymCrypt-OpenSSL 1.9.0 or later. Azure Application Gateway and Azure Front Door added X25519MLKEM768 support in 2025 through a preview TLS policy, but as of August 2026, managed services like Azure SQL, Cosmos DB, and Azure Storage haven’t publicly confirmed post-quantum TLS support at their endpoints, and Azure Key Vault doesn’t yet offer ML-KEM or ML-DSA key types for customer use.
Not every part of the picture is settled. Researchers studying real-world tradeoffs note the practical cost clearly. “The hybrid mode, as standardized by the IETF in TLS 1.3, supports simultaneous usage of ECDH and PQC KEM, albeit at the cost of increased data transmission size and computational resources,” a group of cryptography researchers wrote in their arXiv paper on post-quantum TLS 1.3. That’s the honest framing: hybrid mode isn’t free, it’s a deliberate trade of a small, measurable cost today against a large, uncertain cost avoided later.
Pricing: What Does Post-Quantum TLS Actually Cost?
There’s no separate line item for “post-quantum TLS” on most cloud bills, because the cost shows up indirectly, in bandwidth, compute, and certificate management rather than a dedicated SKU. Here’s how the major platforms handle it as of August 2026.
| Provider/service | Post-quantum TLS availability | Additional cost | Notes |
|---|---|---|---|
| Cloudflare (any plan) | Enabled by default at the edge | $0 | X25519MLKEM768 is the recommended default group, no config needed |
| AWS KMS / ACM / Secrets Manager | Supported on non-FIPS endpoints, all AWS regions | $0 extra for the key exchange itself | Standard API request pricing applies; no published PQC-specific surcharge |
| Windows Server 2025 / Windows 11 | Available via KB5099536 / KB5089573 | $0 (included in update) | Disabled by default, requires admin configuration |
| OpenSSL 3.x / Go standard library | Hybrid groups supported | $0 (open source) | Requires recent version and explicit cipher suite configuration |
| Oracle JDK (2026 releases) | Hybrid key exchange for TLS 1.3 | $0 for the feature | Standard JDK licensing terms apply |
| Chrome, Edge, Firefox | Enabled by default | $0 | No user or developer action required |
The real cost isn’t a fee, it’s bandwidth and CPU at volume. A service handling a billion TLS handshakes a month, at roughly 2.27 KB of extra handshake data per hybrid connection, adds about 2.1 TB of additional monthly egress just from the key exchange overhead. For most organizations that’s a rounding error against total traffic, but it’s worth modeling if you run a high-volume API gateway or IoT fleet with tight bandwidth budgets. No cloud provider currently publishes a distinct per-operation price for ML-KEM versus classical key exchange in their KMS pricing pages. The operations are billed identically to their classical counterparts.
ML-KEM Security Levels: 512 vs 768 vs 1024 Explained
ML-KEM ships in three parameter sets, and picking the right one is a security-margin decision, not a performance one, since all three are fast enough for production TLS. ML-KEM-512 targets a security level comparable to AES-128, with an 800-byte client public key and 768-byte server response, and the fastest raw throughput of the three at 45,000 client and 70,000 server operations per second in Cloudflare’s benchmark. ML-KEM-768, the deployed industry default via X25519MLKEM768, sits at a security level roughly comparable to AES-192, balancing a 1,184-byte public key against still-solid throughput of 29,000 to 45,000 ops/sec. ML-KEM-1024 targets AES-256-equivalent security, with the largest keys (1,568 bytes both directions) and the lowest, though still fast, throughput at 20,000 to 30,000 ops/sec.
Almost nobody deploys ML-KEM-512 for TLS in practice, since the security margin over classical attacks is considered too thin for long-term data protection. The real choice in production is between ML-KEM-768 (the default nearly everyone runs, via X25519MLKEM768) and ML-KEM-1024 (via SecP384r1MLKEM1024, reserved for higher-assurance use cases like government and defense systems that want a larger margin against future cryptanalytic advances against the lattice problem ML-KEM relies on). For most organizations, matching the industry default of X25519MLKEM768 is the pragmatic choice: it’s what browsers negotiate, what Cloudflare recommends, and what the broadest set of clients already support.
Testing and Validating Your Post-Quantum TLS Setup
Before rolling hybrid post-quantum TLS out broadly, confirm it’s actually negotiating the way you expect. The openssl s_client command shown earlier is the fastest single-connection check, and it reports the negotiated group directly in its output. For a broader external view, Qualys SSL Labs’ server test reports supported TLS 1.3 groups for any public-facing server, making it useful for confirming a hybrid group is visible to typical clients rather than only to your own test rig. The open-source testssl.sh tool does the same check from the command line and is easier to script into a CI pipeline that runs against staging before every deploy.
For internal services, packet capture is more reliable than trusting application logs. A Wireshark capture of a TLS 1.3 ClientHello will show the supported_groups extension, letting you confirm both which groups a client offers and which one the server actually selects in its ServerHello. This matters most during the transition period, when you want to confirm a change to server configuration didn’t accidentally disable the hybrid group instead of adding it, a mistake that’s easy to make with a single misplaced colon in an OpenSSL cipher string.
Real-World Deployments: 5 Examples
Post-quantum TLS 1.3 isn’t a lab experiment anymore. Here’s who has actually shipped it in production as of August 2026.
Cloudflare’s global edge network. Every domain on Cloudflare gets X25519MLKEM768 as an available, and often preferred, key exchange group automatically. It’s the single largest deployment of post-quantum TLS on the internet, and Cloudflare’s own telemetry is the source most other researchers cite for adoption trends.
Google Frontend. Google’s front-end infrastructure, which terminates TLS for Search, Gmail, and most Google services, runs hybrid post-quantum key exchange at scale, contributing to the low single-digit-millisecond overhead figures cited in the EverTrust deployment recap.
Apple iCloud Private Relay. Apple’s privacy-focused relay service, which routes traffic through two separate hops to obscure IP addresses, added hybrid post-quantum key exchange to its own TLS stack as part of the same 2025 wave of large-scale deployments.
AWS KMS, ACM, and Secrets Manager. Any application authenticating to these AWS services over non-FIPS endpoints can now negotiate ML-KEM hybrid key exchange, protecting credentials, certificates, and secrets in transit against future quantum decryption of intercepted traffic.
Windows Server 2025 and Windows 11 fleets. Enterprises running the July 2026 cumulative updates can now enable hybrid post-quantum TLS 1.3 for internal and external connections, though it requires deliberate configuration through Group Policy rather than arriving pre-enabled.
5 Use Cases: When to Choose Which
Public-facing web and API traffic at any scale. Enable hybrid post-quantum TLS 1.3. The overhead is a few milliseconds and modest bandwidth, and Cloudflare, AWS, and modern browsers already handle it transparently. There’s no good reason to leave this off for HTTPS traffic serving the general public in 2026.
Long-lived confidential data (health records, financial transactions, government communications). Prioritize hybrid post-quantum TLS immediately. This is the “harvest now, decrypt later” scenario: an adversary recording encrypted traffic today could decrypt it once quantum computers mature, so data that needs to stay secret for 10+ years is the highest-priority migration target.
Bandwidth-constrained IoT and embedded devices. Test carefully before switching. The extra 2.27 KB per handshake and the larger public key sizes can strain devices on cellular or LPWAN connections with tight data caps or small memory budgets. Measure actual overhead on your hardware before rolling out fleet-wide.
Legacy systems still pinned to TLS 1.2. Post-quantum key exchange doesn’t help you here at all. Migrate to TLS 1.3 first. Only TLS 1.3 sessions can use the hybrid ML-KEM groups.
Regulated federal and defense systems. Follow NIST’s staged timeline rather than making an independent call. Initial PQC integration is required for federal civilian agencies in 2026, with additional gates for high-value assets by 2030, full system migration for high-impact and defense systems by 2031, and final infrastructure cutover by 2035, according to a summary of NIST’s 2026 PQC migration requirements.
Migration Guide: Moving from Classical to Post-Quantum TLS 1.3
Migrating doesn’t mean ripping out your existing TLS stack. It means adding hybrid groups alongside what you already run, then monitoring before making anything the sole option.
- Confirm you’re on TLS 1.3. Hybrid ML-KEM groups only apply to TLS 1.3 negotiations. Check your server config and confirm TLS 1.2 fallback is minimized or logged.
- Update your TLS library. You need OpenSSL 3.2+, a recent BoringSSL build, Go 1.24+, or an equivalent that ships X25519MLKEM768 support. Older library versions won’t recognize the new cipher suite codes.
- Enable the hybrid group, don’t force pure post-quantum. Add X25519MLKEM768 as a supported (not sole) group. This keeps classical fallback available for clients that don’t yet support the hybrid mode.
- Test handshake success rates before and after. Compare TLS handshake failure rates for a week pre- and post-change. Cloudflare’s field data shows no measurable drop, but your client mix may differ, especially with older mobile devices or embedded clients.
- Measure actual latency impact on your traffic. Don’t rely on published benchmarks alone. Instrument real handshake timing before and after enabling hybrid groups, since your network path and client geography affect the real-world number more than the algorithm does.
- Check downstream dependencies. Load balancers, WAFs, and TLS-terminating proxies all need to support the new groups too. A hybrid-capable origin server behind a proxy that only knows classical groups gets you nothing.
- Enable on internal service-to-service traffic separately. Internal mTLS between microservices is often lower-risk to update first, since you control both ends and can roll back quickly if something breaks.
- Plan for certificate and signature algorithm migration separately. ML-KEM covers key exchange, not digital signatures. Certificates still typically use RSA or ECDSA signatures. Migrating to ML-DSA (FIPS 204) for signatures is a separate, later project.
- Set a monitoring dashboard for adoption rate. Track what percentage of your incoming connections actually negotiate the hybrid group over time, the same way Cloudflare publishes its own adoption numbers.
- Revisit annually against the NIST timeline. Federal and regulated deployments should track NIST’s 2026-2035 staged deadlines and adjust urgency accordingly, even if your organization isn’t directly regulated.
Sample Configuration: Enabling Hybrid ML-KEM in OpenSSL
For server operators running OpenSSL 3.2 or later, enabling the hybrid group is a configuration change, not a code change.
# nginx.conf snippet — enable hybrid post-quantum group alongside classical
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
# Verify negotiated group with openssl s_client
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3
# Expected output includes:
# Peer signing digest: SHA256
# Negotiated TLS1.3 group: X25519MLKEM768The order matters: listing X25519MLKEM768 first tells the server to prefer it when the client supports it, while keeping X25519 and prime256v1 as fallback for clients that don’t yet negotiate the hybrid group.
Pros and Cons of Post-Quantum TLS 1.3
Hybrid Post-Quantum TLS 1.3: Pros
- Protects against harvest-now-decrypt-later attacks on long-lived sensitive data
- Standardized (RFC 10024) and NIST-approved (FIPS 203), not experimental cryptography
- Already the default in Chrome, Edge, and Firefox with no user action needed
- Keeps classical algorithm as a fallback, so it can’t be weaker than what you run today
- Free to enable across Cloudflare, AWS, OpenSSL, Go, and the JDK
- ML-KEM’s core operations are computationally fast, often faster than X25519 in raw ops/sec
Hybrid Post-Quantum TLS 1.3: Cons
- Adds roughly 2.27 KB per handshake, which matters on constrained networks
- Requires updated TLS libraries, since older stacks can’t negotiate the new groups at all
- Windows support ships disabled by default, requiring manual admin configuration
- Doesn’t address digital signatures, only key exchange, so certificates need separate migration
- Pure (non-hybrid) post-quantum TLS 1.3 is still not production-recommended as of August 2026
- Adds 10-20% to total connection setup time in lab conditions, though this shrinks at internet scale
The Verdict: Should You Turn On Post-Quantum TLS 1.3 Now?
Yes, for nearly everyone, and the data backs it up. The overhead measured across three independent sources, Cloudflare/Google/Apple field data, a 2026 academic study, and Cloudflare’s own operations benchmark, lands in the same range: roughly 1.5 to 2 milliseconds of added median latency and about 2.27 KB of extra handshake payload. Against that small, well-measured cost sits a real, if delayed, threat: encrypted traffic intercepted and stored today could be decrypted once cryptographically relevant quantum computers exist, a risk that grows every year you wait.
Adoption data shows the industry has already made this call. Post-quantum hybrid key exchange went from 2% to roughly 52% of Cloudflare’s inbound TLS traffic in under two years, and it’s the default in every major browser without users noticing or opting in. If your TLS library and infrastructure already support X25519MLKEM768, the actual decision isn’t “should I migrate” but “why haven’t I enabled the setting yet.” The main groups where waiting still makes sense are bandwidth-constrained embedded devices, where the extra kilobytes genuinely matter, and organizations still running TLS 1.2, who need to solve that more basic problem first.
Frequently Asked Questions
Does post-quantum TLS 1.3 replace classical encryption entirely?
No. Production deployments use hybrid mode, combining ML-KEM with classical X25519 or a NIST elliptic curve. Both algorithms have to fail for the connection to be compromised. Pure post-quantum-only TLS 1.3 exists as an IETF draft but isn’t the recommended production configuration as of August 2026.
How much slower is a post-quantum TLS 1.3 handshake?
Field data from Cloudflare, Google, and Apple’s 2025 deployments shows about 1.5 ms added at the median and 7 ms at the tail, with no measurable drop in connection success rate. Lab studies show a larger relative jump, around 18.7% in total connection time, but that gap narrows significantly at internet scale.
Which browsers support ML-KEM hybrid TLS 1.3 by default?
Chrome has supported it by default since version 124. Edge and recent Firefox versions also enable hybrid post-quantum key exchange by default. Apple’s OS-level networking stack, including iCloud Private Relay, supports it in production as well.
Does Windows support post-quantum TLS 1.3?
Yes, as of the July 2026 updates (KB5089573 for Windows 11 24H2/25H2, KB5099536 for Windows Server 2025), which added three hybrid key exchange groups. They ship disabled by default and need to be turned on through Group Policy, MDM, or TLS PowerShell cmdlets.
What’s the difference between ML-KEM-768 and ML-KEM-1024?
ML-KEM-768 offers a security level roughly comparable to AES-192 and produces a 1,184-byte public key with a 1,088-byte ciphertext. ML-KEM-1024 targets a higher security level comparable to AES-256, with larger 1,568-byte keys and ciphertexts on both sides. X25519MLKEM768 is the deployed industry default; SecP384r1MLKEM1024 is available for higher-assurance use cases.
Do I need to update my TLS certificates for post-quantum TLS 1.3?
Not for key exchange. Hybrid ML-KEM affects the key exchange step only, not certificate signatures. Your existing RSA or ECDSA certificates keep working. Migrating certificate signatures to post-quantum algorithms like ML-DSA (FIPS 204) is a separate project on a slower timeline.
Is post-quantum TLS 1.3 required by any regulation yet?
For US federal civilian agencies, initial PQC integration is required starting in 2026, with staged deadlines through 2035 for full migration of high-impact and defense systems. Private-sector adoption is currently voluntary but accelerating fast given browser and cloud provider defaults.
Will enabling hybrid post-quantum TLS break older clients?
Not if configured correctly. Adding X25519MLKEM768 as a supported group alongside classical groups, rather than as the only option, lets older clients that don’t recognize the hybrid group fall back to standard X25519 or ECDHE negotiation without failing the connection.
What is harvest-now-decrypt-later and why does it matter for TLS?
It’s the attack pattern where an adversary records encrypted TLS traffic today and stores it, betting that a future quantum computer will be able to decrypt the classical key exchange retroactively. It matters for TLS specifically because the key exchange, not just the encrypted payload, is what a quantum computer would need to break. Data protected only by classical X25519 today could become readable in the future even though nothing about the stored ciphertext changes; only the attacker’s decryption capability does.
Related Coverage
- TLS 1.3 vs TLS 1.2: 70% Adoption, 1-RTT Handshake [2026]
- ML-KEM vs RSA: 1,184-Byte Keys, 52% Web Adoption [2026]
- ML-KEM vs ML-DSA: 1,088 vs 3,293 Bytes [2026]
- ML-DSA vs SLH-DSA: 2.4KB vs 7.8KB Signatures [2026]
- ECC vs RSA: 25x Faster Signing, Smaller Keys [2026]
For more coverage of encryption standards and cryptographic protocols, visit the Cryptography section.
