Post-Quantum Crypto: Why Talk Outpaces Deployment

Post-Quantum Cryptography: The Gap Between Planning and Deployment

DigiCert's July 2026 survey of 1,001 enterprise security leaders found 87% of organizations are "planning, testing, or implementing" post-quantum cryptography — but only 7% have deployed it across more than half their digital certificates, barely moved from 5% a year earlier. Meanwhile, a small number of infrastructure players have already done the hard part: Cloudflare reports over 65% of human web traffic on its network is post-quantum encrypted, and independent scans put broad internet-wide server adoption at under 40%. The standards are finished. The gap between talking about migration and actually shipping it is the story.

The Standards Are Done — That Part of the Debate Is Over

NIST finalized three post-quantum cryptography standards — ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a conservative hash-based fallback — in August 2024, with a fourth backup key-encapsulation algorithm, HQC, selected in March 2025. There is no longer a credible "the standards aren't ready" excuse available to any organization evaluating migration. What's left is deployment, and deployment is where the real split between talk and action shows up.

The urgency behind this isn't hypothetical. "Harvest now, decrypt later" describes adversaries capturing encrypted traffic today and storing it until a quantum computer capable of breaking RSA and ECC exists to decrypt it. The EU's draft NIS2 amendment released in early 2026 explicitly described HNDL attacks as already occurring, not a future risk. Estimates of how many qubits a fault-tolerant quantum computer would need to break RSA-2048 have fallen sharply — Google Quantum AI researcher Craig Gidney's May 2025 paper put the number under one million noisy qubits, a roughly twentyfold reduction from his own 2019 estimate of around 20 million. Every subsequent public revision has moved in the same direction: down.

Who's Actually Done It

A short list of organizations have moved past pilots into production-scale deployment, and their numbers are specific enough to check.

Cloudflare is the clearest infrastructure-level success story. The company enabled post-quantum key agreement for all websites and APIs on its network back in 2022, and by April 2026 reported that over 65% of human-generated traffic through its network was post-quantum encrypted — up from just over 50% in October 2025. Cloudflare has now shifted its full target date to 2029, when it expects post-quantum authentication — not just key exchange — to be the default across its entire product line without requiring any customer action.

That 65% figure describes the client-to-edge connection, though, not the whole internet. Independent researcher Jan Schaumann's regular scans of the top 100,000 domains found only 39% supporting post-quantum key exchange server-side as of September 2025, up from 28% six months earlier — real progress, but a much smaller number than Cloudflare's edge statistic, and a useful reminder that "the internet has gone post-quantum" is true for traffic routed through a handful of large providers and much less true for the wider server population.

Google enabled post-quantum key agreement server-side for most of its own infrastructure back in 2023, ahead of Cloudflare, and has set an internal target of full PQC migration by 2029. Apple deployed its PQ3 protocol in iMessage in February 2024, making it the first widely used consumer messaging platform with post-quantum end-to-end encryption, and Signal adopted the PQXDH key exchange protocol in September 2023 for its more than 40 million users. On the browser side, Chrome enabled ML-KEM hybrid key exchange by default starting with Chrome 124 in April 2024, with Edge and Firefox following — which is a large part of why Cloudflare's client-side percentage climbed as fast as it did: browser vendors, not individual websites, did much of the early work.

Microsoft shipped general availability of ML-DSA support inside Active Directory Certificate Services on Windows Server 2025 in May 2026 — the first mainstream enterprise certificate authority platform able to issue post-quantum certificates in production. That matters disproportionately because it's aimed at the enterprise PKI layer, which is exactly where the DigiCert survey shows everyone else stalling.

Who's Still Just Talking About It

The gap shows up most clearly at the enterprise level, away from the handful of hyperscale infrastructure vendors named above. DigiCert's second annual Quantum Readiness Outlook, based on 1,001 IT and security decision-makers surveyed across the US, UK, and Australia and published July 23, 2026, found 87% of organizations describe themselves as planning, testing, or implementing PQC. Only 7% report that more than half of their digital certificates run on quantum-safe or hybrid cryptography — an increase of less than two percentage points from the 5% DigiCert measured in its first survey in May 2025. Retail showed the lowest deployment share among the industries surveyed.

Separately, Ponemon Institute's 2026 Global State of Post-Quantum and Cryptographic Security Trends study, sponsored by Entrust and based on more than 4,000 IT and security practitioners worldwide, found 68% of organizations describe managing their cryptographic assets as extremely or very difficult, and only 38% report actively transitioning to post-quantum cryptography at all — a figure that actually declined year over year despite the tightening regulatory deadlines described below.

The DigiCert data undercuts a common assumption about why enterprises are slow: it isn't apathy at the top. In DigiCert's 2025 survey, weak executive buy-in looked like a plausible explanation for the low deployment number. By 2026, executive buy-in ranked as the single biggest obstacle for only 8% of respondents, tied with standards uncertainty and interoperability concerns; legacy system complexity was cited by roughly a quarter of respondents as the primary blocker. Leadership has largely bought in. The problem is that most enterprise cryptography is buried inside systems nobody has fully inventoried, and inventory — not intent — is the actual bottleneck.

