Cloudflare Targets 2029 for Full Post-Quantum Security

For years, the security industry treated Post-Quantum Cryptography as a future challenge rather than an immediate priority. Q-Day, the point at which a cryptographically relevant quantum computer (CRQC) can break RSA and elliptic curve cryptography at scale, was a 2030s problem. Enterprise security teams planned migrations on decade-long runways. Governments issued guidance with soft deadlines. Breaking P-256 with Shor’s algorithm on a superconducting quantum computer was estimated to require millions of physical qubits. As of early 2025, no lab had demonstrated 1,000 fault-tolerant logical qubits. The gap felt wide enough to wait.

That picture started to change in March 2026 when two independent research publications closed the gap faster than expected. One came from Google, the other from researchers at Caltech and the quantum startup Oratomic. Together, the results compressed previously assumed timelines and were enough to move deadlines.

On April 7, 2026, Cloudflare responded by accelerating its post-quantum roadmap, setting 2029 as its target for full post-quantum security, including authentication and not just encryption. Google independently arrived at the same 2029 deadline while IBM Quantum Safe’s CTO declined to rule out targeted quantum attacks as early as 2029.

The industry consensus on timeline has shifted, and the shift is not about encryption alone. The harder migration challenge is authentication: the PKI infrastructure, digital signatures, and long-lived credentials that underpin trust across the entire Internet. This blog breaks down what triggered the acceleration, why authentication is the harder migration, and what your organization needs to prioritize before the window closes.

Two Papers That Moved the Deadline

Breaking classical public-key cryptography with a quantum computer is not a single-variable problem. It requires simultaneous progress on three distinct fronts: quantum hardware, quantum error correction, and quantum algorithms. For years, limitations in each area helped keep Q-Day timelines comfortably in the 2030s. However, two publications in March 2026 challenged that assumption.

1. Google Quantum AI, Ethereum Foundation, and Stanford University

The first came from Google Quantum AI, in collaboration with researchers from the Ethereum Foundation and Stanford University, which published a whitepaper describing a roughly 10x reduction in the spacetime volume required to solve the elliptic curve discrete logarithm problem on secp256k1, a 256-bit curve. Spacetime volume is the product of logical qubits and non-Clifford gate count, where Toffoli gates serve as the standard unit of computation cost, and it is the primary driver of physical resource overhead in fault-tolerant quantum computing.

In physical qubit terms, this represents approximately a 20-fold reduction over prior best estimates for ECDLP-256. Their low-qubit variant estimates no more than 1,200 logical qubits and 90 million Toffoli gates; their low-gate variant estimates no more than 1,450 logical qubits and 70 million Toffoli gates.

On a superconducting architecture with physical error rates of 10^-3, either path executes in minutes on a machine with fewer than 500,000 physical qubits. Google chose not to publish the actual attack circuits, reasoning that doing so would constitute a partial blueprint for adversaries. Instead, they verified the improvement using a zero-knowledge proof.

2. Caltech and Oratomic

The second came from researchers at Caltech and the quantum startup Oratomic, who explored the same problem from a different direction. Their work focused on estimating the physical qubit cost of running Shor’s algorithm against 256-bit elliptic curves and RSA-2048 on a neutral atom platform. Their time-efficient architecture breaks a 256-bit elliptic curve target in approximately 10 days using around 26,000 physical qubits, and RSA-2048 in approximately 97 days using around 102,000 physical qubits.

A space-efficient variant reaches the same 256-bit target with roughly 10,000 physical qubits, though at a runtime of approximately three years, making it relevant only for long-lived keys sitting in dormant systems. These numbers are roughly 50 to 100 times fewer physical qubits than prior estimates on superconducting architectures. While the paper remains a preprint and relies on hardware advances that have yet to be demonstrated, it reinforced the broader trend identified Google Quantum AI’s work: the resource requirements for breaking widely deployed cryptography may be falling faster than expected. Because the paper is unreviewed, the qubit estimates should be treated as a directional lower bound rather than a confirmed capability.

The efficiency gap comes from error correction overhead. Superconducting architectures need roughly 1,000 physical qubits per logical qubit to manage noise and limited qubit connectivity. Neutral atom machines use reconfigurable arrays where qubits can be repositioned during computation, which theoretically reduces error correction overhead to as few as 3 to 4 physical qubits per logical qubit under high-rate code assumptions, though this has not yet been demonstrated at cryptographically relevant scale. That is a difference of two to three orders of magnitude in physical resource cost if those theoretical targets are achieved.

Oratomic did not publish all the technical details, following responsible disclosure practices. Other researchers have also noted that the fastest version of their approach depends on hardware capabilities that have not yet been demonstrated at scale.

Why These Breakthroughs Hit Harder Together

