Post-quantum cryptography in TLS: real-world adoption

Actualizado: 2026-05-03

Just two years ago, post-quantum cryptography in TLS was a conference talk, an experiment in OpenSSL side branches, and a topic those of us not professionally in cryptography listened to with curiosity but no urgency. In September 2025 the landscape is radically different: the big operators have rolled ML-KEM hybrids into production on real end-user connections, most HTTPS traffic on modern browsers already negotiates post-quantum algorithms, and it is time to stop treating the topic as science fiction and start checking whether our own infrastructures are ready.

Key takeaways

• The inflection point was March 2024: Chrome enabled X25519Kyber768 by default; Cloudflare had been negotiating it since September 2023. After NIST ratification in August 2024, the final name is X25519MLKEM768.
• By mid-2025, over 30% of TLS 1.3 connections to Cloudflare’s edge negotiate a PQC hybrid group; over 50% filtering by modern browsers on recent devices.
• OpenSSL 3.5 (April 2025) includes ML-KEM in the official tree — any NGINX, Apache or HAProxy compiled against 3.5 can negotiate the hybrid group without external patches.
• The cost: an ML-KEM-768 public key is 1,184 bytes versus 32 bytes for X25519 — the ClientHello exceeds standard TCP packet size and forces fragmentation on networks with old middleboxes.
• Digital signatures (ECDSA, RSA) remain classical — ML-DSA and SLH-DSA are ratified but post-quantum certificates remain rare in 2025.

The phase shift in numbers

The inflection point started in March 2024, when Chrome enabled the X25519Kyber768 group by default for TLS 1.3 connections to servers that support it. Cloudflare had begun negotiating it at the edge in September 2023, and Apple added it to iMessage with PQ3 in February 2024. With the NIST ratification in August 2024, the final version was named ML-KEM-768 and the TLS hybrid group was renamed X25519MLKEM768.

The numbers published by Cloudflare are striking. By mid-2025, over 30 percent of TLS 1.3 connections to their edge negotiate a post-quantum hybrid group, and that figure rises above 50 percent when filtered by modern browsers on recent devices. Similar telemetry from Google and Mozilla points the same way.

The other metric worth looking at is server-side compatibility. OpenSSL 3.5 included ML-KEM directly in the official tree in April 2025, which means any NGINX, Apache, or HAProxy compiled against OpenSSL 3.5 or later can negotiate the hybrid group without external patches.

How the hybrid works without myths

There is a widespread misunderstanding worth clearing up. ML-KEM-768 does not replace X25519: it is combined with it in what is called a hybrid exchange. Client and server exchange keys using both algorithms and derive a shared secret from both.

The reason is prudence: ML-KEM is new and has not endured twenty years of intense cryptanalysis like X25519. This defense-in-depth logic is what enabled mass deployment. It is not betting all security on a new algorithm, it is adding a layer without removing the existing one. The benefit is that, even if a future adversary stores encrypted traffic today to decrypt tomorrow with a quantum computer, today’s hybrid traffic remains opaque. This is called harvest-now-decrypt-later resistance in the industry.

The weight of the handshake

The elephant in the room with ML-KEM is size. An ML-KEM-768 public key is 1,184 bytes, and the encapsulation ciphertext another 1,088 bytes. Compared to the 32 bytes of an X25519 public key, that is a two-order-of-magnitude increase. In practical terms, a TLS 1.3 ClientHello with X25519MLKEM768 weighs over two kilobytes and can exceed standard TCP packet size, forcing fragmentation.

This has two notable consequences:

1. Networks with old middleboxes can break the handshake. Isolated cases have been reported in old home routers, poorly configured corporate firewalls, and mobile operators in specific countries. The browser response has been to implement detection and fallback to classical groups when the PQC handshake fails.

2. Effective handshake RTT increases slightly. Measured on modern fiber connections with TLS 1.3 and TLS False Start, the increase is a few milliseconds and practically imperceptible. On mobile 3G connections in high-latency regions, the increase can reach tens of milliseconds.

What to check in your own infrastructure

If you run public web servers, this is a good time to audit. The points to check are relatively simple:

First, the OpenSSL version compiled into your servers. Anything below 3.5 does not have native ML-KEM. Long-cycle distributions like Debian 12 still carry OpenSSL 3.0, although Debian 13 released in August 2025 ships 3.5.

Second, web server configuration. NGINX accepts post-quantum groups from version 1.27, and verifying with the ssl_groups directive including X25519MLKEM768 explicitly is worthwhile. On Apache with mod_ssl and HAProxy it is similar. Traefik — which I use — negotiates PQC automatically when the underlying OpenSSL supports it, with no extra configuration.

Third, metrics. If you use Prometheus or similar, adding metrics of negotiated TLS groups is worthwhile to see the real proportion of post-quantum connections. Watching the number climb is a concrete way to confirm the migration works.

Fourth, CDNs and intermediate providers. If your traffic goes through Cloudflare, Fastly, or Akamai, PQC negotiation happens at the edge and your origin needs no changes. But if you have direct connections without CDN, the work falls on you.

Post-quantum signatures are another story

An important nuance is that the current rollout only covers key exchange with ML-KEM. Digital signatures, which in TLS use ECDSA or RSA certificates, remain classical. NIST standards for post-quantum signatures, ML-DSA and SLH-DSA, were ratified in August 2024, but post-quantum certificates are still rare.

The reason is that an ML-DSA signature weighs several kilobytes, which significantly inflates a handshake already carrying a full certificate chain. My reasoned forecast is that this transit will take two or three more years to land, because it requires coordination among certificate authorities, browsers, and operators.

How to think about the decision

My read is that 2025 is the year PQC in TLS stops being a futuristic option and becomes basic hygiene. Doing nothing is not neutral: it means your traffic remains susceptible to the harvest-now scenario, with an opportunity cost that grows every month as the rest of the web advances. For anyone running critical infrastructure, the question is not whether to migrate but when.

The good news is that the migration cost is low. Updating to OpenSSL 3.5, verifying web server configuration, and adding metrics is a half-day job on most infrastructures. The bad news is that certificate authorities and certificates remain classical, leaving the signatures side of the handshake unresolved. But that is manageable as long as key exchange is covered.

The concrete recommendation for those of you who manage something public: review in the coming months, not a year from now. The window to do it calmly closes quickly, and when post-quantum traffic climbs from 50 to 80 percent, staying on legacy configurations starts becoming a visible problem, not just a theoretical weakness.