2026 State of PQC on the Web

Relevant solutions

BIG-IP Local Traffic Manager

BIG-IP SSL Orchestrator

NGINX Plus and Open Source

NGINX Ingress Controller

NGINX Gateway Fabric

Introduction

Welcome to the 2026 State of Post-Quantum Cryptography (PQC) Report. As the threat of cryptographically relevant quantum computers (CRQCs) moves from theoretical physics to a tangible operational risk, organizations worldwide are scrambling to secure their networks. However, public narratives and vendor marketing often obscure the ground truth of this migration. This report cuts through the noise to deliver a purely data-driven assessment of global PQC readiness.

This document provides a comprehensive, empirical analysis of how PQC is actually being deployed across the internet today. We explore:

• Real-World Adoption Metrics: The exact percentages of websites supporting hybrid PQC key exchanges, broken down by industry, geopolitical region, and infrastructure provider.
• The Certificate Bottleneck: The looming operational crisis caused by massive post-quantum digital signatures, the complexities of X.509 composite certificates, and the industry shift toward 47-day automated certificate lifespans.
• Internal Network Risks: The often-ignored architectural impact of PQC on internal service meshes, Kubernetes mTLS payloads, and legacy enterprise dependencies.
• Strategic Roadmaps: Actionable steps to transition from vulnerable legacy protocols to quantum-resistant architectures based on regulatory mandates.

Our findings are derived from a massive, active telemetry scan of the top 1 million domains globally. By initiating TLS 1.3 handshakes, we captured the specific cipher suites, key encapsulation mechanisms (KEMs), and certificate chains presented by each server.

We then cross-referenced the resolved IP addresses with global Autonomous System Number (ASN) databases to isolate the massive influence of Content Delivery Networks (CDNs). Finally, we mapped company domains to their corporate headquarters’ location and industry sectors to reveal the true, organic enterprise adoption rates across the global economy.

For security leaders, this report is designed to serve as a practical, executive-level playbook. You can use this data to:

• Benchmark Your Posture: Compare your organization's post-quantum progress against direct industry peers, high-risk economic sectors, and sovereign national averages.
• Assess Payload and Network Impact: Evaluate how the massive size of post-quantum public keys and signatures will impact your transport layers, helping you prepare internal high-throughput networks for the performance overhead of expanded certificate chains.
• Drive Executive Action: Leverage our concrete data on TLS 1.3 technical debt and the impending 47-day certificate mandate to secure budget for essential public key infrastructure (PKI) automation and network modernization.

Executive Summary

The global transition to post-quantum cryptography (PQC) has officially crossed a major milestone, with 54% of the top 1 million websites now supporting PQC key exchanges. On paper, this is a historic achievement. In reality, very little of this progress is due to organizations taking proactive steps.

True enterprise quantum readiness remains dangerously low. While the public edge is rapidly securing data-in-transit, organizations have barely begun to address the existential cryptographic threats lurking in their internal networks, authentication protocols, and administrative structures. This report evaluates the systemic barriers to genuine post-quantum security and outlines the immediate, highly critical actions required by enterprise security leaders before "Q-Day" arrives.

The primary driver behind the 54% adoption figure is not organic enterprise engineering, but the CDN effect. CDNs and cloud-native hyperscalers (primarily Cloudflare and Fastly) have enabled PQC by default for their customers. This has created a massive, automated spike in adoption that peaks at 80% in the middle ranks of the top 1 million (ranks 80k to 220k), where smaller, agile websites inherit post-quantum security effortlessly.

Conversely, the world's most critical enterprises and high-value domains show significantly poorer adoption. Because these organizations operate complex on-premises environments, custom load balancers, and bespoke TLS configurations, they cannot rely on a simple cloud-based CDN toggle. Consequently, those with the most to lose are currently the furthest behind, trapped by legacy operational technology (OT) debt, manual certificate workflows, and rigid change-control pipelines.

Top 5 Critical Findings for Security Leaders:

The Organic Adoption Myth: The CDN Illusion

Headline statistics suggest that over 54% of the top one million websites are quantum-safe, but this masks a critical infrastructure dependency. When Cloudflare-hosted domains are removed from the dataset, average post-quantum cryptography adoption plummets from 54% down to just 22%. Much of the early progress is not the result of deliberate enterprise migration programs, but rather the passive consequence of routing web traffic through a single content delivery network. Organizations relying solely on edge-provider defaults leave origin servers, internal application tiers, and private API ecosystems completely unmigrated and vulnerable to decryption.

Technical Debt Stalls Agility

Post-quantum readiness demands rapid cryptographic agility, yet enterprise environments remain weighed down by legacy operational habits and outdated protocols. Industry standards bodies are pushing leaf certificate lifespans down toward a strict 47-day window, yet 19% of top websites still deploy certificates with lifespans exceeding 90 days. Paired with the fact that 10% of the web still fails to support modern TLS 1.3, this technical debt creates an operational barrier. Organizations that struggle to automate short-lived certificate renewals or deprecate legacy protocol versions will find it nearly impossible to execute the rapid cipher rotations required during the post-quantum transition.

Organizations with the Most to Protect Are the Least Prepared

The economic sectors safeguarding the most sensitive, long-lived data assets are lagging behind general commercial adoption. Critical infrastructure and high-value industries post alarmingly low post-quantum success rates: Government sits at only 35%, Oil & Gas at 34%, and Telecommunications at 35%. Crucially, these figures already include the artificial bolstering provided by CDN networks, meaning organic origin readiness is substantially lower. For public sector and critical infrastructure entities whose proprietary operational data, intelligence, and citizen records carry multi-decade confidentiality requirements, this sluggish migration pace invites acute exposure to persistent "Harvest Now, Decrypt Later" campaigns.

The Certificate Bloat Crisis: East-West Traffic at Risk

The transition to post-quantum X.509 certificates introduces unprecedented data bloat into network payloads and computational overheads. Because post-quantum public keys and digital signatures are significantly larger than legacy RSA and ECC keys, certificate chains will expand dramatically. While this overhead will introduce measurable latency across the public web, the operational fallout will be far worse for constrained IoT and OT devices, and busy internal enterprise networks. High-throughput internal east-west traffic, containerized microservices, and database replication links are strictly optimized for sub-millisecond execution and minimal packet overhead. Injecting massive post-quantum certificates into these internal environments threatens to cause severe TCP packet fragmentation, buffer exhaustion, and cascading connection timeouts across mission-critical backend.

Regulatory Mandates Have Rendered "Q-Day" Irrelevant

Debating the precise calendar date when a cryptographically relevant quantum computer will materialize is an executive distraction. The operational deadline has already been set by binding regulatory statutes. U.S. Executive Order 14412 mandates post-quantum implementation for key establishment by 2030 and digital signatures by 2031. Simultaneously, the European Commission and the NIS Cooperation Group’s Coordinated Implementation Roadmap dictate that high-risk use cases and critical infrastructure must fully migrate by 2030, with all remaining commercial systems transitioned by 2035. Compliance audits, contractual obligations, and supply-chain procurement rules will force enterprise migration years before quantum hardware is likely to achieve real-world cryptanalysis.

Why We Need Post Quantum Cryptography

Quantum computers pose two significant threats to the safety of our digital applications:

1. Decryption of data and communications, often referred to as harvest now, decrypt later (HNDL).
2. Forgery of digital signatures, known as trust now, forge later (TNFL).

The most immediate threat facing organizations today is HNDL. Encrypted communications are currently being collected and stored in vast data warehouses. When CRQCs finally arrive, this data will be decrypted within a matter of days. Since much of this data has long-lived privacy requirements (known in cryptographic parlance as "cover time") threat actors know that even if captured data is 5 years old, it will still contain relevant and valuable information, such as intellectual property, long-lived API keys, or sensitive personal information. Secrets intended to be kept for 50 years, or more, would have their effective cover dramatically reduced. So, while CRQCs are not yet here, the risk is very much active today.

While much focus is on HNDL, the even bigger threat of TNFL looms. When CRQCs arrive, they will have the ability to create a digital signature that is indistinguishable from the original. On the web, this could mean an attacker creating a certificate for example.com that is fully trusted by web browsers. Beyond the web, nation-states could create malicious firmware that is trusted by hardware security chips, and malware groups could distribute ransomware signed with a certificate known and trusted by antivirus software. Modern identity systems, from smartcards to FIDO2, rely on public key cryptography. If an identity can be forged at will, all protocols and technologies that place explicit trust in digital signatures will become untrustworthy overnight.

Table 1 summarizes the two attack vectors that today’s ‘classical’ cryptography will face in the near future.

Table 1: Comparing the timescales and impact of HNDL and TNFL attacks

What happens on Q-Day?

