Google and Cloudflare Set a 2029 PQC Deadline. The Rest of Big Tech Did Not.

Two papers dropped at the end of March. Both said the same thing in different ways: the quantum threat to elliptic curve cryptography is closer than we thought. How close? The kind of close that made Google set an internal deadline five years ahead of what the US government asked for and caused Cloudflare to immediately fall in line. And the kind of close that most of the rest of big tech is apparently comfortable watching from a distance.

Let me walk you through what those papers actually showed, who moved, who didn't, and what a four-year gap between migration timelines means in practice.

The Papers That Started This

March 31, 2026 was a bad day for anyone still feeling relaxed about the quantum threat.

Google Quantum AI published resource estimates for breaking ECC-256 using Shor's algorithm. Their number: fewer than 500,000 superconducting qubits. That sounds like a lot until you remember the previous leading estimate, from Craig Gidney in 2021, was around 20 million. The requirement just dropped by more than a factor of 40.

The same day, a team from Oratomic, Caltech, and UC Berkeley published a second paper that went further. They applied Google's compiled circuits to neutral atom hardware instead of superconducting qubits. The neutral atom architecture is reconfigurable in three dimensions, which lets you map problems onto far fewer physical qubits. Their result: approximately 10,000 reconfigurable atomic qubits could run Shor's algorithm at cryptographically relevant scales. A 26,000-qubit neutral atom system could crack ECC-256 in about ten days. RSA-2048 takes longer — roughly 102,000 qubits and three months — because the key is larger and Shor's algorithm scales with key size. ECC falls first, which is exactly what you do not want to hear, because ECC-256 is what protects your TLS connections, your SSH keys, your OAuth tokens, and your FIDO2 authentication flows right now.

The author list on the Oratomic paper includes John Preskill and Dolev Bluvstein. If those names don't mean anything to you: Preskill is one of the founders of quantum error correction theory, and Bluvstein led Harvard's landmark neutral atom fault-tolerance demonstrations. This is not a crank paper. Worth noting that all nine authors hold Oratomic equity, which is a relevant detail — but the underlying results reference Google's own verified circuits.

The broader trend is staggering regardless. Estimated qubit requirements for cryptographically relevant Shor's algorithm runs have fallen five orders of magnitude over two decades. That trajectory did not slow down in 2026. It sped up.

Who Moved

Google announced its 2029 PQC migration deadline on March 25, a week before those papers dropped. The timing is not a coincidence. Their security engineering leadership wrote that they needed to "prioritize PQC migration for authentication services" and explicitly recommended other engineering teams follow their lead.

The migration scope is substantial. Google's ML-DSA has already landed in Android Verified Boot, meaning the startup sequence that checks your Android device's integrity before handing control to the OS is now quantum-resistant. Remote attestation, the mechanism that proves device integrity to enterprise servers and cloud services, is transitioning next. The Android Keystore and the Play Store's app-signing processes are further down the roadmap, which will require developers to update signing and verification workflows.

The Chromium roadmap for PQ authentication has four stages, ending with mandatory post-quantum TLS keys.

Cloudflare moved to match on April 7. Their blog post cited both the Google Quantum AI resource estimates and the Oratomic paper as the catalysts. Cloudflare started their PQC migration in 2019, enabled post-quantum encryption for all websites and APIs through their network in 2022, and reports that over 65% of human-initiated traffic hitting their network is now post-quantum encrypted. The remaining problem — and the reason they accelerated — is authentication. Encrypting the data channel is the easy part. Signing and authenticating identities with quantum-resistant signatures is where the engineering gets hard, because ML-DSA signatures are roughly 37 times larger than ECDSA signatures. That's bandwidth, latency, and compatibility debt landing on every TLS handshake.

If you've read our earlier piece on Merkle Tree Certificates and the Post-Quantum Web, you already understand the certificate size problem. The short version: a naive post-quantum certificate chain is 15kB+ per TLS handshake versus 4kB today. Cloudflare's target for supporting ML-DSA authentication on Cloudflare-to-origin connections is mid-2026. Visitor-to-Cloudflare connections using Merkle Tree Certificates are targeted for mid-2027.

Two of the most critical pieces of internet infrastructure just committed to the same year. When the dominant CDN and the dominant browser/OS vendor agree on 2029, that date stops being a voluntary goal and starts functioning as an industry mandate.

Who Stayed the Course

Microsoft published their Quantum Safe Program before any of this. Their plan has core infrastructure migration starting 2026, integration into Windows, Azure, and Microsoft 365 beginning 2027, and full completion by 2033. That's four years behind Google. To be fair to Microsoft, 2033 is still two years ahead of the NSA's 2035 deadline and aligns with broader government guidance.

