Skip to content

CLOUDFLARE 2026-04-07 Tier 1

Read original ↗

Cloudflare targets 2029 for full post-quantum security

Summary

Cloudflare publishes an updated Q-Day risk assessment and an accelerated roadmap: full post-quantum security across the entire product suite including authentication by 2029. The shift is driven by three independent advances reported in the month before the post — Google's undisclosed algorithmic breakthrough against elliptic-curve cryptography (proven by zero-knowledge proof only), Oratomic's resource estimate showing RSA-2048 / P-256 breakable on a 10,000-qubit neutral-atom computer, and Google's own migration timeline moving to 2029 with explicit priority on quantum-secure authentication. IBM Quantum Safe's CTO can no longer rule out quantum moonshot attacks on high-value targets as early as 2029. The post inverts the industry's historical priority order: once Q-Day is imminent, authentication (not encryption) is the urgent threat — an adversary with a CRQC can impersonate servers and forge credentials, and any overlooked quantum-vulnerable long-lived key is a front-door access point. Cloudflare publishes intermediate milestones and prescribes concrete posture for enterprises, governments, and its own customers.

Key takeaways

  • Q-Day pulled forward by three independent advances. In one week: (a) Google announced a major speed-up to the quantum algorithm for cracking elliptic-curve cryptography, disclosing only a zero-knowledge proof of the algorithm — not the algorithm itself — to avoid handing it to adversaries; (b) Oratomic published a resource estimate for breaking RSA-2048 / P-256 on a neutral-atom quantum computer, requiring a shockingly low 10,000 qubits; (c) Google moved its own migration timeline to 2029. IBM Quantum Safe's CTO can no longer rule out quantum moonshot attacks on high-value targets as early as 2029. (Source: Cloudflare post, citing Google Research / Oratomic / IBM / Sophie Schmieg's RWPQC 2026 talk)

  • Progress on CRQCs compounds across three independent fronts — hardware (neutral atoms, superconducting qubits, ion traps, photonics, topological qubits; many pursued by multiple labs in parallel), error correction (Oratomic showed reconfigurable neutral-atom qubits need only 3-4 physical qubits per logical qubit, vs ~1,000 for nearest-neighbor superconducting), and software / algorithms (Google's undisclosed speed-up against P-256). A breakthrough on any one compounds the others; ignoring it requires assuming every hardware approach hits a wall.

  • Public progress will go dark. Quoted Scott Aaronson (end of 2025): "at some point, the people doing detailed estimates of how many physical qubits and gates it'll take to break actually deployed cryptosystems using Shor's algorithm are going to stop publishing those estimates, if for no other reason than the risk of giving too much information to adversaries. Indeed, for all we know, that point may have been passed already." Cloudflare states flatly: "That point has now passed indeed."

  • HNDL vs authentication — the priority flip. When Q-Day is far away, the dominant threat is harvest-now-decrypt-later (adversary captures encrypted traffic today, decrypts it years later on a CRQC) and the right response is post-quantum encryption. Cloudflare has done this: PQ hybrid key-agreement on by default since 2022; >65 % of human traffic to Cloudflare is currently post-quantum encrypted (source). When Q-Day is imminent, the dominant threat is authentication — an attacker with a CRQC impersonates servers and forges credentials. "Any overlooked quantum-vulnerable remote-login key is an access point… Any automatic software-update mechanism becomes a remote- code-execution vector."

  • Long-lived keys first. If early CRQCs are scarce and expensive, attackers will concentrate them on high-value persistent-access keys — root CAs, API auth keys, code-signing certificates, federation trust anchors. One compromised long-lived key grants indefinite access until revocation. The calculus flips if CRQCs become fast and cheap (later-generation neutral-atom machines); then attackers revert to HNDL because individual-key attacks stay undetected. Sophie Schmieg's analogy (RWPQC 2026): Enigma cryptanalysis in WWII — the attacker who keeps the break secret reshapes history.

  • Adding PQ is not enough — you must disable the classical primitives to prevent downgrade attacks. Not feasible for open federated systems (browsers, the public web), so the industry is adopting PQ HSTS and/or certificate transparency- based downgrade protection instead (Chromium PQ auth roadmap, Bas Westerbaan RWPQC 2026 slides).

  • Post-migration: rotate every secret. Once quantum-vulnerable cryptography is disabled, all secrets previously exposed through it (passwords, access tokens, API keys) must be rotated — because an attacker with prior captures could have already derived them. Captured in the disable- legacy-before-rotate pattern.

  • Authentication migration takes years, not months. Unlike PQ encryption (one big push — client + server both support the hybrid, negotiate, done), PQ authentication has a long dependency chain: certificate issuance, cross-signing, trust-anchor updates, fraud- monitoring, third-party validation, HSM firmware, federated-login IdPs. Cloudflare's explicit framing: "this effort will take on the order of years, not months."

  • Third-party / indirect dependencies are now in scope. "Q-day threatens all systems. [...] it's important to understand the impact of a potential Q-day on third-party dependencies, both direct and indirect. Not just the third-parties you speak cryptography to, but also any third parties that are critical business dependencies like financial services and utilities." Captured in the third-party-dependency quantum assessment pattern.

  • Cloudflare's intermediate milestones (from the post's roadmap diagram, subject to change):

  • Mid-2026: PQ authentication ( ML-DSA) support for Cloudflare → origin connections.
  • Mid-2027: PQ authentication support for visitor → Cloudflare connections, using Merkle Tree Certificates.
  • Early 2028: Cloudflare One SASE suite adds PQ authentication → fully PQ secure.

  • 2029: Cloudflare fully post-quantum secure (encryption + authentication, entire product suite).

  • Posture recommendations by audience:

  • Businesses: make PQ support a procurement requirement; keep software updated; automate certificate issuance; assess critical vendors early for what their inaction would mean.
  • Governments / regulators: "fragmentation in standards and effort between and within jurisdictions could put progress at risk" — assign and empower a lead agency to coordinate on a clear timeline, promote existing international standards over jurisdiction-specific ones.

  • Cloudflare customers: no mitigation action needed on Cloudflare-controlled sides; upgrades will be default-on at no additional cost, "no switches to flip." Customers must still upgrade browsers / applications / origins they control.

  • Strategic principle — default-on security upgrade at no additional cost. "Free TLS helped encrypt the web. Free post-quantum cryptography will help secure it for what comes next." Continuation of the 2014 Universal SSL + 2022 PQ-for-all posture (concepts/defense-in-depth meets economic friction removal).