Popular narratives often depict Q-Day as an apocalyptic flick of a switch, where every encrypted channel instantly falls and digital trust evaporates overnight. In reality, the operational constraints of early-generation CRQCs will be far more nuanced. Running Shor's algorithm against established asymmetric primitives requires dedicated, fault-tolerant execution across thousands of logical qubits. Breaking an ephemeral elliptic-curve key exchange (such as X25519 or P-256) or factoring an RSA-2048 modulus demands hours to days of sustained quantum processor time per target key. Consequently, an adversary's capability will be severely rate-limited by hardware availability, making indiscriminate, internet-wide decryption computationally impossible on day one.

This physical bottleneck fundamentally shapes the threat from HNDL. While adversaries can store intercepted ciphertexts at negligible cost today, retrospective decryption is strictly linear and non-scalable. Because modern protocols like TLS 1.3, QUIC, and SSH enforce forward secrecy, there is no universal master key to unlock an entire historical archive. Decrypting each harvested connection requires an independent discrete logarithm computation. Even under optimistic hardware assumptions, solving just a few hundred recorded sessions would consume months of dedicated quantum machine time. As a result, early HNDL attacks will not target general web traffic; adversaries will triage their archives, focusing scarce quantum compute exclusively on high-value intelligence, long-term state secrets, and diplomatic communications.

The paper On the Practical Feasibility of Harvest-Now, Decrypt-Later Attacks is recommended reading for those wanting to explore the HNDL threat in more detail.¹

The dynamic changes when assessing TNFL, where the threat shifts from confidentiality to identity impersonation. The quantum resources required to extract a private key from an existing public key match those needed for HNDL, but the downstream payoff is exponentially higher. Once an attacker invests the hours or days necessary to derive the private key of an intermediate Certificate Authority or code-signing root, the quantum computer is no longer needed. The compromised key can then generate millions of forged, fully trusted certificates or authenticated API signatures on commodity classical hardware.

While HNDL represents a slow, targeted erosion of past privacy, TNFL represents an immediate threat to the foundation of web authentication, making certificate agility and compact post-quantum signatures our most urgent defensive priority.

When is Q-Day?

2029.

Well, not quite.

Predicting the exact calendar date of "Q-Day" (the moment a CRQC successfully breaks modern encryption) remains an exercise in probability rather than prophecy. Major hardware manufacturers deliberately avoid pinning down a single date, recognizing that breakthroughs in error correction, logical qubit synthesis, and algorithm optimization make rigid forecasts unsound. Instead, leading figures rely on probabilistic horizons such as Mosca's Theorem, which historically placed a 50% probability of a cryptographic break occurring by the early 2030s. Rather than waiting for an absolute date to arrive, the threat intelligence community focuses on capability thresholds: mathematical optimizations published by Google Quantum AI and academic consortiums have slashed the physical qubit count required to break NIST P-256 and RSA-2048 by more than twenty-fold, significantly accelerating the timeframe in which a state-sponsored machine could pose an existential threat.

This acceleration has created widespread confusion in the media, most notably around the year 2029. Contrary to popular belief, vendors like Google, Cloudflare, and Microsoft have not predicted that Q-Day will happen in 2029. Rather, 2029 represents the industry's self-imposed engineering deadline for complete post-quantum migration readiness. Similarly, while IBM's official roadmap targets the deployment of its landmark fault-tolerant "Starling" system in 2029, its 200 logical qubits will serve commercial research and fall well short of the thousands of logical qubits required to execute Shor's algorithm against enterprise key exchanges. However, the realization that true CRQCs (such as IBM's projected 2,000-logical-qubit "Blue Jay" architecture) are poised to follow in the early to mid-2030s has forced the technology sector to "shift left".

Why Q-Day doesn’t matter

But debating the exact date of Q-Day has become a moot point and overlooks the reality that compliance timelines have already been decided. For US and many global organizations, the transition is a binding legal obligation accelerated by U.S. Executive Order 14412, which mandates the implementation of NIST standards by December 31, 2030, for key establishment and December 31, 2031, for digital signatures.² Crucially, this aligns with the European Commission and NIS Cooperation Group’s Coordinated Implementation Roadmap, which outlines a synchronized transition strategy. The European roadmap mandates that Member States begin active migrations by the end of 2026, fully transition all high-risk systems (such as critical infrastructure, utilities, and financial transactions) no later than 2030, and complete the migration of all remaining systems by 2035.³ With state-sponsored adversaries actively executing HNDL attacks on encrypted traffic today, these regulatory milestones, not the uncertain arrival of Q-Day, represent the true operational deadlines.

What to expect in this report

In this report we focus on the progress being made to prepare for the HNDL and TNFL threat to public websites. We do this by examining TLS and HTTPS configurations of the web’s top 1 million websites. We will examine overall progress in deployment of PQC encryption and X.509 certificates before diving into the industries and regions that are making the most (and least) progress. This report examines the impact that PQC algorithms will have on TLS connections, and we conclude with some recommendations for those who are unsure how to begin their PQC migration journeys.

The State of PQC on the Web in 2026

For our second annual State of PQC on the Web investigation, we once again scanned the web’s top 1 million websites and examined their TLS configuration, DNS records, and HTTP headers. By exploring the adoption across industry and regions, we’re able to uncover the different pace of adoption and pinpoint where critical technical debt creates disproportionate risk for modern organizations.

It has been reassuring to see that, collectively, the web is making significant strides to implementing PQC. At a high level, the increase in PQC paints a positive picture of progress to a quantum-safe web, but looking deeper, we uncovered that the headline numbers mask two critical realities. While year-over-year adoption using identical scanning methodology has effectively doubled from 2025 to 2026, refined scanning techniques reveal an even more dramatic truth: much of this apparent readiness is driven by edge CDNs enabling PQC by default, rather than deliberate, end-to-end enterprise migration.

Overall adoption metrics across the top 1 million sites

This year we have improved our scanning methodology to ensure we collect every possible classical and PQC cipher that a website has to offer. Figure 1 shows the average PQC support across the top 1 million sites and for transparency. This visualization shows results for our legacy scanning method, as well as our new and improved one. Due to the significant difference in scan results, we will keep comparisons to last year at a minimum. All charts and figures after Figure 1 will use only the new 2026 scanning method’s data.

Comparing 2025 and 2026, using our legacy scanning methodology (blue and green, respectively) we see an impressive, albeit expected improvement in PQC. Ranks across the top 1 million saw a 10-20% increase when using the legacy scanning method. What immediately jumped out to us when using our new scans was not just how much more support there appeared to be in ranks 1,000 to 1M, but that counter to our expectations, support actually increased in ranks 10,000 and below (see the orange line in Figure 1).

Figure 1: Comparative progression of PQC adoption across 2025 and 2026, illustrating the impact of baseline scanning methodology (blue) against enriched 2026 scanning capabilities (orange)

Keen to find out why average PQC support appears to increase as we go down in rank, we explored alternative ways to analyze the data. While Figure 1 shows the rolling average (mean) for all sites as we work down through the top 1 million side, Figure 2 represents the same data for 2026 using a histogram. This method represents average support only for sites within each bin (grouping). Figure 2 uses bins of 20,000 and uncovers two unexpected details:

First, we see that support for PQC is broadly consist across the entirety of the top 1 million, with around 54% of all sites for (most bins) having PQC support. An immediate question arises: how is it that some of the world’s smallest websites have the same level of support for PQC as some of the biggest sites in the world?

Second, we can clearly see a large spike in PQC support from ranks 80,000 to 200,000 (with a smaller spike in the 600,000 to 620,000 bin).

Figure 2: Volume distribution of post-quantum cryptography adoption across the top 1 million websites, grouped by rank intervals

We first thought of examining which web servers were performing TLS termination. While this can be accurately performed using TLS fingerprinting, this technique usually requires multiple and potentially disruptive TLS handshakes to each server. So, instead, we opted to examine the common platform enumeration (CPE) header for each server, which informs us which technology is used in a web application. Immediately we saw some similarities with a large spike in F5’s NGINX web server around the same ranking as PQC support (see Figure 3). But the match is not perfect, and the similarities drop as we reach the lower ranks of the top 1 million.

Figure 3: Market share proportion of web server technologies across post-quantum cryptography enabled websites, binned by website rank

Organic Adoption vs. CDNs

We moved our investigation to examine IP ranges and autonomous system numbers (ASNs), which would show us if one or a number of hosting providers and CDNs had a part to play, and the results were obvious. We took the histogram we saw in Figure 2 and overlayed PQC-enabled sites that sit behind a Cloudflare IP address. The orange bars in Figure 4 make it clear the impact that Cloudflare has on global PQC support.

Figure 4: Volume distribution of post-quantum cryptography adoption across the top one million websites, comparing total PQC-enabled sites (orange) against those hosted behind Cloudflare (dark blue).

