Exec Summary
There is a growing disconnect between the rapid pace of advancements in quantum computing and the priority to which CISOs assign to the associated risk. Recent predictions now estimate the arrival of Q-Day (the date when quantum computers become powerful enough to break widely used public key cryptography) to be as early as 2029. Yet, according to the ISACA Pulse of Quantum Computing poll, only 5% of CISOs say that post-quantum cryptography (PQC) is a ‘high business priority’ for the near future.1 This report evaluates the current state of PQC adoption among the world’s top 1 million websites and the most commonly used web browsers and devices.
Among the top one million websites, only 8.6% support hybrid PQC key exchange mechanisms. This reflects a broad hesitancy to transition and, more worryingly, 25% of websites still do not support TLS 1.3 at all, with 16% failing to implement quantum-resistant symmetric ciphers. Conversely, PQC adoption is more visible among the world’s most popular sites, with 42% of the top 100 supporting it, though this figure drops to 26% for ranks 100–200, and averages just 21.9% across the top 1,000. Support falls further to 13.9% for the top 10,000 sites and 8.4% for the top 100,000.
The uptake of PQC is particularly low in some of the most security-sensitive sectors. Only 3% of banking websites support PQC, placing the industry among the lowest adopters—even within its own Financials sector (Figure 1). Healthcare and government websites are also lagging.
Websites that support post-quantum cryptography (PQC) tend to have stronger overall TLS configurations, offering fewer and more modern cipher suites while disabling outdated protocols like SSLv3 and TLSv1.0. Those with PQC enabled offered significantly fewer cipher suites (suggesting deliberate hardening) compared to non-PQC sites which still commonly support weak and obsolete protocols. This contrast highlights PQC support as a strong proxy for broader cryptographic hygiene.
Geographically, TLD analysis shows that countries like Australia (.au), Canada (.ca), and the UK (.uk) are leading in PQC deployment when considering both adoption rate and volume. However, when company headquarters are considered, the United States stands out as the global frontrunner, with the UK, Canada, and Australia following closely.
On the client side, browser support plays a major role in overall PQC readiness. While 93% of Chrome requests are PQC-ready, Safari’s lack of support reduces the global readiness rate to just 57%. Firefox, despite accounting for only 2% of requests, sees 85% of its traffic coming from PQC-capable versions.
The data suggest that while technical capability for PQC adoption exists—especially given the widespread use of TLS 1.3—the practical rollout is lagging in many critical areas. For organizations with data that must remain confidential well into the future, failing to deploy PQC measures today may already be too late.
Figure 1: Proportion of PQC-enabled sites per business sector
Introduction
No one knows exactly when Q-day will arrive but recent advancements have seen the estimated number of Q-bits required to crack traditional encryption plummet from 1 billion in 2012, to 20 million in 2019, to just 1 million as of May 2025.1 Since Google is now predicting that sufficiently powerful quantum computers may be here by 2030, it may already be too late for many organizations to deploy post-quantum cryptography (PQC) to protect their web applications.
While this report focuses specifically on the web’s use of encryption, it’s important to acknowledge that quantum computing threatens far more than just websites. The eventual arrival of a cryptographically relevant quantum computer will impact nearly every domain that relies on public-key cryptography: from disk and device encryption, to secure email and document signing, to remote access protocols like SSH, and even end-to-end encrypted messaging apps. However, this report deliberately keep its scope narrow, concentrating on the most visible and scannable frontier of cryptographic deployment: the public web. |
Quantum Computing Has Already Broken Cryptography (sort of)
As of writing this report, despite some claims overstating their progress, quantum computing has not broken traditional cryptography.2 Researchers all over the world, however, can very much see the light at the end of encrypted tunnel.
So why claim that quantum computing has already broken cryptography? Because this is a one-sided race and you are at a distinct disadvantage.
You are competing in a race against a time-traveller who can go back in time and set off before the starting gun has even fired.
What is Cover Time and Why Does It Matter?
Encryption has always played a big part in the ‘data lifecycle’ and yet, while an organization’s data lifecycle may consider when the data itself may no longer needed, rarely are the lifespans of cryptographic primitives considered. Even before Q-Day became a looming threat, cryptographers considered how long any given cipher or key length would provide adequate security. Until recently, the longevity of traditional cryptographic ciphers has been focused on key length. The bigger the key, the longer it provides protection.
The now defunct website keylength.com compares global encryption standards from the likes of NIST and BSI and allows visitors to view the recommended key length for any given cover time. To ensure that data is secured and safe from decryption, NIST, for example, recommends a RSA key length of 2024 bits (2K) to protect data until 2025, but should you want protection until 2050, a 7680 bit (7K) RSA key is recommended. Similar increases are recommended for elliptic curve cryptography (ECC) and cryptographic hashes. |
Although many organizations have not historically accounted for the cover time of their encrypted data, Q-Day is a wake-up call. The newly popularized threat vector is known as ‘harvest now, decrypt later’ which conveys the risk rather more succinctly than ‘cover time’.
With some experts now forecasting that quantum computers could decrypt today’s encrypted internet traffic by 2030, nearly everything transmitted over the web today could be vulnerable to retrospective decryption in just over five years.
If you have data with a cover time of 5 years or more, you should assume that it’s already lost to your adversaries.
When Should I Deploy PQC?
The latest date at which you should been deploying PQC ciphers is determined by the simple formula:
PQC Deployment Date = Q-Day – Cover Time
If you assume Q-day as 2030 and a cover time of 5 years then the latest you should be deploying PQC to protect from harvest now, decrypt later, is 2025. And that’s assuming adversaries have not already begun to harvest the data.
RSA, ECDHE, DSA, and ECDSA Will Be Broken
We last wrote about How Quantum Computing Will Change Browser Encryption in 2017, and this is still an excellent read for those wanting a deeper understanding on how quantum computers will affect TLS. Figure 2, taken from that article, explains the components of the TLS protocol which quantum computing threaten most directly.
Figure 2: Quantum computing exposure of the TLS protocol
The security of traditional cryptography, such as the RSA and Diffie-Hellman, is based on the complexity of solving mathematical problems. Problems that are close to impossible to solve with traditional digital computers. Quantum computers, however, make these problems trivial to solve, thereby allowing adversaries to easily find the large secret numbers that form the basis of cryptographic keys.
All current public-key algorithms and digital signatures such RSA, DH, RSA (i.e. the components marked ‘unsafe’ in Figure 2) are believed to be broken in a post-quantum world.
TLS 1.2 is No Longer Secure
Beyond the cryptographic algorithms themselves, all TLS protocols earlier than TLS 1.3 are inherently vulnerable since they allow the use of very old and very broken ciphers. More specifically to a post-quantum world, however, earlier versions of TLS have no mechanism with which to support PQC and hybrid ciphers.
For that simple reason, TLS 1.2 should be considered legacy, weak, and deprecated.
The State of Post-Quantum Cryptography (PQC)
As of this report, PQC support has been codified in new NIST standards and is gradually being adopted across browsers, web servers, application delivery controllers, and SaaS platforms (including CDNs). Although these algorithms are now formally defined, adoption on the web must proceed cautiously to maintain compatibility with legacy infrastructure. While modern browsers and up-to-date web servers can readily support PQC ciphers, many older hardware and software systems cannot. To address this, a hybrid deployment strategy has been adopted. Rather than switching immediately to PQC-only ciphers, servers and clients are implementing PQC alongside classical algorithms, allowing secure fallback to traditional cryptographic standards when one side lacks PQC support.
When assessing the quantum risk to TLS, it’s important to distinguish between two components:
- Key exchange, which determines the encryption keys used in a session
- Authentication, which verifies the server (and optionally the client using mTLS) via digital signatures
Due to the “harvest now, decrypt later” threat model it is vital to implement post-quantum KEMs as soon as possible.
By contrast, digital signatures used for authentication in TLS must be verified in real time during the handshake. If they are not broken during the session, they cannot be retroactively forged. Therefore, the risk posed by classical signatures (e.g., RSA, ECDSA) is that quantum computers in the future will allow new certificates to be forged, but not past ones.
For this reason, much of this report focuses on the rollout of post-quantum key exchange support, but we will also briefly evaluate the preparedness of certificate authorities.
What are the PQC Standards?
In 2016, the U.S. National Institute of Standards and Technology (NIST) launched a multi-year competition to evaluate and standardize quantum-resistant cryptographic algorithms. After an extensive review process involving academic and industry experts worldwide, NIST announced its first selections in 2022. For general encryption, NIST selected CRYSTALS-Kyber and for digital signatures, it chose CRYSTALS-Dilithium, FALCON, and SPHINCS+. These algorithms were chosen for their strong security proofs, performance, and suitability for integration into modern systems.
As of August 2024, NIST has cemented the use of these PQC algorithms in three new standards.1
FIPS 203 defines the standard for encryption, which keeps data private during transmission. The chosen algorithm, CRYTALS-Kyber, has been renamed ML-KEM and comes in three flavors of increasing security: ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
FIPS 204 defines the standard for digital signatures, which provide the ability to detect tampering (non-repudiation). It is based on CRYSTALS-Dilithium algorithm and has been renamed ML-DSA.
FIPS 205 is an additional standard for digital signatures that is based on a different class of algorithm than ML-DSA. Originally known as SPHINCS+, it is now standardized as SLH-DSA. This provides a valuable fallback option: if a fundamental flaw is ever discovered in ML-DSA, the industry can quickly transition to SLH-DSA as a backup.
The integration of these post-quantum algorithms into mainstream protocols is already underway. The most notable example is the inclusion of hybrid key exchange support in TLS 1.3 and supported by some leading web servers, application delivery controllers, and SaaS platforms.
What is KEM?
KEM stands for Key Encapsulation Mechanism.
For those familiar with TLS, this may be a new acronym and a new concept to understand.
TLS has always required two forms of encryption: symmetric and asymmetric (also known as public key encryption). Symmetric cryptography secures the actual data exchanged between two parties, while the asymmetric component is used to securely negotiate the symmetric key used for that encryption.
Historically, TLS has relied on two methods for asymmetric key negotiation:
- Key exchange, where one party generates and securely transmits the key (e.g., RSA key exchange)
- Key agreement, where both parties contribute to the final key (e.g., Diffie-Hellman and Elliptic Curve Diffie-Hellman)
Key encapsulation mechanisms (KEMs) are increasingly used in TLS as part of post-quantum cryptographic transitions. While not new to cryptography, KEMs represent a new model for key exchange in TLS, replacing traditional methods like RSA and Diffie-Hellman in hybrid and post-quantum cipher suites.
They are essential in hybrid cipher suites, which combine classical algorithms with post-quantum algorithms to provide security against both classical and quantum adversaries. In these hybrid schemes, KEMs allow a shared key to be derived securely from multiple components (e.g., an elliptic curve DH exchange and a post-quantum KEM like Kyber or ML-KEM).
What Happens When Q-Day Arrives?
Q-Day is inevitable.
What is less certain is how threat groups will look to weaponize this new technology. Even by 2030, it is extremely unlikely that the technology will have reached the practicality and affordability of all but the world’s largest nation-states and wealthiest companies.
In addition to the huge cost for acquiring and maintaining the technology, there will also be a requirement for skilled engineers, not to mention the time needed to perform calculations.
In May 2025, Google Quantum AI reported a breakthrough in the practicality of breaking RSA-2048 encryption using quantum computing.2 Previous estimates, such as a 2021 study by Gidney and Ekerå, suggested that factoring a 2048-bit RSA key would require around 20 million noisy qubits and about eight hours of runtime.3 Thanks to recent improvements in quantum algorithms—specifically in modular exponentiation—and advances in quantum error correction, Google’s latest analysis shows that the same task could now be completed with roughly one million noisy qubits, reducing the hardware requirement by a factor of 20. Although this leaner design increases runtime, the report estimates the computation could still be finished in under one week of continuous operation. These improvements reflect not just better quantum hardware, but more efficient organization of quantum circuits, making quantum factoring significantly more accessible.
When Q-Day finally arrives, decryption of previously intercepted data is unlikely to occur en masse overnight. Instead, well-resourced nation-states will begin selectively decrypting sensitive communications they have harvested over the years. While the web’s encryption may not immediately collapse, what will be lost instantly is trust. From that moment on, no one will be able to guarantee that encrypted data—past or present—remains confidential.
A more immediate and damaging threat will be the ability of quantum-capable adversaries to forge digital signatures, including those used in TLS certificates and code signing. Algorithms like ECDSA and RSA, which currently underpin authentication on the web, will become practically breakable. If the internet has not widely transitioned to post-quantum cryptographic certificates—or at least hybrid alternatives—by the time this capability is realized, it will no longer be possible to trust the authenticity of websites, APIs, or software updates. The cryptographic foundations of digital trust will have eroded, even if the collapse isn’t visible at first.
The State of Post-Quantum Cryptography (PQC) on the Web
We partnered with Efflux to scan the TLS configurations of the web’s most popular sites, as defined by Majestic.4 We made multiple attempts to connect to the default HTTPS port for the root domain of each site, following redirects where possible.
Let’s dive into the results.
Who is Ready for Q-Day?
Of the 1 million sites we attempted to connect to, 843,584 completed a successful TLS handshake. Of those, 72,613 completed a successful hybrid-PQC handshake. From here on in, when calculating percentages for this report, we will calculate the proportion of sites from 843,584 (not 1 million). Any reference to proportions of the top 1 million sites, will in fact be based on calculations out of 843,584.
The highest rank for a PQC enabled site was 1, which should come as a surprise to no one. Google held the top spot and, as a long-time proponent of PQC, it was no surprise to see a successful PQC handshake. Perhaps more surprising was the position for the lowest ranked PQC enabled site: 1,000,000. As we explore later, we have found that many small organizations and websites are benefitting from the security features offered by CDNs and online stores such as Fastly and Shopify, including their early adoption of PQC ciphers.
8.6% of the top 1 million sites completed a successful hybrid-PQC TLS connection
One million (well, 843,584) is a large number, as you can appreciate, and so the mean value of successful PQC handshake is dragged way down towards the bottom of the list. Things look very positive at the higher end of 1 million, with the more popular sites on the internet bringing up the average for the top 10 and top 100, as the data show in Table 1.
| Rank Threshold | PQC Support |
| Top 10 | 50.0% |
| Top 100 | 43.8% |
| Top 1000 | 23.1% |
| Top 10,000 | 15.0% |
| Top 100,000 | 9.3% |
| Top 1,000,000 | 8.6% |
Figure 3 provides a visualisation of Table 1, showing how quickly average PQC support drops as we make our way down the list of top 1 million sites. Note the logarithmic scale of the x-axis and the maximum value of 50% on the y-axis.
Figure 3: Percentage of sites across the top 1M which support PQC (logarithmic scale)
Some of the sites in the top 100 which allowed PQC include facebook.com, Instagram.com pinterest.com, vimeo.com, whatsapp.com, github.io, reddit.com, cnn.com and bbc.com.
Sites in the top 100 which did now allow PQC included twitter.com, linkedin.com, microsoft.com, apple.com, and baidu.com
The proportion of PQC support is also represented as histogram Figure 4. Note: for clarity and simplicity, only the top 10,000 sites are shown, with a bin size of 500.
Figure 4: Percentage PQC support per 500 sites across the top 10,000
PQC Adoption by Platform
As of writing, there are a very limited number of ways to deploy and host hybrid-PQC enabled web sites.
CDN provider Cloudflare offers hybrid-PQC support by default using a single hybrid cipher: X25519+ML-KEM768.
At the time of writing, F5’s BIG-IP supports an early draft of ML-KEM (X25519Kyber768Draft00) although this version is not compatible with the final specification. F5’s Nginx Plus R33 does support the final ML-KEM768 spec, although users must enable this manually in the configuration.1 This version of Nginx Plus also support all ciphers and algorithms as defined by the Open Quantum Safe (OQS) project.2
Users of the Apache webserver can enable the same OQS ciphers, although Apache must be compiled against OpenSSL 3.2+, the oqs-provider library and elliptic-curves must be manually installed, and then the configuration changed.
Squarespace, Github, and Flywheel also offer PQC enabled TLS connections for their static and templated websites. However, businesses looking to create and host truly bespoke applications have more limited options with the top choices being Cloudflare or Nginx (Figure 5).
Figure 5: Number of domains which support PQC and have an identifiable ‘server’ value in their HTTP response
PQC Adoption by Industry
Each industry manages distinct types of data, each with its own set of risks. Determining the cover-time, as part of data lifecycle management, is essential in scenarios where data confidentiality has long-term value, such as:
- Intellectual property (e.g., trade secrets)
- Personal data under data protection regulations (e.g., GDPR)
- Classified government or military information
- Medical records and legal evidence
- Financial transaction logs and payment card details
Finance, healthcare, government, and critical infrastructure are often cited as the industries that handle the most secret and most sensitive data. It is surprising, then, to find them ranking worst for PQC support on their public websites (see Figure 6).
Figure 6: Proportion of PQC support among company sectors
Around 8.5% of Healthcare sites in the top 1M support PQC. That drops to 7.7% for Financials, and 7.1% for Government.
Banking stands out as a surprisingly weak adopter of PQC, with just 4 out of 145 identified banks (2.9%) supporting post-quantum ciphers.
Industry breakdown and the data for Figure 6 can be found in the Appendix.
PQC Adoption by Region
To ascertain whether there is a discernable difference in attitudes to PQC over the world, we wanted to compare PQC adoption by country and region. We use both top-level domain (TLD) and company head-quarter locations to evaluate regional differences.
By Top-Level Domain
Since IP addresses mean very little when it comes to geolocation due to the widespread use of technologies such as CDNs and SaaS security platforms, we have used TLD codes as a very loose approximation of countries. This has many problems (not least because of the widespread use of .com) so please consider this when evaluating the following results.
Limiting analysis to top-level domains (TLDs) which have at least 100 sites, a few conclusions can be drawn from the visual representation of the bubble plot in Figure 7.
High-volume TLDs like .com, .org, and .net have relatively low PQC adoption rates:
- .com has 468,253 sites but has only 9.86% PQC adoption
- .org has 86,978 and just 8.65% adoption
- .net has 30,380 sites and only 3.84% adoption
Smaller TLDs like .au, .nz, and .dev lead in PQC adoption rates
- .au has the highest PQC adoption among high-volume TLDs at 17.38%.
- .nz follows closely with 17.06%, and .dev has 15.69%.
European ccTLDs show cautious adoption
- .de (Germany) = 2.09%
- .fr (France) = 3.74%
- .nl (Netherlands) = 4.44%
- .se, .es, .be, .ch, etc. all range between 3% and 5%
Figure 7: PQC adoption of the top 1M sites as percentage per TLD
Further data is available in Table 6 (see Appendix).
By Country (HQ location)
Performing lookups on each domain to determine the location of their company’s headquarters provides another, perhaps more realistic, view of the global opinions of PQC support. We used BigPicture.io to lookup the top 100,000 sites, the results of which are shown in Figure 8.
Figure 8: PQC adoption as a percentage of all websites for each country (based on HQ location)
Some countries stand out in the data. The United States of America, the United Kingdom, and Canada, all have a significant number of sites in the top 1M (1,000 or over) along with an above-average rate of adoption (10% or higher).
Figure 9: Graphical representation of PQC adoption per country (based on HQ location)
PQC Cipher Usage
Come 2030, NIST recommends that we are using PQC ciphers exclusively. By then, all TLS 1.3 handshakes should be dealt with entirely by ML-KEM and ML-DSA. But if PQC ciphers have been approved and ratified into new FIPS standards, why not move to them immediately?
What are Hybrid Ciphers and Why Do We Need Them?
Cryptographers use mathematical proofs to ensure that ciphers are secure, but many flaws and vulnerabilities with TLS come not from the algorithms themselves, but from the implementation of them. There is some debate over how to categorize TLS vulnerabilities, but we consider only two of the biggest 16 TLS vulnerabilities (Logjam and ROBOT) to be inherent cipher (or key size) problems. Seven vulnerabilities were due to oversights in the TLS specifications, and five were vendor implementation mistakes.
We’ve learnt that it takes time, requiring many researchers poking and prodding, to discover weaknesses. PQC ciphers are simply too new, so while the ciphers are provably secure, we don’t yet have enough trust in the implementation of them.
Through the wonder of mathematics, however, we can benefit from future proof quantum-resistant PQC ciphers while also enjoying the tried and trusted security of traditional ciphers. Using key derivation functions (KDFs) we can combine the keys created by ML-KEM and an elliptic-curve (such as x25519) in to one ‘larger’ key which has the security properties of both.
KFinal = KDF(KTrad. || KPQC)
Two keys (KTrad and KPQC) are created and then ‘mixed’ together. As long as either key is generated in a secure way, the entire resulting key KFinal is secure. If ML-KEM is discovered to be insecure, the ECHDE component keeps the entire key secure. Similarly, once Q-Day arrives, the ML-KEM component ensures that the overall key is still safe.
PQC (Hybrid) Cipher Adoption
The Open Quantum Safe project provides quantum safe cipher support to OpenSSL 3.x.1 Many key encapsulation (KEM) algorithms are supported. In our scan of the top 1M sites, we attempted to perform a handshake using each of them:
- BIKE: bikel1, p256_bikel1, x25519_bikel1, bikel3, p384_bikel3, x448_bikel3, bikel5, p521_bikel5
- FrodoKEM: frodo640aes, p256_frodo640aes, x25519_frodo640aes, frodo640shake, p256_frodo640shake, x25519_frodo640shake, frodo976aes, p384_frodo976aes, x448_frodo976aes, frodo976shake, p384_frodo976shake, x448_frodo976shake, frodo1344aes, p521_frodo1344aes, frodo1344shake, p521_frodo1344shake
- ML-KEM: mlkem512, p256_mlkem512, x25519_mlkem512, mlkem768, p384_mlkem768, x448_mlkem768, X25519MLKEM768, SecP256r1MLKEM768, mlkem1024, p521_mlkem1024, SecP384r1MLKEM1024
Now that NIST has standardized on ML-KEM we expected to see very little else deployed on the web, and our suspicions were largely met. Every single hybrid-PQC HTTPS server used ML-KEM768, save for three, which used ML-KEM1024. Virtually every site combined ML-KEM768 with the X25519 elliptic-curve, with only five websites making use of different ECC algorithms.
| Hybrid-PQC Cipher | Count |
| X25519MLKEM768 | 72608 |
| p521_mlkem1024 | 3 |
| SecP256r1MLKEM768 | 2 |
PQC Websites vs non-PQC Websites
Maintaining a strong cryptographic posture often has more to do with disabling old and weak configurations than enabling the latest and greatest features, and TLS configuration can be a strong indicator of overall application security strategy. Websites that still accept SSLv3, TLSv1.0, or weak ciphers, often lack in other aspects, such as permitting weak and default passwords, failing to deploy web application firewalls, and lack a robust patching strategy.
Cipher Suites
After examining the top 1 million sites, we found that PQC enabled sites offered significantly fewer cipher suites than those that did not (Figure 10).
Figure 10: Number of cipher suites offered by PQC and non-PQC websites
The maximum number of cipher suites offered by a PQC site was 56, compared to 78 offered by non-PQC sites. This strongly suggests that sites which have enabled TLS 1.3 and hybrid-PQC ciphers have also made efforts to disable old protocols and ciphers.
| As a reminder to readers, the boxed area spans from the first quartile (Q1) to the third quartile (Q3), encompassing the middle 50% of the data. The line inside the box represents the median (Q2), the middle value of the dataset. The whiskers (lines extending from the box to the minimum and maximum values, excluding outliers) indicate the range of the data. Individual data points plotted as dots beyond the whiskers, represent values that fall outside the typical range. |
TLS Versions
Looking closely at the protocols used to offer the various cipher suites, we seen an even bigger disparity between PQC and non-PQC enabled sites (see Figure 11).
Very few PQC enabled sites still support TLSv1.1 and v1.0 (3.1% and 3% respectively). Many non-PQC enabled sites still offer these legacy protocols with, shockingly, a non-zero number still allowing SSLv3 connections (TLSv1.1 sits at 37.3%, v1.0 at 34.5%, with SSLv3 sitting at 0.6%)
Figure 11: Protocol support by PQC status
Getting PQC Ready
Strong PQC strength will rely upon more than just the quantum-resistant asymmetric ciphers themselves. TLS 1.3 support is a must, as are strong symmetric ciphers.
Strong Symmetric Encryption
While quantum computers pose the most significant threat to asymmetric encryption (public key cryptography) they also promise to impact symmetric encryption. The current advise is that doubling the key length will provide sufficient protection for the foreseeable future. If you are currently using AES-128 as your symmetric cipher, this should be increased to AES-256.
| Symmetric Cipher | Percentage of top 1M which prefer this cipher |
| AES_256 | 81.31% |
| CHACHA20 | 2.28% |
| Unsafe ciphers | 16.41% |
The good news is that the majority of the world’s most popular sites already use a symmetric cipher and key size that is believed to be quantum resistant. On top of AES-256, CHACHAT20 also makes use of a 256-bit key. But it’s not all good news.
Almost 16.5% of the most popular sites are not currently using a safe symmetric cipher.
Doubling the key size will have some impact on performance though, with today’s compute power and AES acceleration often performed in hardware, only the lowest powered and IoT devices should notice any performance impact.
TLS 1.3 Support
Before a TLS connection can even attempt to make use of PQC ciphers, it must already be using the latest version of the protocol.
TLS 1.3 is almost five years old, having been finalized in RFC 8446 in August 2018.1 This latest version of SSL/TLS brought with it a few important upgrades to older versions of the standard. Namely, a simplified and modernized key agreement (removing the insecure RSA key exchange), forward secrecy to prevent bulk ‘harvest now, decrypt later’ attacks, and formal security guarantees.
Most importantly, however, it provided extension support for hybrid key exchanges thanks its extensible key share mechanism (EKM) and standards such as the draft RFC 9180: Hybrid Public Key Encryption (HPKE).2
- HPKE combines:
- A KEM (for key exchange),
- A Key Derivation Function (KDF),
- And an Authenticated Encryption with Associated Data (AEAD) algorithm (for encrypting the payload).
- It supports one-way, public-key encryption suitable for scenarios where the recipient’s public key is known, but no secure channel is yet established.
- Modes: HPKE defines several use modes, including base, PSK (pre-shared key), authenticated, and authenticated with PSK.
- Flexibility: You can swap out different KEMs (e.g., X25519, Kyber), KDFs (e.g., HKDF), and AEADs (e.g., AES-GCM, ChaCha20-Poly1305) based on the security needs.
All that to say, that TLS 1.3 is required to support PQC and hybrid-PQC TLS connections.
The world’s top sites perform reasonably well, with 71.3% rate of TLS 1.3 preference across the entire ‘million’. The world’s top 10 claim a perfect 100% rate of adoption, but we don’t have to climb down very far from the top to see our first site which only supports TLS1.2. The site at rank 34 supports only TLS 1.2, as do many others in the top 100 (see Figure 12).
Figure 12: Rolling average rate of TLS 1.3 preference across the world’ top 1 million sites
Rolling averages across a rapidly increasing data set can easily hide the nuance in the data, however. In fact, Figure 12 perfectly hides the worrying trend in the data among the web’s most very popular sites. We visualize the same data in the dual histogram plots in Figure 13 (note the logarithmic y-axis).
The websites at the very top of the global ranks drag up the average for those in the top 1,00, but beyond, that we see many popular sites preferring TLS 1.2. In fact, the average for TLS 1.2 preference is higher among the top 50,000 sites than it is for the bottom 50,000 websites (Figure 13).
Figure 13: Histogram (logarithmic y-axis) the distribution of TLS version preference across the top 1M site
In fact, sites in the top 10,000 are the worst offenders for poor TLS 1.3 support. This suggests that the world’s top sites are likely deploying their own infrastructure but struggling to keep up with patching and maintenance of those systems. Smaller organizations are more likely to adopt a web hosting or SaaS platform, which affords them all the security controls that platform has.
| Web site rank bin | 1 – 1000 | 1001 – 2000 | 2001 – 3000 | 3001 – 4000 | 4001 – 5000 |
| TLS 1.3 Preference | 78.9% | 75.9% | 77.6% | 77.6% | 76.7% |
Virtually all modern platforms and TLS stacks support TLS 1.3. Unsupported versions are shown in Table 7 in Appendix. A more rigorous protocol analysis (including an inspection of those worrying SSLv3 websites) will be given in later research.
Web Browser PQC Support
This analysis explores PQC readiness across browser-based web traffic by examining user-agent data from F5’s Distributed Cloud. We analyzed almost 13 Billion transactions and focused on real human traffic, excluding transactions identified as bots and other forms of automation. We also excluded traffic from custom mobile apps due to the complications in determining client-side support of specific ciphers. Rather than measuring unique users, the data reflects total transaction volume, meaning high-frequency users have a proportionally greater influence on results. While not ideal for measuring broad user awareness, this method offers insights into the real-world adoption of PQC-capable client adoption in the real world.
After removing mobile app connections and bot traffic, we found that 57.4% of all browser-based transactions are PQC-ready, meaning they originate from browsers that support hybrid post-quantum key exchange by default. Google Chrome is the primary driver of PQC adoption, accounting for 59% of all connections. However, 93% of those connections came from version 131 or later—when PQC support was enabled by default. Firefox, though only representing 2.4% of traffic, shows strong alignment with modern cryptography standards: 85% of its connections are PQC-ready.
Safari on MacOS and iOS, and all iOS-based browsers, are currently major factors preventing PQC wider adoption. Since iOS does not yet support PQC ciphers (and all popular iOS browsers use the iOS TLS libraries) no iPhone or iPad user will currently be able to benefit from quantum safe encryption. Accounting for 38% of all connections in the data it significantly drags down overall readiness. Safari’s lack of PQC capability—despite Apple’s influence over large iOS and macOS user bases—underscores a major gap in ecosystem-wide adoption.
Outdated browsers on non-Apple devices (e.g. older versions of Chrome on Windows) accounted for 4.56% of all connection requests.
Figure 14: Distribution of web transactions by browser and platform
PQC Certificate Digital Signatures
As we noted earlier, quantum computers will provide the ability to forge digital certificates which make use of classical algorithms, such as ECDSA. While some certificate authorities (CAs) are experimenting with the creation of hybrid certificates and some hardware security modules (HSMs) do offer support for PQC certs, they are significantly further from seeing mass market adoption than hybrid public-key key exchange mechanisms.
Let’s Encrypt, still the world’s most popular CA (accounting for 42.5% of all certificates observed in our scan) currently has no plans announced with regard to PQC or hybrid-PQC certificates (see Figure 15).
Figure 15: Top 10 Certificate Issuers
Future F5 Labs research will monitor the state of digital certificates and web’s progress towards adopting them.
Conclusions
This report it highlights a critical and growing risk: while quantum computers capable of breaking today’s encryption are not yet available, adoption of post-quantum cryptograph is slow with Q-day as little as five years away. All businesses, particularly those dealing with intellectual property, healthcare records, financial transactions, or national security-related information could already be at risk—even if that data remains secure for now.
There is also increasing regulatory and policy momentum. The U.S. National Institute of Standards and Technology (NIST) has finalized its PQC standardization process, and government agencies such as the NSA have begun mandating post-quantum readiness for organizations in their supply chains. As these standards trickle down, commercial sectors will likely be required—or strongly expected—to follow suit.
Beyond technical compliance, encryption is a trust signal. Falling behind on the transition to post-quantum-safe encryption risks damaging a company’s reputation with customers, investors, and partners who are increasingly alert to cybersecurity issues. Inaction may be interpreted as complacency or even negligence.
Finally, the transition to a fully PQC web is not trivial. Hybrid-PQC deployments offer a practical stepping stone, but organizations need time to test, plan, and implement these changes properly. Delaying this work risks increased costs, rushed migrations, and potentially insecure implementations down the line. Starting now is a strategic investment in future-proofing data security.
Recommendations
For those applications already delivered by a CDN, SaaS, or ADC platform which maintains up to date ciphers and standards, enabling hybrid-PQC may be as easy an enabling a configuration option. Other organizations will need to quickly determine their exposure and evaluate this against the risk appetite of the business, as well as any regulation their industry may soon impose.
The most advise for organizations wishing to adopt PQC support as soon as possible, is to ensure that you are making use of application delivery and security platform (ADSP) which supports TLS 1.3 and the PQC, including hybrid-PQC ciphers.
More comprehensively, consider the following 5-step plan to evaluate the current state of TLS cryptography across the business:
1. Discovery
- Create an inventory of cryptographic configs, including TLS versions enabled and cipher suites used
- Ensure that APIs as well as applications (both internal and external) are evaluated
- Factor in what cryptographic hardware offload you have and the impact that hybrid PQC may have
2. Evaluate Risk
- Understand data policies that exist across the business and how they define the data lifecycle, including cover time
- Consider legal and regulatory compliance regarding how long data must be held and kept secure
3. Adopt Crypto Agility
- Where possible, plan to decouple TLS and cryptographic operations from applications and move them to dedicated infrastructure, such as ADCs or CDNs.
- Ensure that the platform you chose can rapidly adopt new TLS protocols and cipher suites and allow for easy config change without disruption to the application or business
4. Define Migration Strategy
- Determine timelines for high- vs. low-risk systems
- Plan hybrid deployments where necessary to ensure backward compatibility.
5. Educate and Train Teams
- Provide training for engineers and architects on PQC concepts and migration strategies.
- Raise awareness among leadership about the importance of quantum readiness.
- Periodically review new PQC standards, attacks, and performance improvements.
Figure 16: Industry support of PQC ciphers