Why the Standards Being Done Didn't Make This Fast

The core reason intent hasn't converted into deployment is arithmetic, not willpower. ML-DSA signatures run roughly 15 to 50 times larger than the classical signatures they replace — an ML-DSA-87 signature is about 4,627 bytes versus roughly 96 bytes for ECDSA P-384. That size difference propagates through every certificate in a chain, every TLS handshake, and every hardware security module operation, which means certificate authorities have to migrate root-first, in sequence, before anything downstream can follow. Migrating a leaf certificate before its issuing CA breaks validation outright.

Before any of that can even start, most organizations don't actually know where their vulnerable cryptography lives. A credible cryptographic inventory has to span endpoint scanning, live network traffic, certificate authority databases, hardware security module partitions, infrastructure-as-code repositories, and third-party software bills of materials — because a meaningful share of at-risk cryptography is hardcoded into legacy application code or embedded in vendor libraries nobody has audited in years. That inventory work, increasingly formalized as a Cryptographic Bill of Materials, is unglamorous, doesn't produce a headline, and is exactly the step most enterprises are still stuck on.

The Deadlines That Are About to Make "Still Planning" Untenable

Three dates converge in late 2026 and early 2027, and each converts what has so far been a voluntary roadmap into something with procurement or compliance teeth. NIST's FIPS 140-2 validation status moves to "Historical" on September 21, 2026, meaning federal procurement will require FIPS 140-3 validated cryptographic modules going forward. The EU's NIS Cooperation Group has set December 31, 2026, as the deadline for member states to publish national PQC strategies, a step toward the binding NIS2 obligation the European Commission proposed in January 2026. And the NSA's CNSA 2.0 suite becomes a mandatory acquisition gate for new National Security Systems on January 1, 2027, requiring ML-KEM-1024 and ML-DSA-87 specifically — stricter parameter sets than the civilian defaults most enterprise pilots have been testing against.

On the US federal civilian side, President Trump signed Executive Order 14412 on June 22, 2026, mandating PQC migration for federal agencies and their contractors, with the Office of Management and Budget's follow-up guidance (M-26-15, issued June 24, 2026) setting a December 31, 2030 deadline for high-value federal systems. NIST's own IR 8547 draft sets the wider deprecation schedule: 112-bit security algorithms like RSA-2048 and ECC P-256 are deprecated by 2030, and all quantum-vulnerable public-key algorithms are disallowed in NIST standards entirely by 2035.

The Genuine Counterpoint: Nobody Knows When "Q-Day" Actually Arrives

The one piece of nuance worth holding onto is that the urgency driving all of this rests on an estimate, not a fact. No cryptographically relevant quantum computer exists as of mid-2026. Expert surveys on when one might exist span an unusually wide range — from claims it's already been achieved in a classified setting to arguments that the engineering challenges may never be fully solved — with most serious estimates clustering somewhere in the 2030 to 2035 window, which is exactly why government migration deadlines land in that range. Google's own May 2026 estimate suggesting some systems could be vulnerable by 2029 sits at the aggressive end of that range, not the consensus.

That uncertainty doesn't undercut the case for migrating now — harvest-now-decrypt-later means the relevant deadline is when data currently being collected stops needing to stay confidential, not when a quantum computer is switched on — but it does mean the loudest "Q-Day is imminent" framing in some vendor marketing overstates the certainty of the timeline. The honest version is: nobody can name the year, the trend in resource estimates keeps moving earlier rather than later, and the responsible planning posture treats the earlier end of the range as the one to prepare for.

What This Actually Means for a Security Team Right Now

Being "in planning" puts you in the majority, not behind it — but that won't last past 2026. The 87% figure means most organizations are exactly where DigiCert's data says they are. The risk isn't being behind peers today; it's still being in that group when the FIPS 140-2 and CNSA 2.0 deadlines land in the next several months.

Inventory, not algorithm selection, is the actual first step. Every organization named above as having "done it" started with knowing precisely where their vulnerable cryptography lived. Skipping that step to jump to algorithm rollout is the most common reason enterprise pilots stall.

Confidentiality-lifetime data should migrate before signing infrastructure. Data that needs to stay confidential for years — financial records, healthcare data, long-lived intellectual property — is exposed to harvesting today, regardless of when a quantum computer arrives. Long-lived signing identities like root certificate authorities and firmware signing keys are the second priority, not the first.

Server-side and client-side adoption are different numbers — check both. Cloudflare's 65% figure describes edge traffic; independent internet-wide server scans put actual adoption closer to 39%. An organization's own dependency on major CDNs or cloud platforms can make its exposure look better or worse than its own infrastructure actually is.