The decision by Cloudflare and other hyperscale Content Delivery Networks (CDNs) to enable Post-Quantum Cryptography (PQC) by default at the edge, no doubt, is a huge benefit and net win for internet security. It does, however, represent a double-edged sword. On the positive side, it accomplishes at scale what decades of security awareness campaigns could not: instantly shielding over half the web’s public ingress against HNDL attacks without requiring millions of website owners to manually patch web servers or update their application delivery and security platforms (ADSPs). However, this convenience comes with potential drawbacks. It obscures underlying technical debt, forces large post-quantum packet payloads (ClientHello/ServerHello expansion) onto unsuspecting clients, and creates operational inertia where organizations defer necessary backend upgrades because their front door appears secure.

For small and mid-sized businesses (SMBs), CDN-led PQC rollout creates a dangerous "accidental security" trap. Because PQC key exchanges are enabled automatically at the CDN edge, SMB IT teams may have no idea PQC is active, what ciphers are being negotiated, or why crypto-agility matters.

Indeed, exploring available and preferred ciphers offered by webservers show just how little configuration is available to the IT and security teams that rely on the CDN.

X25519MLKEM768 Dominates

At some undetermined date in the future, classical cryptography may be dropped entirely, and PQC-only ciphers will exist. While new PQC algorithms have been rigorously tested, they have not had the decades of probing and tweaking that classical ciphers (such as RSA and ECDHE) have endured. To ensure our digital communications remain as secure as possible, the web has adopted a hybrid-PQC model. Instead of clients needing to choose between a classical cipher or a new PQC cipher, most websites implement a hybrid cipher which uses both classical and PQC encryption at the same time. If a threat actor wanted to break a connection secured by hybrid encryption, they would need to break both the classical algorithm and the PQC algorithm simultaneously.

This "defense in depth" is not just a theoretical precaution; the necessity of this model was proved in July 2022 during the spectacular collapse of SIKE (Supersingular Isogeny Key Encapsulation). Highly favored as a post-quantum finalist due to its incredibly compact key sizes, SIKE's underlying mathematics were completely broken by researchers in under an hour.⁴ Crucially, this devastating attack did not require a quantum computer. The keys were recovered using a classical, single-core laptop.

Because almost all currently standardized post-quantum algorithms (such as ML-KEM) rely on a single mathematical family (structured lattices) the industry faces a dangerous cryptographic monoculture. If a similar mathematical shortcut is ever discovered against lattice-based cryptography, a pure PQC web would collapse overnight. By keeping classical ciphers active alongside PQC, hybrid schemes guarantee that if a post-quantum algorithm is suddenly broken classically, the classical elliptic curve still shields the session.

Figure 5: Distribution of preferred post-quantum Key Encapsulation Mechanisms (KEMs) across the top one million websites, grouped by rank intervals.

Web servers, reverse proxies, and application delivery and security platforms (ADSP) that perform TLS termination typically support many different ciphers and protocols which allow them to negotiate the best possible one with each client.

In our scan of the top 1 million websites, we wanted to find the most common preferred PQC cipher offered to clients (i.e. web browsers). Figure 5 represents this, and it is obvious how dominant the X25519MLKEM768 cipher is. Note the similar trends in ranks 80,000 to 200,000 as seen in previous figures.

Figure 6 shows how few sites in the top 1 million support anything other than X25519MLKEM768. Only ten websites in the entire top 1 million support 4 or more PQM KEMs.

Figure 6: Frequency distribution of supported post-quantum Key Encapsulation Mechanisms (KEMs) per website across the top one million domains.

Just one site supported an impressive 10 KEMs, including:

MLKEM512, MLKEM768, SecP256r1MLKEM768, p384_mlkem768, X25519MLKEM768, x448_mlkem768, x25519_mlkem512, p256_mlkem512, MLKEM1024, and p521_mlkem1024.

You may have spotted in the list of key agreement ciphers, above, that some new pure PQC ciphers (ones that do not mix a PQC KEM with a classical key agreement such as ECDHE). Upon further investigation, we found only 1,472 websites (0.32% of the top 1 million) allowed any form of pure PQC connection, although this rises to 1% when excluding Cloudflare.

But what of the impact of large CDNs? What happens if we exclude Cloudflare from the list of PQC supported sites? Since, at the time of writing, Cloudflare’s only support PQC is X25519MLKEM768, the picture changes substantially when we exclude them from the analysis (see Figure 7).

Figure 7: Proportion of supported Key Encapsulation Mechanisms (KEMs) across fifty rank bins of the top one million websites, excluding Cloudflare-hosted domains.

While X25519MLKEM768 remains the most popular, its dominance over the other ciphers is far less pronounced, and we see significant support for SecP256r1MLKEM768, giving an average of almost 20% usage across the top 1 million. This cipher uses the same PQC KEM of MLKEM768 but combines it with the classical elliptic curve SecP256r1.

SecP384r1MLKEM1024 is also present, having an average support of 6.25% across all sites.

FIPS Compliance in a Post-Quantum World

While commercial CDNs and public web traffic heavily favor X25519MLKEM768 due to performance efficiency, regulated enterprises and government entities face a distinct regulatory hurdle. In federal and strictly regulated environments, key-agreement schemes must adhere to approved NIST Special Publications (such as SP 800-56A Rev. 3). Because the widely deployed Curve25519 (X25519) is not an approved key-agreement primitive under current NIST guidelines, commercial hybrid defaults cannot be introduced into strict FIPS-enforced operational baselines. This friction creates an immediate operational question for public sector, defense, financial, and healthcare organizations modernizing their transport security.

To bridge the gap between commercial post-quantum adoption and government standards, the IETF standardized hybrid key-exchange mechanisms paired with NIST curves, notably SecP384r1MLKEM1024 (RFC 10024). This mechanism pairs the approved NIST P-384 elliptic curve (secp384r1) with ML-KEM-1024 (standardized in NIST FIPS 203, meeting NIST Security Category 5). While the US National Security Agency’s (NSA) Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) timeline ultimately mandates pure post-quantum algorithms like ML-KEM-1024 for general transport, hybrid schemes serve as a transitional bridge in network protocols such as IKEv2. However, formal FIPS deployment remains nuanced: the Cryptographic Module Validation Program (CMVP) is still finalizing implementation guidance (such as SP 800-227 and updates to IG D.S) to officially govern how hybrid shared secrets derived under SP 800-56C Rev. 2 can be recognized inside FIPS-validated module boundaries.

For CISOs and security architects in regulated sectors, understanding this distinction is vital. FIPS-mode deployments already rely on approved NIST curves for classical TLS and IPsec negotiations; adding post-quantum resilience means layering an ML-KEM component onto that existing curve foundation, rather than attempting to introduce commercial X25519 defaults. As organizations conduct cryptographic discovery and assemble their Cryptographic Bill of Materials (CBOM) for post-quantum readiness, they must verify that their application delivery controllers, API gateways, and VPN infrastructure support NIST curve hybrid pairings in preparation for incoming CMVP guidance.

Symmetric cipher support

Shor's algorithm poses a catastrophic threat to modern security because it completely breaks classical public-key cryptography (the handshake in TLS) in a single computational leap. In contrast, Grover's algorithm targets symmetric ciphers and hash functions, but its impact is significantly weaker. Rather than instantly cracking encryption, Grover acts as an optimized brute-force search tool that narrows the effective search space for a secret key.

Early post-quantum guidance conservatively recommended doubling symmetric key sizes from 128-bit to 256-bit ciphers under the assumption that Grover would halve effective key strength. However, practical quantum resource estimates reveal major architectural bottlenecks. Grover's algorithm cannot be efficiently distributed across millions of parallel quantum processors without losing its speed advantage. Furthermore, the massive gate depth required for fault-tolerant error correction means executing a Grover key search would require a physical quantum computer to run continuously for thousands of years without hardware failure.

As a result of these physical limitations, global standards bodies and cybersecurity agencies, including NIST, UK NCSC, and Germany's BSI, confirm that existing 128-bit symmetric primitives, such as AES-128 and SHA-256, remain secure against quantum adversaries. While 256-bit keys are still recommended for high-assurance, long-term government classifications and CNSA 2.0, standard 128-bit symmetric encryption provides robust protection for enterprise applications for the foreseeable future.⁵

Figure 8: Frequency distribution of negotiated symmetric ciphers and protocol handshakes across the top one million websites, highlighting the dominant configurations.

Our scan of the top 1 million sites reveals that almost every connection was offered a security symmetric cipher (Figure 8). Insecure sessions, using a known broken cipher, such as RC4, or a small key length, numbered in the dozens out of over 800,00 successful connections.

Sector and Geopolitical Disparities

Policies, regulation, risk appetite, and tech debt, can vary wildly by industry and region. We examined how each sector and nation was progressing in their PQC deployments, and we explored reasons for the apparent disparities.

To identify industries, sectors, and locations, we made use of the BigPicture.io API. This allowed us to have a standardized approach to mapping domain names to industries, and we made use of the Company HQ field to geolocate companies. Since top level domains (TLDs) are increasingly used for vanity purposes (e.g. .io and .ai) we decided that company HQ location provided a more realistic way to locate a company’s primary country, rather than relying on its domain.

