Google and Cloudflare Move Post-Quantum Deadline to 2029
Google and Cloudflare just pulled their post-quantum cryptography deadlines forward to 2029. Here's what changed and what TLS engineers should do now.
Two weeks ago, if you asked a cryptographer when the post-quantum cryptography transition had to finish, the answer was 2031 (the NSA’s CNSA 2.0 benchmark) or 2035 (the wider federal one). This month that answer moved. Google announced a 2029 deadline to migrate its products. Cloudflare followed days later with a matching commitment and took on the part most vendors have been quietly avoiding: authentication. If you run TLS at any serious scale, those roadmaps became yours whether you signed up for them or not.
A paper, not a quantum computer
No one built a cryptographically relevant quantum computer in March. What happened was a paper. Google’s Quantum AI team published updated resource estimates for breaking ECDSA-256 and RSA-2048 with Shor’s algorithm, and the numbers fell by roughly 20x on both qubit count and runtime compared to the community’s earlier models. A separate group working on reconfigurable neutral-atom arrays reached similar conclusions from a different starting point. The hardware still isn’t there. Nobody is getting decrypted tomorrow. But the theoretical distance between here and a machine that matters shrank faster than anyone modeled, and “harvest now, decrypt later” is now a real calendar problem for anyone guarding twenty-year secrets.
Google’s response was to jump ahead of its own federal reporting requirements. Cloudflare’s was a roadmap with dates attached. ML-DSA signatures on Cloudflare-to-origin connections arrive mid-2026. Merkle Tree Certificates for visitor-to-edge authentication follow mid-2027. Post-quantum authentication lands in the Cloudflare One SASE stack by early 2028. By 2029 everything is PQ-secure by default, no opt-in flag or surcharge.
Where TLS actually stands
Key exchange is in decent shape. The hybrid X25519MLKEM768 group, which bolts classical X25519 to NIST’s ML-KEM-768 (FIPS 203), already runs on a meaningful share of traffic to Google, Cloudflare, Meta, and most of the major CDNs. Chrome, Edge, and Firefox negotiate it by default whenever the server offers it. If you’re on OpenSSL 3.5, a recent BoringSSL, current rustls, or an up-to-date Go crypto/tls, you may already be doing post-quantum key exchange in production without noticing.
Authentication is where the handshake starts to hurt. Server certificates still sign with RSA or ECDSA, and the NIST replacements are much larger. An ML-DSA-65 signature (FIPS 204) runs about 3.3 KB. An ECDSA-P256 signature fits in 64 bytes. Stack a full chain, an OCSP staple, and a few SCTs on top, and the first flight of the handshake starts to resemble a small HTML page. Cloudflare is betting on Merkle Tree Certificates, which batch signatures across many certificates so the per-connection cost stays bearable. Expect the next eighteen months of IETF TLS and LAMPS work to orbit that problem.
Things worth doing this quarter
Start with inventory. You cannot migrate what you haven’t mapped. CISA’s Cryptographic Bill of Materials guidance is a reasonable template, and the NCCoE migration playbooks fill in the operational gaps. Long-lived keys, embedded devices, and firmware signing workflows are where the migration bites earliest, because anything with a replacement cycle measured in years stays painful the longest.
Then turn on hybrid key exchange wherever you own both endpoints. For origin servers behind Cloudflare, internal load balancers, and service meshes, enabling X25519MLKEM768 costs a few hundred extra bytes per handshake and shrinks the harvest-now window for every bit of traffic crossing it. Most modern TLS libraries put this behind a single config flag. I have yet to hear a good reason to leave it off.
Start thinking about certificate rotation now, too. The CA/Browser Forum’s new 47-day maximum certificate lifetime goes into full effect in 2029, the same year Google wants to be done migrating. Both changes push the same direction: fully automated issuance and rotation. If a human at your shop still clicks through CSR generation once a year, that workflow is the most likely to fall over first when either deadline lands.
Revise the spreadsheet
2029 is not a prediction of Q-Day. It is an operational deadline that two companies with an outsized view of global TLS traffic decided they could meet, and that their customers and browser partners will inherit by default regardless of what anyone else planned. If your migration plan still quietly assumes 2031, or 2035, this is the week to update the timeline column. The standards are mostly finished. The infrastructure giants already moved. What remains is the work that has been getting postponed for the last three years.