Operational numbers

  • >65 % of human traffic to Cloudflare is currently post-quantum encrypted (radar.cloudflare.com/post-quantum).
  • 10,000 qubits — Oratomic's resource estimate for breaking P-256 on a neutral-atom computer.
  • 3-4 physical qubits per logical qubit on reconfigurable neutral-atom machines (vs ~1,000 on nearest-neighbor superconducting) — the error-correction factor that collapses Q-Day estimates.
  • 2029 — Cloudflare's target for full post-quantum security (encryption + authentication, entire product suite); also Google's migration target and IBM Quantum Safe's earliest moonshot-attack non-exclusion.
  • 2030 — Google's implied Q-Day concern horizon, inferred from its authentication-over-HNDL priority flip.
  • Mid-2026 / Mid-2027 / Early 2028 / 2029 — Cloudflare's four announced milestones.
  • 2014 → 2019 → 2022 → 2026 → 2029 — the Cloudflare PQ timeline: free Universal SSL → started preparing PQ migration → enabled PQ encryption for all websites/APIs → updated risk assessment → full PQ secure.

Systems extracted

  • Cloudflare Universal SSL (2014) — the 2014 free-TLS-for-all program; the historical precedent the post invokes for why PQ will also be free and default-on.
  • Cloudflare One — the SASE suite; explicitly flagged as the product whose PQ-auth upgrade gates the "2029 fully PQ secure" claim.
  • Merkle Tree Certificates — the specific cert-issuance mechanism Cloudflare plans to deploy in Mid-2027 for visitor→Cloudflare PQ authentication.
  • ML-DSA (NIST FIPS 204, formerly Dilithium) — the specific PQ signature algorithm named for the Mid-2026 Cloudflare→origin deployment.
  • PQ HSTS — browser-ecosystem downgrade- protection mechanism being worked on at Chromium.
  • Certificate Transparency — alternative downgrade-protection surface for PKI.