Note: Only the top 100,000 domains were mapped to countries and industries. Statistics, averages, and analysis are constrained to the top 100,000 domains only.

Industry variations

Our sector telemetry (Figure 9) exposes a stark divergence between consumer-facing web properties and highly regulated, heavy-industry sectors:

Figure 9: Post-quantum cryptography adoption rate across economic sectors within the top 100,000 websites, showing the percentage of PQC-enabled sites (dark blue) compared to legacy configurations (orange).

Critical Infrastructure and Government Lag Behind

The sector telemetry uncovers a dangerous paradox at the core of national cybersecurity posture: the industries that manage our most critical assets, and harbor data with the longest operational shelf-lives, sit squarely in the bottom quartile of post-quantum readiness. Government agencies (35.4% adoption), Telecommunications providers (35.2%), Oil and Gas operators (34.5%), and Utilities (39.4%) lag far behind commercial averages. These sectors are often constrained by massive operational technology (OT) footprints, air-gapped supervisory control and data acquisition (SCADA) systems, and multi-decade procurement cycles that actively resist rapid cryptographic refactoring. Furthermore, because government portals and utility networks are bound by strict national data sovereignty regulations, they deliberately avoid routing public traffic through US-headquartered cloud CDNs. While this architectural choice preserves jurisdictional control, it isolates these critical operators from the default edge of PQC protections enjoyed by the private sector. Consequently, the very entities safeguarding classified state communications, citizen identity records, and critical utility controls remain the most vulnerable to retrospective HNDL exploitation.

The Accidental Leaders: Consumer, Media, and Travel Sectors

At the opposite end of the spectrum, Consumer Services (58.8% adoption) and Technology (56.1%), followed closely by Consumer Goods (49.8%), emerge as the undisputed global leaders in post-quantum deployment. However, this readiness is likely an architectural artifact rather than the result of deliberate, board-level cryptographic engineering. Modern retail, streaming media, travel booking, and consumer platforms operate in hyper-competitive, high-concurrency digital markets where millisecond latency and DDoS resilience dictate commercial survival. To maximize global performance, these organizations route nearly all inbound web traffic through hyperscale edge platforms such as Cloudflare, Fastly, and AWS CloudFront. When these major providers enabled hybrid PQC key exchanges (specifically X25519MLKEM768) by default across their global edge points of presence, millions of consumer applications became quantum-safe overnight. The risk for security leaders in these sectors is complacency: while external marketing pages and checkout flows enjoy high-profile post-quantum shielding at the edge, internal payment processing pipelines, backhaul API tunnels, and corporate databases frequently remain anchored to unpatched, legacy cryptographic infrastructure.

Regional Disparities

Our telemetry reveals a striking geographic divide in PQC readiness. Rather than indicating varying levels of security awareness, regional adoption rates strongly reflect cloud architecture choices, local hosting ecosystems, and digital sovereignty mandates.

To accurately evaluate a nation's post-quantum progress without statistical distortion, simply measuring a country’s PQC percentage adoption is insufficient. Across the top 1 million domains, sample sizes per country vary by orders of magnitude: while the United States accounts for over 26,000 domains, smaller nations may represent only a few dozen.⁶ Evaluating adoption solely as a percentage creates a severe distortion: a country with 12 out of 12 sites supporting PQC would naively appear 100% quantum-ready, outranking major economies that have successfully upgraded thousands of domains but show a lower aggregate percentage.

To resolve this sampling bias, Figure 10 cross-references PQC adoption percentage (X-axis) against the total volume of top-1M websites headquartered in each country (Y-axis, displayed on a logarithmic scale), with bubble area scaled proportionally to overall domain footprint. This multi-dimensional view separates genuine, large-scale infrastructural readiness from small-sample statistical noise, providing a weighted, realistic assessment of each nation's true cryptographic maturity.

Figure 10: Post-quantum cryptography adoption rate compared to the volume of total scanned sites across international countries, categorized by geographic region.

The Cyber Defense Precedent: Ukraine (65.12%)

Ukraine represents the highest PQC success rate in the entire dataset. Under active hybrid warfare, Ukrainian organizations aggressively migrated public infrastructure to US cloud platforms and DDoS proxy shields (e.g., Cloudflare Project Galileo) for operational resilience, inadvertently making them the most PQC-ready nation on the web.

• Ukraine:65.12% (351 of 539 sites)

The Five-Eyes & Anglo-Sphere Leadership Tier (~55%–63%)

The dataset reveals a tight, top-performing cluster among English-speaking economies and Five-Eyes nations:

• Australia:63.11% PQC Success (698 of 1,106 sites)
• United States:62.05% PQC Success (16,154 of 26,034 sites)
• United Kingdom:60.95% PQC Success (3,397 of 5,573 sites)
• New Zealand:~55%–58% PQC Success (Estimated edge adoption profile)
• Canada:54.23% PQC Success (763 of 1,407 sites)

Key Driver: CDN Edge Dominance & Five-Eyes Alignment

This leadership is not primarily driven by manual enterprise refactoring. Instead, companies headquartered across the Five-Eyes nations (US, UK, Australia, Canada, and New Zealand) heavily utilize US-headquartered cloud hyperscalers and edge Content Delivery Networks (such as Cloudflare, Fastly, and AWS). Because these edge platforms enabled PQC key exchanges (specifically X25519MLKEM768) by default, organizations in these regions inherited post-quantum capability "by accident" at the ingress layer.

Furthermore, regulatory bodies across the Five-Eyes, such as the US NSA/CISA, UK NCSC, Australian Signals Directorate (ASD), and New Zealand National Cyber Security Centre (NCSC NZ via the NZISM), share aligned timelines for PQC migration, establishing a unified strategic push toward post-quantum readiness across government and critical infrastructure.

European Union "Sovereignty Lag" (~35%–46%)

In sharp contrast to the Anglosphere, Continental Europe exhibits significantly lower PQC readiness across major industrial economies:

• Germany:35.78% (1,321 of 3,692 sites)
• France:39.19% (859 of 2,192 sites)
• Italy:39.74% (341 of 858 sites)
• Austria:36.81% (141 of 383 sites)
• Czech Republic:34.15% (111 of 325 sites)
• Spain:45.23% | Netherlands: 46.44% | Denmark: 48.79%

Key Driver: On-Premises Hosting & Regulatory Caution

The ~25 percentage-point gap between Germany/France and the US/UK is a direct consequence of European data sovereignty preferences:

Local Data Center Preference: European enterprises maintain a much higher proportion of self-hosted, on-premises data centers and regional European hosting providers that do not feature "default-on" edge PQC.

National Cryptographic Guidance: Cybersecurity agencies like France's ANSSI and Germany's BSI have issued cautious, highly specific guidance around post-quantum algorithms (favoring specific hybrid implementations or FrodoKEM for high-security applications), causing European IT teams to deliberate rather than rely on US CDN defaults.

East Asian Enterprise Stacks (29%–38%)

The telemetry highlights extreme outliers in East Asia and Eastern Europe, illustrating how local technology stacks impact global metrics:

• Japan:29.69% (437 of 1,472 sites)
• South Korea:29.08% (114 of 392 sites)
• Taiwan:38.26% (88 of 230 sites)

Despite being global leaders in hardware and electronics, Japanese and South Korean enterprises rely heavily on legacy on-premises web infrastructure, custom enterprise load balancers, and domestic hosting providers that have not yet implemented OpenSSL 3.5 or OQS provider modules.

Decoupled & Isolated Infrastructures (13%–16%)

• China:13.03% (116 of 890 sites)
• Russian Federation:16.09% (335 of 2,082 sites)

China and Russia show the lowest adoption rates in the global dataset. In Russia, geopolitical sanctions and the exit of Western edge CDNs (Cloudflare, Fastly) forced fallback onto legacy domestic hosts. In China, domestic CA policies, local CDN providers, and state-mandated cryptographic standards (SM2/SM3/SM4) create a separate cryptographic ecosystem detached from global WebPKI PQC standards.

Sector x Country

Analyzing sectors or geographic regions individually provides a useful macro-level snapshot of post-quantum adoption. However, cross tabulating these two dimensions in a heatmap unveils the underlying structural drivers. By mapping industry sectors against company headquarters, we can instantly determine whether cryptographic readiness is governed by global industry standards or dictated by regional hosting infrastructure and local data sovereignty laws.

All sites

We first begin by analyzing all sites, regardless of how and where they are hosted (Figure 11).

Figure 11: Post-quantum cryptography adoption rate matrix across major economic sectors and corporate headquarters locations within the top 100,000 websites.