Progress across the three fronts of quantum computing is interconnected. Better algorithms reduce the gate count required, which lowers the hardware burden. Better error correction reduces the physical qubit overhead per logical qubit. Better qubit connectivity reduces the cost of error correction itself.

The 2025 to 2026 period saw meaningful movement on all three at once: neutral atom scalability improved, reconfigurable connectivity cut error correction costs sharply, and Google’s algorithmic result cut the gate count for secp256k1 by an order of magnitude. When multiple fronts advance in parallel, the combined effect on resource estimates is multiplicative, not additive. That is what drove Cloudflare, Google, and IBM to revise their threat timelines within weeks of each other.

Cloudflare’s Post-Quantum Journey So Far

Cloudflare’s post-quantum migration did not begin with this announcement. The company has been working toward a post-quantum Internet since 2014, building each layer of the migration incrementally.

• 2014: Launched free universal SSL certificates, establishing encrypted-by-default as a baseline across millions of websites.
• 2019: Began post-quantum migration work in TLS, tracking NIST’s standardization process and testing early algorithm candidates.
• 2022: Enabled post-quantum encryption for all websites and APIs served by Cloudflare, mitigating Harvest Now, Decrypt Later (HNDL) attacks by default.
• 2026: Accelerated the roadmap to a 2029 full post-quantum target, with post-quantum authentication added as an explicit requirement.

As of the April 7, 2026 announcement, over 65% of human traffic to Cloudflare is already post-quantum encrypted. That covers the confidentiality half of the problem. The 2029 roadmap targets the other half: authentication. Protecting data in transit and verifying identity are solved through different mechanisms, face different migration challenges, and carry different consequences when they fail.

Authentication: The Deeper Half of the Problem

The industry’s initial PQC focus was on encryption, and for good reason: HNDL attacks are assumed to be already underway. But as Q-Day moves closer, the more consequential exposure shifts to authentication. Encryption protects what is being said. Authentication determines who is trusted to say it. When that trust layer breaks, the damage is not passive data exposure. It is active, real-time compromise.

Authentication answers a set of questions the Internet relies on constantly: is this server who it claims to be? Is this software update genuinely from the vendor? Is this API credential legitimate? Today, the answers to those questions rest on RSA and ECDSA digital signatures. Both are broken by Shor’s algorithm on a CRQC, a quantum computer operating with enough fault-tolerant logical qubits to run Shor’s algorithm against real-world key sizes at practical speed. An adversary who can forge those signatures does not need to intercept traffic. They can walk through the front door.

The attack surface that opens up is broad:

• Server impersonation: A forged TLS certificate for any domain makes the attacker a trusted man-in-the-middle, invisible to the client.
• Code signing compromise: Any software update mechanism using a quantum-vulnerable signing key becomes a remote code execution vector. The attacker signs malicious code with a forged key that every endpoint trusts.
• Root certificate compromise: Root CA keys are long-lived, often for decades. Forging against a root CA allows the attacker to issue trusted certificates for any domain globally.
• Persistent access via forged credentials: API keys, access tokens, and session credentials become forgeable. Unlike an HNDL attack, which is passive and retrospective, authentication attacks are active, real-time, and persistent.

As Cloudflare’s team noted directly: broken authentication is catastrophic where data leakage is merely severe. An adversary needs only one trusted quantum-vulnerable key to get in the front door.

Why long-lived keys are the first target

First-generation CRQCs will be expensive and scarce. Compute will not be spent on session keys that expire in minutes. The realistic target set is keys that hold persistent value: root certificates with 20-year lifetimes, code signing certificates distributed to millions of endpoints, and Hardware Security Module (HSM)-protected API keys embedded in critical infrastructure. A single compromised root CA or widely trusted code-signing key propagates damage across every system that trusts it downstream.

Google’s Sophie Schmieg has publicly compared a scenario where a covert CRQC silently breaks authentication systems to Enigma’s cryptanalysis, a capability that changes the course of events before anyone realizes it is being used.

The NIST Standardized Algorithms

NIST has been building the post-quantum standards portfolio in stages. The first three standards were finalized in August 2024: ML-KEM (FIPS 203) for key encapsulation, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. Two more are in active standardization. FN-DSA, based on the Falcon algorithm, is a compact-signature alternative currently progressing toward FIPS 206. HQC, selected in March 2025, is a code-based backup KEM for ML-KEM, providing algorithmic diversity in case lattice-based key encapsulation is later found vulnerable, with finalization targeted for 2027.

Standard	Algorithm	Type	Primary Use Case	Security Category	Status
FIPS 203	ML-KEM (Kyber)	Lattice-based	Key exchange	1, 3, 5	Finalized (Aug 2024)
FIPS 204	ML-DSA (Dilithium)	Lattice-based	Digital signatures	2, 3, 5	Finalized (Aug 2024)
FIPS 205	SLH-DSA (SPHINCS+)	Hash-based	Long-term / high-assurance signatures	1, 3, 5	Finalized (Aug 2024)
FIPS 206	FN-DSA (FALCON)	Lattice-based	Compact signatures	TBD	Draft
HQC	HQC	Code-based	Backup KEM	1,3,5	Selected (Mar 2025)