IBM has focused heavily on tooling. Their Quantum Safe Explorer handles cryptographic inventory for enterprises running IBM infrastructure, and their z16 mainframe ships PQC hardware acceleration. But IBM has not published a specific completion target for its own internal migration, at least not publicly. They're building the shovels while Google and Cloudflare are digging.

AWS has published migration guidance and is rolling out PQC capabilities under a shared responsibility model. Some features are transparently enabled for all customers, others are opt-in. Amazon's public guidance points to government timelines rather than internal deadlines, suggesting they're tracking the regulatory calendar, not the threat calendar.

Meta published a detailed PQC migration framework in April 2026. It's worth reading for anyone managing a large-scale migration, because their breakdown of "PQC Migration Levels" is practical and the lessons learned section is honest. Meta's own timeline aligns with the 2030 guidance from NIST and the NCSC rather than Google's accelerated posture. They're ahead of most enterprises, but they're not racing.

Signal and Apple have incorporated ML-KEM-768 into messaging and device security respectively, but both implementations are hybrid — classical plus PQC, running in parallel — and neither company has announced a deadline for dropping the classical half.

The Gap That Actually Matters

The divergence in timelines is not just a press release problem. It has structural consequences.

Cloudflare handles a significant fraction of global internet traffic. Google controls Chrome, Android, and some of the most critical authentication infrastructure on the internet. If you're building anything that touches a Cloudflare CDN or an Android device — which means almost any web developer or mobile developer reading this — the 2029 deadline is landing on your code whether you've thought about it or not.

Here's the mechanical issue. Post-quantum authentication requires both sides to support it. Google and Cloudflare can mandate PQC connections in Chrome and at the Cloudflare edge, but every origin server, every backend API, every authentication provider between you and the user has to participate. If your infrastructure is still running classical ECDSA in 2029, you will need to support both handshake paths, which means more complexity and more attack surface. Eventually, browsers will drop the fallback. That day just moved forward.

There's also the harvest now, decrypt later problem, which the 2030s crowd tends to underweight. Adversaries collecting encrypted traffic today can store it and decrypt it when capable quantum hardware exists. For data with a long security lifetime — authentication keys, identity records, signed audit logs, compliance archives — the threat window isn't "when does Q-Day arrive." It's "how old is the oldest thing I've encrypted with classical algorithms." For healthcare, finance, government, and any system where OAuth tokens and session data are logged and retained, that window is potentially already open.

Realistic migration timelines from independent research are sobering. Small enterprises: five to seven years. Medium: eight to twelve. Large: twelve to fifteen or more. It is April 2026. A medium enterprise starting today is looking at 2034 to 2038 at minimum. That's past NIST's hard deadline. It's well past the point where Google and Cloudflare will have dropped classical algorithm support for significant portions of their infrastructure.

Where NIST Stands

NIST finalized three post-quantum standards in August 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). A fourth, FN-DSA (FALCON), followed. The US government's CNSA 2.0 framework requires software and firmware signing to use PQC algorithms by January 2027. High-priority government systems with harvest-now-decrypt-later exposure must complete migration by end of 2031. Full migration by 2035.

NIST's timeline was set before the March 2026 papers. It hasn't been updated. Google's 2029 deadline is effectively a statement that the government schedule is inadequate given what the research now shows.

The NSA's current target for national security systems is 2030 to 2033. Government contractors are looking at the strictest enforcement. If you're building anything that touches federal systems or their supply chain, the regulatory clock and the threat clock are now running on different speeds.

What the Algorithms Actually Look Like in Code

The NIST-standardized algorithms each solve a specific part of the problem.

ML-KEM (formerly CRYSTALS-Kyber, FIPS 203) handles key encapsulation. You use it where you'd use ECDH today — establishing a shared secret over a public channel. TLS key exchange is the primary use case. Chrome has been running hybrid ML-KEM + X25519 key exchange since 2023. The key exchange problem is largely solved.

ML-DSA (formerly CRYSTALS-Dilithium, FIPS 204) handles digital signatures. You use it where you'd use ECDSA or RSA signatures today — signing certificates, software builds, documents, authentication assertions. The signature sizes are the problem: 2,420 bytes at the lowest security level versus 64 bytes for ECDSA P-256. A certificate chain with ML-DSA at every level is 15kB. Merkle Tree Certificates exist to work around this. They don't fully solve it.

SLH-DSA (SPHINCS+, FIPS 205) is a stateless hash-based signature scheme. It's slower and produces even larger signatures, but its security reduces to the hardness of the underlying hash function. If you need a conservative fallback that doesn't depend on lattice math holding up, this is it.