The matrix reveals a compelling "cloud leapfrog" phenomenon in emerging enterprise markets, most prominently in India. While major European manufacturing powerhouses like Germany (Healthcare 29.2%, Industrials 30.0%) and France (Healthcare 22.2%, Industrials 36.1%) remain anchored to legacy on-premises web servers, Indian enterprises demonstrate strong PQC readiness across almost all commercial sectors, including Healthcare (47.1%), Industrials (49.1%), and Technology (56.7%). Because India’s enterprise IT ecosystem underwent rapid digital expansion more recently, organizations directly adopted modern cloud edge architectures (such as AWS Mumbai and Cloudflare), cleanly bypassing the decades of accumulated legacy web server debt that continues to restrict continental European firms.

The two-dimensional view also exposes a critical global blind spot in the Telecommunications sector. Even in economies where technology and consumer adoption exceed 65%, telecom providers lag severely across nearly every country in the matrix, dropping to 44.2% in the US, 25.0% in France, 17.6% in Japan, and a striking 14.3% in Australia. Because telecommunications operators manage their public web properties and customer portals on private Autonomous Systems (ASNs) and specialized, self-hosted networking hardware, they operate outside the influence of mainstream commercial CDNs. This infrastructure isolation leaves critical telecom communications vulnerable to HNDL exploitation, even within otherwise security-mature nations.

Finally, the heatmap highlights how regional regulatory frameworks create unexpected industry-specific leadership, such as UK Utilities achieving a world-leading 69.6% adoption rate. Outperforming US Utilities (41.2%) and German Utilities (11.1%), UK utility providers lead all non-technology sectors globally. This anomaly is driven by UK smart-metering mandates and energy market deregulation, which forced utility providers to re-architect their consumer web portals onto modern, high-concurrency cloud edge platforms. Conversely, in sectors where central platforms have been established, such as the unified GOV.UK portal, government web properties achieve 55.1% PQC readiness, whereas fragmented federal and state hosting in the US caps government adoption at 42.7%.

Excluding Cloudflare

When Cloudflare is stripped from the dataset in the second heatmap, this optimistic facade completely collapses. The vibrant, colorful matrix of Figure 11 is instantly replaced by a near-uniform sea of deep, dark maroon, representing a flatline in active, organic adoption. See Figure 12. Stripped of automated CDN-level enablement, PQC adoption across almost all sectors and countries drops to near-zero levels, with most intersections registering a negligible 0.0% to 1.5%. This dramatic visual shift proves that early post-quantum security is almost entirely a passive benefit inherited from network edge infrastructure rather than active, deliberate server migrations. The sole outstanding exception to this collapse is India's Technology sector, which maintains a resilient 32.0% adoption rate even when Cloudflare is excluded. This indicates a highly localized, deliberate engineering effort to deploy native post-quantum security within that specific region.

Figure 12: Heatmap matrix of organic post-quantum cryptography adoption rates across major economic sectors and country headquarter locations within the top 100,000 websites, excluding all Cloudflare-hosted domains

Digital Sovereignty

Over the past few years, digital sovereignty has evolved from a high-level policy debate into an operational mandate for enterprise IT and cybersecurity leaders. This acceleration is driven by intensifying jurisdictional conflicts, most notably the structural tension between the US CLOUD Act, which compels American technology providers to produce data regardless of where servers are physically located, and strict European data privacy laws such as GDPR Article 48. In recent months, this legal imperative has yielded concrete proofs of enforcement across key markets. Landmark regulatory milestones, including the active enforcement of the EU Digital Operational Resilience Act (DORA) across financial infrastructure, the cloud-switching and data portability mandates introduced under the EU Data Act, and the strict qualification rules under France's SecNumCloud 3.2 framework, confirm that digital sovereignty is no longer an abstract compliance goal, but a binding architectural constraint shaping global infrastructure deployment.

To assess data sovereignty and infrastructure dependency, Table 2 compares the headquarters country of each domain against its physical server IP location, revealing how frequently enterprises maintain domestic hosting versus relying on US or third-party infrastructure.

Table 2: Comparing sovereign vs US hosting for a select number of countries

To provide a broader global perspective, Figure 13 maps three distinct infrastructure dimensions for each qualifying nation:

• Domestic Hosting Baseline (Green dot): The percentage of all corporate domains hosted within national borders.
• US Hosting Baseline (Orange dot): The percentage of all corporate domains hosted on US server IP addresses.
• US PQC Dependency (Blue dot): The percentage of PQC-enabled domains hosted on US server IP addresses.

The distance between the orange and blue dots highlights the 'PQC infrastructure gap,' illustrating how post-quantum adoption consistently pulls international web traffic into US cloud hosting environments.

Figure 13: Website sovereignty comparison across international headquarters, contrasting domestic web hosting against United States baseline hosting and United States post-quantum cryptography hosting dependencies.

The Barriers of Technical Debt

Organizations and their web properties have made significant strides since our 2025 State of PQC on the Web report, but many sites are still running on legacy infrastructure. This technical debt can be identified in our data via two indicators:

1. TLS protocol support
2. Lifespan of X.509 certificates

Analyzing the entire top 1 million domains reveals that protocol debt remains a substantial hurdle to quantum readiness (Figure 13) with 10% of sites not yet supporting TLS 1.3, and almost 20% using certificates that last longer than 90 days.

Figure 14: Dual-waffle chart analysis comparing the prevalence of protocol debt (unsupported TLS 1.3) against agility debt (certificate lifespans exceeding 90 days) across the top one million websites.

Missing TLS 1.3

PQC and hybrid-PQC ciphers operate exclusively within the TLS 1.3 handshake via the supported_groups and key_share extensions (defined in RFC 8446). TLS 1.2 cannot natively accommodate these hybrid key shares without non-standard, custom cipher suites that lack broader WebPKI and browser support. Any web property that fails to support TLS 1.3 is therefore completely barred from negotiating post-quantum connections.

Across the evaluated population, 88,928 websites (10.51% of the sites that responded) completely lack support for TLS 1.3. More than one in ten public-facing servers across the global top 1 million cannot establish a post-quantum session, regardless of whether connecting clients (such as modern Chrome, Edge, or Firefox browsers) explicitly request PQC key shares.

Table 3: Comparing all TLS sites with those that support a single TLS protocol

A core driver of this deficit is the substantial cohort of TLS 1.2-only installations, totaling 47,545 domains (5.62%). See Table 3. These represent modern, stable deployments that were updated to meet compliance standards (such as PCI-DSS requirements to deprecate early TLS) but have remained static for years. While secure against classical immediate attacks, these endpoints represent a structural wall against PQC enablement.

Meanwhile, only 9,379 domains (1.11%) have adopted an aggressive "TLS 1.3 only" posture, shedding backwards compatibility entirely.

Figure 15: Percentage distribution of negotiated TLS protocol support across fifty rank bins of the top one million websites, comparing secure modern protocol baselines (green and light blue) against insecure legacy configurations (purple, orange, and red).

Evaluating protocol distribution across 50,000-domain rank bins exposes an unexpected dynamic: the most prestigious, high-traffic domains lag significantly behind lower-ranked cohorts in TLS 1.3 adoption (Figure 13):

• Ranks 1 to 50,000 (Top Tier): TLS 1.3 adoption drops to 83.59%, with TLS 1.2 accounting for 16.35% of all negotiations.
• Ranks 50,001 to 100,000: TLS 1.3 adoption rises to 87.73%, with TLS 1.2 dropping to 12.20%.
• Ranks 100,001 to 150,000 (Peak Tier): TLS 1.3 adoption peaks at 94.31%, while TLS 1.2 shrinks to just 5.65%.
• Ranks 150,001 to 1,000,000: Across the long tail of the web, TLS 1.3 adoption stabilizes tightly between 88.20% and 91.65%, with TLS 1.2 consistently hovering around 8.3% to 11.7%.

This creates a distinct "enterprise inversion curve." High-traffic properties in the top 50,000 are predominantly operated by multinational financial institutions, healthcare providers, legacy media conglomerates, and government portals. These organizations face significant structural friction:

1. Complex Internal Ingress Stacks: Front-end traffic terminates enterprise Application Delivery Controllers (ADCs), dedicated hardware security modules (HSMs), and middleboxes with rigorous change-control windows spanning quarters or years.
2. Deep-Packet TLS Inspection: Corporate environments and regulatory compliance mandates often rely on middleboxes configured for static RSA or TLS 1.2 Diffie-Hellman inspection which, without an SSL Orchestration solution, are fundamentally broken by TLS 1.3's mandatory forward secrecy and encrypted handshake metadata.
3. Client Compatibility Conservatism: Enterprises deliberately restrict TLS configurations to maximize backwards compatibility with embedded legacy clients, point-of-sale systems, and automated B2B API integrations.

In contrast, domains in the 100,001 to 200,000 brackets are disproportionately cloud-native enterprises, high-growth SaaS platforms, and modern web applications hosted behind hyperscale CDNs (such as Cloudflare, AWS CloudFront, and Fastly). These edge platforms enabled TLS 1.3 by default years ago, giving lower-ranked domains an automatic technological advantage over top-tier enterprise stacks.