For authentication migration, ML-DSA and SLH-DSA are the production-ready standards today. ML-DSA is the primary lattice-based signature scheme, offered at three security categories: ML-DSA-44 (security category 2), ML-DSA-65 (security category 3), and ML-DSA-87 (security category 5). At security category 2, ML-DSA-44 produces a 2,420-byte signature and a 1,312-byte public key. ECDSA P-256, for reference, produces a 64-byte signature and a 33-byte public key.

That gap in size has direct consequences for certificate chain lengths, TLS handshake overhead, and systems with message size or latency constraints that were never designed with post-quantum in mind. SLH-DSA grounds its security entirely in hash function hardness rather than lattice mathematics, a more conservative assumption, at the cost of larger signatures: 17,088 bytes at security category 1 for the fast variant.

FN-DSA, once finalized, will offer a compact middle ground with smaller signatures than ML-DSA and a distinct underlying security assumption, making it relevant for constrained or bandwidth-sensitive environments. HQC’s role is confined to key encapsulation; it does not replace or supplement post-quantum signature algorithms. However, organizations building crypto-agile systems should account for KEM algorithm diversity in their hybrid handshake designs.

The algorithms are defined, standardized, and available. Regulatory frameworks including CNSA 2.0 and FIPS 140-3 validation requirements add further constraints on which algorithms and implementations are acceptable in specific deployment contexts. What takes time is everything built around them.

The Migration Dependency Chain

PKI authentication is not a single system with a single upgrade path. It is a chain of dependent components, each of which must be migrated before the next one can follow. That sequential structure is what makes the timeline tight.

• Root CA keys: Root CA keys must be rotated, or new post-quantum root CAs must be issued. This requires trust store updates across operating systems and browsers, a multi-year process with no single controlling authority.
• Intermediate CA certificates: Once post-quantum root CAs are in place, intermediate CA certificates must be reissued carrying post-quantum public keys and signed with post-quantum algorithms. Any intermediate still signed under a classical key remains a weak link in the chain.
• End-entity certificates: TLS server certificates, code signing certificates, and client authentication certificates must all be reissued under the updated post-quantum hierarchy. This covers the broadest surface area and the largest operational volume.
• Relying party software updates: TLS libraries, certificate validators, OCSP and CRL consumers, and HSM firmware must support post-quantum signature algorithms before the certificates they validate will function. Deploying post-quantum certificates into an environment whose validators cannot process them does not improve security. It breaks connectivity.
• Downgrade protection enforcement: Adding post-quantum algorithm support is not sufficient on its own. Systems must also disable support for quantum-vulnerable algorithms to be secure against downgrade attacks, where an adversary forces negotiation back to a classical cipher suite the server still offers. For public-facing HTTPS, a hard cutover is not immediately feasible because legacy clients that do not yet support post-quantum certificates cannot simply be dropped.

In this context, certificate transparency and strict cipher suite negotiation policies provide a practical path to enforcing downgrade protection progressively, without immediately breaking legacy clients. For internal systems with a controlled client estate, PQ-only TLS policy can and should be enforced as soon as the client estate is fully updated.

• Credential rotation: Once downgrade protection is enforced, any passwords, tokens, or session credentials that transited quantum-vulnerable connections must be treated as potentially exposed and rotated. This step cannot begin until downgrade protection is fully in place, and skipping it leaves a residual exposure even after the infrastructure is fully migrated.

Each step depends on the previous one. None can be skipped. This is why the migration to post-quantum authentication takes time, and why starting in 2026 to meet a 2029 target is already tight.

Where to Start Before the Window Closes

The 2029 deadline is Cloudflare’s internal target for its own infrastructure. For most organizations, 2029 is close enough that migration must begin immediately, and the dependency chain is long enough that organizations starting today will be pressed to finish in time.

