F5 reports 54% of the top 1 million websites support PQC key exchange, driven mainly by default CDN and edge-platform enablement.
After analyzing the world’s top 1 million websites, F5 found that 54% already support Post-Quantum Cryptography (PQC) key exchange, indicating that the web is rapidly adopting quantum-resistant communications capabilities. This growth is not entirely driven by enterprises proactively upgrading; it has been significantly boosted by default-enable policies from CDNs and edge service platforms, with Cloudflare and Fastly having the most notable impact.
The same analysis also showed that if Cloudflare-hosted websites are excluded, PQC key exchange support would drop from 54% to 22%, underscoring how heavily the current adoption curve depends on the default capabilities of large platforms.
The core value of PQC key exchange lies in shifting the key negotiation process in TLS handshakes to mechanisms that can resist attacks from quantum computers. F5 noted that the most visible real-world deployment today is the use of hybrid or post-quantum key exchange at the TLS layer, rather than a full replacement of existing cryptographic infrastructure.
However, website identity authentication is still at a later stage of deployment. F5 Labs pointed out that pure PQC or hybrid PQC X.509 certificates for website authentication have not yet appeared in the public web environment. This means that even though connection key negotiation is becoming widespread, certificate systems and signature verification remain the next major hurdle.
The main technical barrier comes from the characteristics of the algorithms themselves. Quantum-resistant algorithms such as ML-DSA have larger public keys and digital signatures than traditional public-key cryptographic algorithms, which directly increases certificate chain transfer volume and data overhead during TLS handshakes. This size expansion further increases deployment pressure in highly concurrent websites, low-latency services, and mobile network scenarios.
F5 also noted that Cloudflare’s automatic key exchange mechanism plays a key role in its enabled environments, and that its main deployed PQC combination is X25519MLKEM768. This shows that the spread of web PQC is currently more a result of platform-level spillover than of independent transformation by individual websites.
Looking at regional distribution, F5 Labs classified sites by the location of their corporate headquarters and found that Taiwan had 88 PQC-supporting sites out of 230 samples, for an adoption rate of 38.26%, higher than Japan’s 29.69% and South Korea’s 29.08%. This indicates that although Asia-Pacific has already shown clear signs of adoption, maturity still varies across markets.
By industry, the technology sector’s PQC adoption rate reached 56.1%, clearly ahead of the roughly 35% levels seen in government agencies, telecommunications, and oil and gas. This suggests that industries with higher levels of cloud adoption and greater external service density are generally more likely to introduce new cryptographic mechanisms first.
In contrast, critical infrastructure-related industries are progressing more slowly, due not only to the technology itself but also to large amounts of legacy OT systems, SCADA systems isolated from external networks, and equipment procurement cycles that may last decades. These conditions make PQC transformation not just a software update, but a long-term project affecting architecture, compatibility, and lifecycle management.
F5’s research recommends that enterprises first inventory the algorithms, key lengths, cipher suites, digital certificates, and protocol versions currently in use, so they can identify which systems are already ready for PQC transition and which still rely on traditional mechanisms. This inventory can serve as the basis for later upgrades and compatibility validation.
In practice, priority should be given to high-risk connections and externally facing service endpoints, especially systems whose TLS termination is handled by CDNs or edge platforms. If a platform already supports PQC key exchange, it should be confirmed whether it is enabled by default, and whether negotiation behavior is consistent between the frontend, origin, and intermediary devices.
For environments that still need to maintain traditional compatibility, a hybrid deployment and validation window should be reserved to avoid connection failures or certificate chain compatibility issues caused by a one-time switch. Especially in scenarios where certificates, TLS handshakes, and intermediary devices coexist, testing must be completed before expanding deployment gradually.
For government, telecommunications, and industrial control-related organizations, PQC should not be viewed only as a cryptographic upgrade, but as part of supply chain and asset lifecycle management. The earlier organizations complete asset inventory, dependency mapping, and platform compatibility checks, the more they can reduce the risks and costs of a full future transition.