A minimal hybrid TLS implementation in Python using the cryptography library looks roughly like this for the key exchange side:

# Source: NIST PQC reference implementation examples
# Hybrid key exchange: ML-KEM-768 + X25519
 
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives import hashes, hmac
# ML-KEM requires a PQC-capable library like liboqs-python
import oqs
 
# Classical component
x25519_private = X25519PrivateKey.generate()
x25519_public = x25519_private.public_key()
 
# Post-quantum component
kem = oqs.KeyEncapsulation("ML-KEM-768")
pq_public_key = kem.generate_keypair()
 
# On the sender side: encapsulate against the recipient's public keys
classical_shared = x25519_private.exchange(peer_x25519_public)
ciphertext, pq_shared = kem.encap_secret(peer_pq_public_key)
 
# Combine both shared secrets
# Neither secret alone can compromise the hybrid session
combined = classical_shared + pq_shared
# Derive final session key from combined material via HKDF

Line 17 is the part worth staring at. You're concatenating two independent shared secrets before deriving the final session key. An attacker needs to break both X25519 and ML-KEM to recover the session. Classical computers can't break ML-KEM. Quantum computers can't efficiently break... well, they'd need the quantum computer that doesn't exist yet. This is the defense-in-depth logic behind hybrid approaches, and it's why hybrid is the right default for 2026 migrations rather than PQC-only.

The liboqs library, maintained by the Open Quantum Safe project, is the practical starting point for most developers. It wraps NIST-standardized algorithms with a consistent API and has bindings for Python, Java, C, and Go.

What You Should Actually Do

If you're running backend infrastructure, your immediate action is a cryptographic inventory. You need to know every place you're using RSA, ECDSA, or ECDH. That means TLS termination, certificate signing, code signing, SSH, authentication token signing, and any stored asymmetric key material. Tools like IBM's Quantum Safe Explorer, Veracode's PQC Scanner, and NIST's NCCoE project resources can help automate this for larger stacks.

The priorities follow from the harvest-now-decrypt-later logic. Anything with a long security lifetime goes first. Authentication infrastructure goes before general encryption. If you're protecting session tokens, signing authentication assertions, or generating certificates, those systems need migration plans now. If you're encrypting ephemeral web traffic, the TLS library upgrades will mostly handle you transparently over the next few years as browsers and CDNs mandate PQC handshakes.

Crypto-agility is the architectural goal. Abstract your cryptographic operations through a consistent interface so algorithm changes don't require rewriting applications. Build it as a managed configuration layer, not hard-coded algorithm choices scattered through your codebase. The organizations that built crypto-agility before this moment are executing a managed rollout. Everyone else is looking at emergency remediation when the window closes.

If you're a developer building on top of Cloudflare Workers, Cloudflare Pages, or any other Cloudflare-hosted environment, the encryption side is handled for you already. The authentication side is coming in mid-2026. Update your plans accordingly. If you're building Android apps with custom authentication, start reading Google's documentation on PQC signing updates for the Keystore and Play Store now, not when Android 17 ships.

The Vercel breach earlier this month was a reminder of how authentication chains fail under classical attacks. Quantum just extends the threat surface further backward in time. The argument for moving off passwords and toward cryptographic authentication gets stronger in a post-quantum world, not weaker, as long as the underlying cryptography is quantum-resistant.

The Bigger Picture

Google and Cloudflare committed to 2029. Microsoft said 2033. IBM hasn't said. The NSA said 2030 to 2033. NIST said 2030 to 2035.

Two papers dropped at the end of March and changed what "adequate" looks like. Google and Cloudflare updated their internal models and published new deadlines within weeks. The rest of the industry is still working from timelines set before those papers existed.

The gap between 2029 and 2033 is four years. Given what the Oratomic paper showed about neutral atom architectures and what Google's resource estimates showed about superconducting paths, four years is not a comfortable margin. It is an assumption that the hardware progress that has reduced qubit requirements by five orders of magnitude in twenty years will slow down enough to make 2033 safe.

That assumption might be right. The Oratomic numbers assume a 1-millisecond stabilizer measurement cycle that hasn't been demonstrated at scale. There is legitimate technical debate about when hardware crosses the threshold from "theoretically possible" to "operational."

But cryptographic migrations at enterprise scale take years before Q-Day arrives. Waiting for certainty means migrating under pressure. The math on that trade-off has not improved.

Traven is the lead developer and author at CoderOasis. For more on the post-quantum certificate infrastructure problem and how Merkle Tree Certificates work, read Your HTTPS Is Toast (But Google Has a Plan).