• Build a cryptographic asset inventory: You cannot migrate what you have not catalogued. Map every cryptographic key, certificate, algorithm, and other cryptographic assets across your environment. Identify all RSA and ECDSA usage across TLS certificates, code signing infrastructure, SSH keys, API authentication mechanisms, VPN configurations, JWT signing keys, and hardware-bound keys in HSMs. Prioritize by key lifetime and blast radius. Long-lived keys protecting high-value or widely trusted systems come first.
• Address authentication if HNDL mitigation is already underway: If post-quantum key exchange is already active in your TLS stack, the HNDL exposure is largely managed. Move attention to post-quantum certificates, digital signatures, and credential authentication. That is where the remaining critical risk sits and where the dependency chain is longest.
• Map your PKI dependency chain: Identify your full CA hierarchy: root CAs, subordinate CAs, and issuing CAs. Determine which HSMs support ML-DSA and SLH-DSA natively and which require firmware updates or replacement. Verify your certificate lifecycle management tooling’s readiness for post-quantum algorithms. Get concrete migration timeline commitments from your CA vendors, not roadmap intentions.
• Test before you deploy: ML-DSA signatures are roughly 38 to 72 times as large as ECDSA P-256 signatures, depending on the security category, with public keys also growing substantially and chain depth multiplying that overhead across each certificate in the hierarchy. Run post-quantum algorithm testing in non-production environments first. Measure the impact on certificate chain sizes, TLS handshake performance, and any system with message size or latency constraints. Find the integration points that need code changes before they surface in production.
• Audit third-party dependencies: As Cloudflare noted directly, Q-Day threatens all systems, not just the ones you control. A complete internal migration is still exposed if a critical vendor, SaaS platform, or infrastructure dependency retains quantum-vulnerable authentication. Identify those dependencies now and get their post-quantum roadmap commitments on record.
• Plan for credential rotation: Once downgrade protection is enforced, all passwords, tokens, and session credentials that previously transited quantum-vulnerable connections must be treated as potentially exposed and rotated. This is not a cleanup step at the end of the migration. It is a planned phase that needs to be scoped and resourced from the beginning.

How EC Can Help

For most organizations, building a complete cryptographic inventory and migrating to post-quantum cryptography cannot be done with existing tooling and internal capacity alone. Encryption Consulting works with enterprises at every stage of this process, from initial discovery through full PQC migration, with PQC Advisory service and purpose-built tooling designed specifically for the complexity of real enterprise PKI environments.

PQC Advisory Service

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, we conduct a PQC Risk Assessment to evaluate your exposure to quantum threats, identify RSA and ECC dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.

We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.

Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe algorithms, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.

With this structured approach, you move from cryptographic uncertainty to a documented, policy-driven migration program aligned to NIST timelines and your regulatory obligations.

CBOM Secure

A successful post-quantum transition begins with visibility. Organizations cannot modernize cryptography if they do not know where certificates, keys, algorithms, and cryptographic dependencies exist across their environment.

Encryption Consulting’s CBOM Secure provides a continuous view of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services. Rather than producing a point-in-time inventory, it helps organizations understand how cryptography is being used, where it is deployed, and how it changes over time.

CBOM Secure continuously discovers and tracks certificates, keys, algorithms, and cryptographic dependencies across the enterprise. It provides visibility into asset ownership, certificate and key relationships, algorithm usage, lifecycle events, and cryptographic exposure, helping teams identify unmanaged assets, deprecated algorithms, and systems that may require modernization.

The platform also supports policy-driven governance by validating cryptographic configurations against organizational standards and highlighting deviations before they become operational or compliance risks.

For organizations preparing for post-quantum cryptography, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms and provides the visibility needed to prioritize remediation and migration activities. More broadly, it enables organizations to establish continuous cryptographic governance and build the operational foundation required for long-term crypto-agility.

A note worth making explicitly: CBOM Secure is not the same thing as a CBOM. A CBOM (Cryptographic Bill of Materials) is a structured artifact, a record of the cryptographic components in a given application or system. CBOM Secure generates and consumes CBOM data, but it also performs continuous discovery and runtime inventory management across the full enterprise environment. The distinction matters because a CBOM alone tells you what was built into an application at a point in time. CBOM Secure tells you what is actually running, where it is running, and how it is changing.

Whether your organization is starting from scratch with no formal inventory in place or is looking to operationalize an existing discovery effort into a continuous governance program, Encryption Consulting brings both the advisory depth and the platform capability to move you forward. To learn more about our PQC Advisory Services or CBOM Secure, visit encryptionconsulting.com or reach out to our team directly.

Conclusion

Cloudflare’s 2029 target is not a response to regulatory pressure or a scheduled roadmap update. It came directly from two research publications that, taken together, showed the physical resource requirements for a CRQC attacking elliptic curve cryptography are lower than the industry had modeled, and that progress on hardware, error correction, and algorithms is converging faster than expected.

The most significant shift in this announcement is not the timeline. It is the priority. Encryption migration addresses a threat assumed to be already underway in the form of HNDL attacks. Authentication migration addresses a threat that, when it arrives, will be active, real-time, and systemic. A quantum adversary who can forge authentication credentials does not need to intercept traffic. They already have access.

Long-lived keys are the first target: root certificates, code signing infrastructure, and persistent API credentials. The dependency chain to migrate them is sequential and cannot be compressed. 2029 is Cloudflare’s target for completing its own post-quantum cryptography migration, not a universal deadline, but a signal of how seriously the threat timeline has shifted. For most organizations, the dependency chain is long enough that early action is the difference between a managed migration and a rushed one.