Post-Quantum TLS in 2026: Where Enterprises Stand and What to Do Now

More than half of the top million websites now negotiate post-quantum key exchange, and almost none of that is the work of the sites themselves. A content delivery network switched it on. That distinction matters for anyone who runs servers, because the part that CDNs cannot do for you, your origin servers, internal services and signatures, is where the work remains. This guide gives the current numbers, the deadlines that are now written into law and guidance, and a practical plan. All figures come from the sources linked, read on 7 November 2026.

Where adoption stands

F5 Labs reports that 54% of the top one million websites now support post-quantum key exchange, but that figure is driven by CDNs. Remove Cloudflare-hosted domains and adoption falls from 54% to 22% (F5 Labs, September 2026).

A study accepted to the ACM Internet Measurement Conference 2026 measured more than two billion TLS handshakes against one million domains from 11 vantage points across three rounds between July 2025 and March 2026. Among the 684,494 domains that answered every round, the share negotiating post-quantum key exchange by default rose from 31.26% to 49.22%, and every one used the same hybrid group, X25519MLKEM768. Cloudflare and Fastly account for roughly 70% of the deployment, 93.92% of it sits behind managed infrastructure and only 4.58% is owner-managed (Communications of the ACM).

The deadlines are now fixed

• United States: Executive Order 14412, signed 22 June 2026, sets 31 December 2030 for federal agencies to move their most sensitive systems to post-quantum encryption and 31 December 2031 for post-quantum authentication. It also directs federal contractors to comply with post-quantum FIPS standards by the end of 2030 (Cloudflare summary).
• NIST guidance from 2024: deprecate RSA and elliptic-curve cryptography by 2030 and disallow them by 2035.
• NSA CNSA 2.0: web browsers, servers and cloud services use post-quantum algorithms exclusively by 2033. Germany's BSI expects classical signatures to stop being used on their own by the end of 2035 (CACM).
• European Union: the NIS Cooperation Group roadmap of 23 June 2025 asks member states to start national transition strategies by the end of 2026 and to move high-risk use cases by the end of 2030.
• Cloudflare's own target: fully post-quantum, including authentication, by 2029, moved up in April 2026 after research breakthroughs (Cloudflare blog).

Gartner advises building a post-quantum inventory and remediation program in 2026, automated cryptographic bills of materials in 2027, TLS 1.3 by 2028 and all high-value systems on post-quantum cryptography by 2030. It estimates fewer than 10% of organizations support it for high-value data today and warns that teams that have not started piloting by 2027 can expect to pay at least 200% more for the full migration (Network World).

Key exchange first, signatures second

The two migrations are different. Key exchange protects today's traffic against "harvest now, decrypt later", where an attacker records encrypted traffic and decrypts it once a quantum computer exists. The hybrid X25519MLKEM768 group does this and is already default in major browsers and CDNs. Signatures and certificates protect against impersonation once such a computer exists, and that ecosystem is far less ready: post-quantum signatures are larger than elliptic-curve ones, and Cloudflare lists signatures for visitor connections as planned through Merkle Tree Certificates. The EU, US and Gartner timelines all put key exchange first for the same reason.

What you should do

1. Inventory where you use cryptography. List TLS endpoints, VPNs, internal service-to-service links, certificates, code-signing and embedded devices. A CDN covers only the visitor-to-edge leg.
2. Test your own endpoints, not your CDN. OpenSSL 3.5 added hybrid ML-KEM to TLS 1.3 and prefers it by default (OpenSSL Foundation, OpenSSL documentation). With OpenSSL 3.5 or later, openssl s_client -connect host:443 -tls1_3 prints a Server Temp Key line: X25519MLKEM768 means hybrid post-quantum, X25519 means classical.
3. Check your toolchain version. On our own server, a client built on OpenSSL 3.0.13 cannot even request the group: openssl s_client -groups X25519MLKEM768 fails with "group cannot be set", and a curl built on it negotiated plain X25519 against a Cloudflare endpoint. A stock distribution OpenSSL older than 3.5 will quietly stay classical, in both clients and servers.
4. Upgrade origins and internal services to TLS 1.3 on OpenSSL 3.5 or newer. Cloudflare says origin adoption rose from 6% to about 11% in a year, helped by the newer OpenSSL in Debian Trixie.
5. Ask vendors for dates. Make post-quantum support for key exchange, and a signature roadmap, part of every security product evaluation.
6. Plan for crypto agility. Keep algorithm choices in configuration, not code, so a change does not need a rewrite.

The handshake cost is small. An OpenSSL benchmark on its development branch rose from 13 ms to 15.5 ms after hybrid ML-KEM became the default, and the cost is paid only once per connection (OpenSSL Foundation). If you run your own mail or web servers, the same logic applies: see our guide on keeping a self-hosted mail server trusted for another case where an old default quietly becomes a problem.

Frequently asked questions

Is a quantum computer able to break TLS today? No known machine can. The reason to act now is harvest-now-decrypt-later and the fixed regulatory deadlines of 2030 and 2031.

What is X25519MLKEM768? A hybrid key exchange that combines classical X25519 with ML-KEM-768. An attacker has to break both, so security does not fall below the classical level.

If I use Cloudflare, am I done? For the visitor-to-edge leg, mostly. Your origin, internal traffic and signatures are separate, and only about 11% of origin servers behind Cloudflare use it.

Do I need post-quantum certificates now? Not yet for most teams. Prioritize key exchange and document a signature plan.