Concepts extracted

  • Q-Day — the day a CRQC can break currently- deployed asymmetric cryptography. Canonical wiki instance.
  • CRQC — quantum computer capable of running Shor's algorithm on deployed key sizes. Progress compounds on hardware + error correction + software.
  • Harvest-Now-Decrypt-Later (HNDL) — the historically-dominant threat model. Canonical expansion.
  • Post-quantum authentication — the newly-dominant threat: impersonation + forgery rather than retroactive decryption. Introduced.
  • Downgrade attack — the generic pattern that forces the "disable classical" step to follow "enable PQ". Introduced.
  • Long-lived-key risk — attackers prioritize persistent-access keys under scarce-CRQC conditions; priority inverts under fast-CRQC. Introduced.
  • Zero-knowledge proof — Google's disclosure channel for proving it has the algorithm without revealing it. Introduced.
  • Threat modeling — the discipline reshuffling itself: "what's at risk first" flipped from confidentiality (HNDL) to authentication (CRQC-enabled impersonation).

Patterns extracted

  • Disable legacy crypto before rotating secrets — the two-step sequence for migrating an installed base: stop accepting quantum-vulnerable primitives, then rotate every secret that was ever negotiated through them. Introduced.
  • Third-party dependency quantum assessment — include indirect dependencies (financial services, utilities) not only direct-crypto counterparties in the migration scope. Introduced.
  • Default-on security upgrade at no additional cost — ship security improvements as universal platform capability rather than paid feature. Cloudflare's consistent posture (2014 Universal SSL → 2022 PQ-for-all → 2029 PQ-auth-for-all). Introduced.
  • Protocol algorithm negotiation — existing pattern; invoked as the rollout mechanism that makes enabling PQ painless but fails to help with disabling classical primitives on a federated installed base.

Caveats

  • The post is a roadmap + threat-assessment update, not a technical architecture deep-dive. Intermediate-milestone details (which exact ML-DSA parameters, which Merkle-tree-cert deployment model, how PQ HSTS interacts with existing HSTS) are linked but not specified in-post.
  • The Oratomic 10,000-qubit number is the post's headline figure but Oratomic omits crucial implementation details on purpose (responsible-disclosure statement). The estimate is architecture-specific (neutral atoms + their error- correction approach) and doesn't translate directly to other hardware.
  • Google's algorithm disclosure is a zero-knowledge proof, meaning the wider community cannot independently evaluate the speed-up. Timeline compression is based on trust in Google's proof — a meaningful epistemic step.
  • IBM's "can't rule out 2029 moonshot attacks" is a bound on the earliest-possible threat, not a prediction; moonshot is explicitly defined as one-off-high-value, not scalable key- cracking.
  • The post's audience-specific prescriptions (businesses / governments / customers) are policy recommendations, not deployment documentation. Customers still have homework on the sides of the connection Cloudflare doesn't control (browsers, applications, origins).
  • Certificate Transparency as downgrade protection is referenced as a Cloudflare-authored direction (Bas Westerbaan's RWPQC 2026 slides) but specific deployment mechanics are slide-deck-only in this post.

Source

Last updated · 200 distilled / 1,178 read