The telemetry also highlights the stubborn persistence of completely broken legacy protocols. While their proportions appear negligible on linear scales, logarithmic analysis demonstrates that cryptographic deprecation is rarely total:

TLS 1.0: Persists across 0.035% to 0.072% of domains in every single bin. In the 450k to 500k bin, TLS 1.0 reaches a peak of 0.0717%.

TLS 1.1: Appears intermittently across bins, peaking in the 1-50,000 bin at 0.0073% (affecting enterprise environments that never disabled it alongside TLS 1.0). A total of 78 sites across the top 1M support only TLS 1.1.

SSLv3: While officially deprecated in 2015 via RFC 7568 following the POODLE vulnerability, SSLv3 is still detected in trace amounts across multiple bins (e.g., 0.0024% in the top 50,000 bin, and 0.0025% in the 650k to 700k bin). Exactly 8 domains remain active on the modern web supporting exclusively SSLv3.

Certified Confusion

While the transition to Post-Quantum Cryptography (PQC) focuses primarily on algorithm selection and key exchange negotiation, the public key infrastructure (PKI) that authenticates the modern web is undergoing its most aggressive structural transformation in over a decade. While the PKI community is still debating how to adopt PQC in X.509 certificates. One of the biggest challenges is the massively increased certificate size that post-quantum signatures schemes create, and the problems this will cause to IoT/OT, security appliances, and other environments which don’t want to suffer from increased network traffic.

Meanwhile, the lifespan of publicly trusted X.509 Transport Layer Security (TLS) certificates are being drastically curtailed by the Certificate Authority/Browser (CA/B) Forum, shifting the web from long-lived static credentials to short-lived, automated certificates.

Shrinking Certificate Lifepans

For years, certificate lifetimes have followed a steady downward trajectory designed to limit exposure to windows. Prior to 2015, public TLS certificates could be issued with validity periods of up to five years, but the CA/B Forum progressively reduced this maximum to three years in 2015, and then to two years (825 days) in 2018.

In September 2020, Apple unilaterally enforced a maximum validity of 398 days (approximately 13 months) in Safari, forcing Google Chrome, Mozilla Firefox, and the CA/B Forum Baseline Requirements to adopt 398 days as the global standard.

Under the 398-day regime, organizations could rely on annual manual renewal workflows, tracking expiration dates via spreadsheets, or calendar alerts. However, browser vendors and security researchers have long argued that 13 months is far too long to trust a static cryptographic credential, particularly in an era of automated attacks and cloud infrastructure churn.

Following Google's 2023 "Moving Forward, Together" roadmap (which initially proposed a 90-day cap) and an Apple-sponsored initiative, the CA/B Forum officially passed Ballot SC-081v3 in April 2025. Supported unanimously by Apple, Google, Microsoft, Mozilla, and major Certificate Authorities (including DigiCert and Sectigo), this ballot established a binding, multi-year reduction schedule:

Table 4: Significant dates related to the reduction of TLS certificate lifespans

Note: Existing certificates issued prior to each transition date remain valid until their stated expiration, but all reissues, duplicates, and new orders on or after each cutoff must strictly adhere to the shortened limits.

The certificate lifespan distribution mirrors the exact "enterprise inversion" curve observed earlier in the TLS 1.3 protocol telemetry (see Figure 16). In the highest-traffic bracket (ranks 1 to 20,000), short-term automated certificates (90 days or less, shown in dark red) account for only 56% of domains, while standard commercial certificates (91 to 398 days, shown in grey) represent nearly 44%. This heavy reliance on annual commercial certificates highlights the institutional friction within top-tier corporations, financial institutions, and government portals, where rigid change-control policies, static load balancers, and manual procurement cycles still dominate cryptographic operations. As a result, the very organizations managing the most critical public-facing assets are the least prepared for the CA/B Forum to mandate stepping certificate lifespans down to 47 days.

Figure 16: Percentage distribution of negotiated TLS protocol support across fifty rank bins of the top one million websites, comparing secure modern protocol baselines (green and light blue) against insecure legacy configurations (purple, orange, and red).

Conversely, automation readiness surges dramatically across the mid-tier web, peaking in the 120,000 to 160,000 rank brackets where short-term automated certificates reach an impressive 91% adoption. Across the broader long tail of the top 1 million (from rank 240,000 onward), automated lifespans stabilize consistently around an 80% baseline. This sustained high adoption is driven by cloud-native hosts, modern SaaS applications, and free automated Certificate Authorities like Let's Encrypt that mandate 90-day validity via ACME by default. Meanwhile, legacy and self-signed certificates exceeding 398 days (shown in blue) remain virtually non-existent in the upper tiers but steadily expand in the lower half of the top 1 million to claim roughly 1.5% to 2% of sites, representing neglected, unmonitored endpoints operating completely outside modern browser compliance baselines.

Where are all the PQC certificates?

While post-quantum key exchanges (the handshake that establishes the secure tunnel) are now successfully being deployed across the internet, post-quantum authentication, specifically using pure or hybrid-PQC X.509 certificates to verify a website's identity, remains non-existent on the public web. Today, public web servers transmit lightweight classical certificates that easily fit into single network packets. However, migrating to post-quantum signature schemes (specifically NIST FIPS 204 ML-DSA, formerly Dilithium) will increase public key and signature dimensions by an order of magnitude. When multiplied across multi-tier certificate chains, this expansion introduces severe latency penalties, packet fragmentation, and protocol amplification of bottlenecks.

Furthermore, the public WebPKI ecosystem is trapped in a holding pattern due to ongoing standards of development and the promise of a better alternative. The internet Engineering Task Force (IETF) is only just finalizing the complex rules for how a "composite" (hybrid) certificate should be safely structured. Rather than rushing to deploy these heavy, transitional hybrid certificates, major browser vendors (like Google and Apple) and public Certificate Authorities (like Let's Encrypt) are largely waiting for a more elegant, long-term solution: Merkle Tree Certificates (MTCs).

Merkle-Tree Certificates

Merkle Tree Certificates (MTCs) are a game-changer for shrinking post-quantum handshake overhead on the public internet, but they are a poor fit for internal enterprise environments and offline operational technology. Because MTC verification relies on extremely short validity windows and continuous, real-time logging, it cannot function in air-gapped networks, remote IoT deployments, or industrial control systems (ICS/SCADA) that lack low-latency internet connectivity. Crucially, the enterprise business case for east/west traffic is virtually non-existent: modern internal data centers already run on high-bandwidth, 10G/40G/100G fabrics where jumbo frames absorb bulky post-quantum certificates with negligible latency. Running an in-house MTC infrastructure would force corporate IT teams to maintain complex, real-time Merkle log servers and continuous tree-signing pipelines. For internal service-to-service communication, automated private CAs issuing standard, self-contained X.509 certificates remain the only sensible operational choice.

Because widespread adoption of MTC infrastructure will take years, client endpoints and public web servers must implement an ironclad, graceful fallback mechanism to traditional X.509 certificates. During the initial TLS handshake, a client advertises its support for Merkle Tree proofs via specific TLS extensions. If an upstream server lacks MTC capability, if the client cannot reach the corresponding log infrastructure to validate the inclusion proof, or if intermediate network conditions corrupt the proof exchange, the connection must dynamically negotiate standard X.509 post-quantum certificate chains instead. Without this bidirectional protocol agility, any transient outage in public log infrastructure or an incomplete client implementation would result in hard connection drops and widespread digital outages. The web cannot afford a hard switch; MTCs must act as an opportunistic performance accelerator that quietly yields to standard X.509 when conditions require it.

The transition to MTCs will introduce severe operational friction for enterprise security tools that rely on forward SSL/TLS inspection, such as Next-Generation Firewalls and Secure Web Gateways. These inspection appliances operate as authorized man-in-the-middle proxies: they intercept outbound employee traffic and dynamically mint a spoofed, on-the-fly certificate signed by the corporate private root CA, allowing the proxy to decrypt and inspect the session for threats. MTCs break this model because an on-premises firewall cannot dynamically generate a valid Merkle inclusion proof on the fly without running its own authenticated tree-logging engine. To avoid breaking corporate web access, security architects will be forced to configure their inspection engines to strip MTC extensions from outbound client handshakes, artificially forcing public web servers to downgrade to classic X.509 certificates. If a public site enforces MTCs exclusively, or if a browser's enterprise root policies fail to recognize classic X.509 fallback paths, the firewall's decryption engine will trigger immediate, catastrophic connection failures across corporate endpoints.

Post-Quantum X.509 Certificates

The size of an X.509 certificate is governed primarily by two cryptographic components:

1. The Subject Public Key: Embedded within the SubjectPublicKeyInfo field.
2. The Signature Value: Appended by the issuing Certificate Authority (CA) to bind identity to the public key.

Table 5 contrasts the raw cryptographic footprint of classical algorithms with NIST-standardized post-quantum signature schemes:

Table 5: Comparing the raw cryptographic footprint of classical algorithms with NIST-standardized post-quantum signature schemes

In a TLS 1.3 handshake, the server does not simply transmit its own leaf (end-entity) certificate. To allow the connecting client to construct a cryptographic path back to a trusted root in its local trust store, the server must transmit an entire Certificate Chain (typically the leaf plus one or more intermediate CA certificates). Figure 17 shows the most common certificate chain lengths for sites in our scan of the top 1 million.

Figure 17: Distribution of certificate chain lengths across post-quantum cryptography enabled websites in the top one million domains.

Figure 17 shows the breakdown of certificate chain lengths for sites across the top 1 million. The overwhelming majority of sites sent 1 or 2 additional intermediary CA certificates as well as the leaf certificate. A small number only sent the leaf certificate, but many sites sent back a huge number of intermediary certs, in one case 43 additional certificates were sent along with the leaf certificate.

Table 6 calculates the total transmitted payload size across these real-world architectural configurations:

The explosion from a 2.0 KB classical chain (ECDSA P-256) to a 14.6 KB / 17.0 KB post-quantum hybrid chain introduces critical transport-layer performance penalties.

The TCP Initial Congestion Window (Initcwnd) Cliff

Most modern operating systems and web servers configure the initial TCP congestion window (initcwnd) to 10 Maximum Segment Sizes (MSS). On standard Ethernet networks with an MTU of 1,500 bytes (yielding an MSS of 1,460 bytes), a server can transmit at most:

10 × 1,460 bytes ≈ 14,600 bytes (14.25 KB)

• Classical Behavior: A classical ECDSA chain (2 KB to 3 KB) plus TLS handshake framing comfortably fits well inside the initial 14.25 KB window, completing the TLS handshake in a single round-trip time (1-RTT).
• PQC Behavior: A pure ML-DSA-65 3-cert chain (18.3 KB) or a hybrid chain (21.9 KB) instantly shatters the initcwnd boundary. The server is forced to pause transmission mid-handshake, wait for the client to send a TCP ACK packet across the network, and only then transmit the remainder of the certificate chain. This introduces an unavoidable extra round-trip delay (+1 RTT) on every new connection.

QUIC and HTTP/3 Anti-Amplification Limits

In HTTP/3 (built over UDP/QUIC, RFC 9000), servers must prevent attackers from using their infrastructure as distributed denial-of-service (DDoS) reflection amplifiers. Before a client's IP address is validated, the server is strictly forbidden from transmitting more than three times the number of bytes received from the client (the 3x anti-amplification limit).

Because an initial QUIC ClientHello packet is typically padded to 1,200 bytes, a server cannot respond with more than 3,600 bytes of handshake data before waiting for a client acknowledgment. While classical ECDSA certificates fit within this 3.6 KB boundary, any post-quantum or hybrid certificate chain immediately violates the anti-amplification limit, forcing an artificial handshake pause and eliminating HTTP/3's low-latency benefits.

During our scan of the top 1 million TLS configurations, we also attempted HTTP/3 connections. We found almost 60% of PQC-ready sites also supported HTTP/3, while only 25% of non-PQC sites allowed this protocol (Figure 18).

Figure 18: Transport protocol distribution within the post-quantum cryptography enabled website cohort, contrasting HTTP/3 adoption (dark blue) against legacy TCP-based HTTP hosting (orange).

IP Fragmentation and Packet Loss Risks

Certificates that exceed typical Path MTU (1,500 bytes) require multiple TCP/IP segments. Across mobile networks, enterprise VPN tunnels, and legacy network middleboxes, multi-packet TLS handshake messages experience substantially higher packet-loss probabilities. A single dropped packet stalls the reassembly of the post-quantum certificate chain, compounding connection latency.

The Root of the CA Problem

While the industry focuses on shrinking leaf certificate lifespans to 47 days, the deeper architectural challenge in WebPKI sits at the root and issuing Certificate Authority (CA) layer. End-entity (leaf) certificates protect individual domains and expire quickly, but CA private keys anchor trust for millions of sites simultaneously. Under Shor's algorithm, a quantum adversary may not target leaf certificates and attack one website at a time; they are, instead, likely to target classical CA signing keys enabling them to mint authentic-looking certificates for any domain without touching the target server.

Figure 19: Distribution of Issuing CA certificate lifespans across trust chains in the top one million websites, highlighting the relative cryptographic risk posed by long-lived certificates.

As shown in Figure 19, nearly 300,000 CA certificates currently active in top-1M chains possess lifespans exceeding 8 years, with over 93,000 valid for 18 to 25+ years. This multi-decade validity model was designed for stability and embedded client compatibility. However, in a post-quantum context, every classical RSA or ECDSA authority certificate spanning into the 2030s represents a persistent mathematical target.

Mapping unique CA certificates against calendar expiration dates (Figure 20) reveals a tale of two timelines. On one hand, a massive wave of roughly 2,500 intermediate and cross-signed CAs expires naturally in 2026. On the other hand, a persistent tail of hundreds of unique CAs remains valid well past the estimated Q-Day horizon, with some extending out to 2045. If these classical authorities remain trusted by client ecosystems past the arrival of quantum cryptanalysis, their underlying private keys could theoretically be factored to execute broad, undetectable impersonation attacks.

Figure 20: Distribution of unique Certificate Authority (CA) certificate expirations across observed trust chains compared against the projected Q-Day threat horizon in 2035.

Is the CA issue catastrophic as the raw expiration dates suggest? When evaluating the mechanics of WebPKI, two critical realities provide essential balance:

The Standardization Deadlock: CAs Cannot Act Yet

Certificate Authorities are unable to simply switch their root and intermediate certificates to PQC today. Discussions in the IETF LAMPS (Limited Additional Mechanisms for PKIX and SMIME) working group and the CA/Browser Forum are still underway to finalize standards for pure and composite PQC X.509 structures (such as ML-DSA under draft-ietf-lamps-post-quantum-signatures).

Until these standards are formally ratified and incorporated into the CA/B Forum Baseline Requirements, public CAs are legally and procedurally prohibited from issuing standardized PQC certificates into the public WebPKI.

Are Long-Lived Roots Only a Threat If Browsers Accept Them?

Technically a root certificate validity date is merely an expiration ceiling; it is not a guarantee of trust.

Trust is ultimately decided by the client's local trust store. Modern browsers (Chrome, Safari, Edge, Firefox) and major operating systems (Apple, Microsoft, Google) control their own root programs. These vendors can, and routinely do, distrust or deprecate root certificates overnight via background software updates regardless of whether the certificate has years of validity remaining (as seen historically with WoSign, Symantec, and Entrust). If browser vendors enforce a hard cutoff date (for example, announcing that no classical RSA/ECDSA root signatures will be accepted after January 1, 2030), the "Forge Later" attack on those browsers is completely neutralized, because the browser will reject any certificate signed by a classical root.

Where the Real Danger Actually Sits

If modern browsers have a kill switch, why worry about the long-tail CAs in Figure 18? The true risk is twofold:

1. The Migration Dilemma (The Coordination Trap)
   Browser vendors can only disable classical roots once virtually the entire web has migrated to post-quantum certificates. If browsers drop classical roots too early, they break millions of active sites. If they wait for the long tail to migrate, they leave a wide transition window open for quantum adversaries to forge certificates against lagging endpoints.
2. The Non-Browser World (IoT, OT, and Embedded Systems):
   While Chrome updates weekly, millions of connected vehicles, industrial control systems, medical equipment, and smart devices embed static trust stores in firmware or un-patchable ROM. These devices will blindly trust classical roots expiring in 2035 or 2040 for decades, making them the true target for quantum forgery rather than consumer web browsers.

Recommendations

The Cryptographic Bill of Materials (CBOM)

The number of cryptographic touch points in an enterprise is likely to be far more than first estimated. Consider all web sites, public and private, test and dev environments, hardware and software appliances, hardware security modules (HSMs), bespoke apps with embedded cryptographic libraries, database and disk encryption, identity and access tools and protocols. The list is likely to be enormous.

Attempting to migrate to post-quantum cryptography without a dynamic inventory is an impossible task: you cannot remediate what you cannot see. This is why building a Cryptographic Bill of Materials (CBOM) has become the mandatory first milestone advocated by NIST, the US Cybersecurity and Infrastructure Security Agency (CISA), and the UK NCSC.^{7, 8}

Extending the principles of a Software Bill of Materials (SBOM), a CBOM provides a machine-readable, centralized registry that catalogues every cryptographic asset across the organization. It captures which algorithms, key lengths, cipher suites, digital certificates, and protocol versions are active, while identifying their exact physical location, hardware dependency, and software ownership.

A comprehensive cryptographic discovery process cannot rely on a single scanning technique. Enterprises must deploy tools across three distinct operational planes:

1. Network and External Attack Surface Discovery (In-Transit Cryptography)
   Active network scanners evaluate TLS handshakes across public domains, internal subnets, and Kubernetes ingress controllers to identify non-PQC compliant protocols (TLS 1.0, 1.1, 1.2), weak symmetric ciphers, and expiring certificates.
2. Source Code and Binary Analysis (Embedded Cryptography)
   Bespoke applications and internal microservices often embed static cryptographic implementations, hardcoded keys, or legacy libraries directly in source code or compiled container images.
3. Host, Keystore, and Appliance Discovery (At-Rest and Identity Assets)
   Enterprise hosts and operating systems harbour fragmented local key vaults that operate outside central IT visibility.

Recommended Next Steps:

1. Establish a Cross-Functional Crypto-Agility Team: Bring together infrastructure, application development, and compliance leaders to define cryptographic ownership.
2. Execute a Phase 1 Ingress and External Surface Scan: Deploy automated network scanners across all public and B2B API endpoints to catalogue external TLS configurations and certificate chains immediately.
3. Integrate CBOM Generation into CI/CD Pipelines: Mandate that internal development teams incorporate automated tools into software build pipelines, ensuring all newly deployed applications produce a standardized cryptographic bill of materials by default.

Eradicating TLS 1.2 and Legacy Cryptography

Post-quantum encryption mechanisms operate exclusively on modern protocol standards. Retiring older protocols like TLS 1.2 is therefore not a routine maintenance task: it is an absolute prerequisite for quantum resilience.

Many organizations assume that because their current encryption meets baseline compliance requirements, upgrading can wait. Our data disproves this: over 10% of the web's top domains completely lack modern protocol support, and more than 5% rely solely on legacy versions. For these organizations, every session remains entirely vulnerable to data harvesting, regardless of how advanced their other security defenses may be.

Eradicating legacy protocols requires three practical executive actions:

1. Resolve the Inspection Blind Spot: Security operations often delay protocol upgrades because older network monitoring tools break when modern encrypted traffic passes through them. Deploying modern application delivery and inspection platforms resolves this by safely decrypting traffic once for internal security inspection without forcing external connections to downgrade to older, vulnerable protocols.
2. Eliminate Partner and Client Friction: Legacy business-to-business APIs and older software libraries frequently depend on outdated encryption. Security leaders must establish a firm's sunset timeline for partners, using traffic telemetry to identify and notify lagging consumers before legacy protocol support is switched off.
3. Purge Lingering Foundational Debt: Retiring older standards provides the natural opportunity to mandate the complete elimination of deprecated algorithms, weak keys, and unmaintained staging configurations across all environments.

Deploying SSL Orchestration for Immediate Transitional Protection

Refactoring internal enterprise applications to support post-quantum cryptography may take years, but adversaries are harvesting encrypted data today. Deploying a dedicated SSL orchestrator at the network perimeter resolves this timing dilemma. By terminating modern hybrid PQC connections at the edge while safely communicating with existing internal servers, an orchestrator shields enterprise data from Harvest Now, Decrypt Later (HNDL) attacks immediately, buying development teams years of breathing room to modernize core backends on normal maintenance cycles.

Critically, deploying SSL orchestration also directly enables and accelerates the previous two recommendations:

• Automating Continuous CBOM Discovery: Rather than running slow, disruptive scans across thousands of individual servers, an orchestrator sits at the strategic traffic chokepoint. It inspects every client and server handshake in real time, continuously feeding live inventory data (protocols, cipher suites, certificate ages, and unmanaged shadow IT endpoints) directly into your central cryptographic management tools.
• Accelerating TLS 1.2 Eradication Without Breaking Inspection: Security operations often delay retiring TLS 1.2 because older firewalls and data loss prevention (DLP) tools cannot inspect modern, fully encrypted TLS 1.3 handshakes. An SSL orchestrator solves this through a "decrypt once, inspect across many" model. It terminates incoming PQC handshakes at the edge, routes cleartext traffic through internal security inspection tools, and re-encrypts it before reaching the backend. This allows organizations to mandate strict TLS 1.3 externally on day one without losing internal security visibility or breaking legacy origin servers.

Ensuring Crypto-Agility

Manual certificate management cannot survive the industry's rapid transition to ephemeral trust. With the CA/Browser Forum reducing maximum certificate lifespans down to 47 days by March 2029, manual renewals are mathematically guaranteed to cause catastrophic operational outages. An enterprise managing several hundred certificates will face thousands of lifecycle events each year, transforming certificate renewal from an annual maintenance task into a continuous daily process, risking errors and wasting countless spend.

Organizations must mandate the enterprise-wide adoption of the Automated Certificate Management Environment (ACME, RFC 8555) protocol across all application delivery controllers, ingress proxies, and server fleets. Furthermore, tying infrastructure to a single Certificate Authority introduces an unacceptable single point of failure. Automated pipelines must be configured with a programmatic multi-CA failover. If a primary provider suffers a network outage, experiences a service-level disruption, or is suddenly distrusted by browser root programs, the automation engine must dynamically reroute certificate requests to an alternative authority without service interruption.

Beyond solving immediate operational hurdles, automated certificate pipelines provide the practical foundation for true cryptographic agility. Major national regulatory authorities have elevated crypto agility from an architectural recommendation to a binding strategic imperative: NIST formalized this blueprint in its Cybersecurity White Paper (CSWP) 39, while the US NSA (under CNSA 2.0), CISA, France's ANSSI, and Germany's BSI (via TR-02102-1) all explicitly mandate that modern systems must be capable of swapping algorithms, key lengths, and certificates without redesigning underlying infrastructure.

This agility is essential because quantum computing is far from the only existential threat to digital trust. Classical cryptanalytic breakthroughs, implementation flaws, side-channel vulnerabilities, and the advancement of AI and its use in cryptanalysis, may compromise classical encryption even if quantum computers fail to materialize for another decade. By decoupling application logic from static credentials and establishing automated multi-CA pipelines, enterprises achieve the agile operational posture required to respond to algorithm deprecations, vendor failures, and mathematical surprises in hours rather than years.

Conclusion

The 2026 telemetry reveals a tale of two divergent internets. On the surface, the headline metric of 54% PQC adoption suggests rapid, historic progress toward quantum resilience. Yet beneath this public-edge veneer lies a profound operational reality gap. The vast majority of today's post-quantum capability is not the result of deliberate enterprise modernization, but rather an accidental byproduct of edge CDN defaults and hyperscaler proxy shields. Where organizations must manage their own infrastructure, readiness collapses. The world's most critical assets, including government portals, telecommunications backbones, utility control networks, and core financial interfaces, sit largely unshielded in the bottom tiers of adoption, weighed down by legacy operational technology, complex middleboxes, and lingering TLS 1.2 technical debt.

The "so what" of this data cannot be overstated for enterprise security leaders and board directors. The threat of post-quantum cryptanalysis is not a distant concern reserved for the 2030s; it is an active, ongoing operational liability today. Adversaries are actively harvesting encrypted enterprise communications, proprietary intellectual property, healthcare records, and state secrets under Harvest Now, Decrypt Later (HNDL) campaigns. Every day that sensitive data is encrypted with classical ciphers, or traverses legacy TLS 1.2 connections, its confidentiality window is permanently compromised. When Q-Day arrives, this captured data will be decrypted, creating severe regulatory, legal, and commercial fallout under emerging compliance frameworks like DORA, NIS2, and GDPR.

Furthermore, the post-quantum transition cannot be treated as a single, calendar-driven algorithm for replacement. True resilience requires structural crypto-agility across the entire technology stack. As the CA/Browser Forum accelerates certificate lifespans down to 47 days and slashes domain validation reuse to 10 days, manual certificate management will become a guaranteed failure mode. Concurrently, the impending arrival of multi-kilobyte post-quantum digital signatures will challenge traditional network boundaries, forcing a delicate dual-issuance coexistence between composite X.509 certificates and Merkle Tree Certificates (MTCs), while placing severe strain on internal service meshes, mutual TLS payloads, and container MTU boundaries.

The window for complacency has closed. Organizations that rely on CDN edge defaults are merely protecting their front door while leaving their backhaul tunnels, internal microservices, and B2B API integrations completely exposed. Navigating this cryptographic inflection point demands immediate, decisive execution across five foundational pillars: cataloging an exhaustive Cryptographic Bill of Materials (CBOM), aggressively eradicating TLS 1.2 protocol debt, deploying SSL orchestration to deliver immediate transitional protection for legacy backends, mandating certificate automation with multi-CA failover to survive the 47-day certificate mandate, and contractually enforcing crypto-agility throughout vendor procurement. Quantum readiness is no longer an abstract theoretical milestone; it is an urgent operational prerequisite for modern enterprise resilience.