Google Just Moved Its Quantum Deadline to 2029

Your cryptography migration roadmap probably says 2035. Google’s doesn’t anymore. On March 25, 2026, Google set a new post-quantum cryptography 2029 deadline for its own systems, six years ahead of the federal backstop most enterprise security teams have been planning around for the past two years.

That’s not a marketing decision. It’s a response to math. Six days later, Google Research published the resource estimates behind it, and they’re the kind of numbers that make a CISO reread an email twice (and then forward it straight to the budget committee).

If you’re responsible for cryptographic risk at your organization, here’s exactly what happened, what the new research means and doesn’t mean, and what NIST’s separate, still-unfinished post-quantum cryptography deadline requires of you in the meantime.

The Announcement That Moved the Goalposts

Google’s announcement came from Heather Adkins, VP of Security Engineering, and Sophie Schmieg, Senior Staff Cryptography Engineer, in a post titled “Quantum frontiers may be closer than they appear.”

“We’re setting a timeline for post-quantum cryptography migration to 2029.” Heather Adkins & Sophie Schmieg, Google Security Engineering

That’s a specific, internal, engineering-driven deadline, not a regulatory mandate. Google ties it directly to faster than expected progress in quantum hardware, error correction, and updated estimates of what it actually takes to break current encryption standards.

The first concrete product step: Android 17 is integrating ML-DSA-based digital signature protection, on top of post-quantum support already shipping in Chrome and Google Cloud. Google is treating signature and authentication migration as the more time-sensitive half of the problem, ahead of encryption. The logic is straightforward once you sit with it: forging a signature only requires the attacker to break the math at the moment of the attack, so there’s no advance window. Encrypted data, by contrast, can be captured and stored today, then decrypted years later once the hardware catches up, which is the harvest-now, decrypt-later risk we’ll come back to in a moment. Both problems are urgent. They’re just urgent on different clocks.

The Math That Convinced Google to Move Early

Six days after the deadline announcement, on March 31, 2026, Google Research published the paper that explains why. Ryan Babbush, Director of Research for Quantum Algorithms, and Hartmut Neven, VP of Engineering at Google Quantum AI, laid out two optimized quantum circuits for solving the elliptic curve discrete logarithm problem at the 256-bit security level, the math underneath ECDSA, the signature scheme securing most TLS connections, SSH sessions, code signing, and the majority of cryptocurrency wallets, including Bitcoin and Ethereum.

The numbers: one circuit uses fewer than 1,200 logical qubits and roughly 90 million Toffoli gates. The second uses fewer than 1,450 logical qubits and about 70 million Toffoli gates. Run on a superconducting quantum computer, Google estimates either circuit could complete the attack with fewer than 500,000 physical qubits in a matter of minutes, an approximately 20-fold reduction from prior estimates of what the attack would require.

It’s not an isolated revision either. Craig Gidney, also at Google Quantum AI, updated his RSA-2048 factoring estimate in 2025 to under 1 million physical qubits and less than a week of runtime, down from his own 2019 estimate of 20 million qubits and roughly eight hours. Same researcher, same category of algorithm, same order-of-magnitude drop. Two separate 20-fold reductions in attack-resource estimates, from the same research group, inside a single decade, is arguably more significant than either individual number. That’s the trend that moved Google’s internal calendar, not one paper.

One more detail worth knowing: Google didn’t publish the actual attack circuits. It used a zero-knowledge proof, developed in coordination with the U.S. government, that lets outside researchers verify the resource estimate without releasing a usable attack blueprint, an approach modeled on standard coordinated vulnerability disclosure practice.

NIST’s Slower, Still-Unfinished Deadline

Google’s 2029 timeline is the freshest news, but the post-quantum cryptography schedule most compliance teams actually have to plan against still comes from NIST. NIST finalized its first three post-quantum standards back in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a hash-based signature scheme). A fourth standard, FIPS 206, based on the Falcon algorithm, is still in draft and isn’t expected to finalize until late 2026 or early 2027. A fifth, HQC, selected as a backup key-encapsulation method in March 2025, won’t see a final standard until 2027 at the earliest.

The 2030 and 2035 dates you’ve probably seen cited everywhere actually come from a separate document, NIST Internal Report 8547, which proposes deprecating 112-bit-security algorithms like RSA-2048 and ECC P-256 by 2030, and disallowing all quantum-vulnerable public-key algorithms by 2035. Here’s the part that doesn’t get repeated often enough: IR 8547 is still an initial public draft. It was released in November 2024, public comment closed in January 2025, and it has not been finalized as of this writing. Treat the 2030 and 2035 dates as the most likely outcome of an open process, not as settled law, especially if your organization sits outside direct U.S. federal scope.

National security systems run on a separate, tighter clock. The NSA’s CNSA 2.0 guidance sets preference dates as early as 2025 for some categories, required adoption between 2030 and 2033, and full quantum resistance by 2035, with ML-KEM-1024 and ML-DSA-87 specified as the mandated parameter sets. If you’re a defense contractor or anywhere in that supply chain, this is the schedule that actually governs you, not IR 8547.

Where Other Governments Stand

Canada, the EU, and the UK are each running parallel post-quantum cryptography tracks, on slightly different clocks. If your organization operates across any of these jurisdictions, the deadline that matters is whichever one applies to your weakest-governed system, not the most generous one.

Not Everyone Is Convinced This Is Urgent

Worth saying plainly: no quantum computer capable of breaking today’s public-key encryption exists yet. CISA’s own Post-Quantum Cryptography Initiative says so directly, while still flagging harvest-now-decrypt-later as a present-tense risk for long-lived data. Both statements are true at the same time, which is exactly why the expert debate over urgency hasn’t settled.

Scott Aaronson, the Schlumberger Centennial Chair of Computer Science at the University of Texas at Austin and one of quantum computing’s most consistent public skeptics, wrote in comments reported in early May 2026 that people whose hardware judgment he trusts more than his own now think a fault-tolerant, attack-scale quantum computer “ought to be possible by around 2029.” That’s a notable shift for Aaronson. It’s also worth knowing his own caveat: an earlier prediction of his would technically count as fulfilled even by a trivial demonstration, like factoring 15 into 3 times 5, a calculation a human can do faster by hand than any quantum computer currently running. Most headline coverage drops that part.

Matthew Green, a cryptography professor at Johns Hopkins University, takes a more grounded stance. In comments reported by CyberScoop in April 2026, Green called the recent research a useful precautionary exercise, but questioned whether quantum computing has enough near-term, lucrative applications to accelerate past foundational research into deployed attacks on the timeline implied by recent coverage. He raises a sharper point too: several of NIST’s own earlier post-quantum candidates turned out to have classical, non-quantum vulnerabilities. SIKE, one of the standardization process’s later-round finalists, was broken in 2022 using ordinary computers. Calling something “post-quantum” doesn’t automatically make it secure against everything else.

Adam Back, CEO of Blockstream and one of the cypherpunk movement’s earliest figures, pushed back specifically on cryptocurrency alarm following Google’s paper, telling Bloomberg the practical threat to Bitcoin remains decades off.

“The biggest calculation it’s performed is factoring 21 into 7 times 3.” Adam Back, CEO, Blockstream

Back still thinks Bitcoin and other chains relying on the same elliptic curve signatures, the kind of dependency that also shows up in cross-chain bridge designs, should start migrating to quantum-resistant signatures now. He just doesn’t think anyone should be panicking about it this month.

The research group a16z crypto goes further, arguing the field isn’t close to a cryptographically relevant quantum computer by any reasonable reading of public progress data. Even reporting on Google’s own resource-estimate reduction tends to include the same caveat: shrinking the qubit count on paper doesn’t solve the unsolved systems-engineering problem of running hundreds of thousands of physical qubits with real-time error correction at scale. Reducing one bottleneck just exposes the next one.

What This Actually Means for Your Organization

Strip out the deadline debate and the actual post-quantum cryptography adoption gap is the unglamorous part. A Propeller Insights survey of 1,042 senior cybersecurity managers, commissioned by DigiCert and published in 2025, found that 69% of respondents recognize the quantum risk to current encryption, but only 5% have actually implemented quantum-safe encryption anywhere in their environment. Nearly half, 46.4%, believe a substantial share of their own encrypted data could eventually be compromised.

A separate Ponemon Institute study of 1,426 IT and security practitioners across the U.S., EMEA, and Asia-Pacific found 61% don’t expect to be ready, only 30% have allocated budget, and just 52% have even started a cryptographic inventory, the mandatory first step in any migration. A more recent Omdia survey of over 400 senior IT leaders, published in early June 2026, puts the share who’ve fully assessed their systems for cryptographic risk at just 22%.

None of that requires believing a quantum computer will exist next year. It requires believing harvest-now-decrypt-later is real today. Adversaries can capture encrypted traffic now and simply wait. Anything with a confidentiality requirement stretching into the mid-2030s, financial records, legal archives, government communications, long-lived intellectual property, is exposed under today’s encryption the moment it’s intercepted, regardless of when the decryption key eventually becomes breakable.

This is the same regulator setting the clock on zero trust security architecture, so if your team is already mapping NIST-aligned controls for that initiative, cryptographic inventory belongs on the same project plan rather than a separate one.

A Practical Migration Checklist

Here’s the post-quantum cryptography migration sequence security teams are actually using, in order:

1. Run a cryptographic inventory. Find every system, certificate, library, and hardcoded dependency using RSA, ECDSA, ECDH, DSA, or Diffie-Hellman. Most teams underestimate how many places this math is buried.
2. Prioritize by data lifespan, not system criticality. A low-priority system with 20-year data retention requirements is a higher quantum risk than a high-priority system that only handles short-lived sessions.
3. Deploy hybrid cryptography first. Pairing a classical algorithm with a post-quantum one means you stay protected even if one half is later broken, which matters given Matthew Green’s point about unproven new candidates.
4. Treat signatures as time-sensitive on their own clock. Migrate authentication and signing separately from encryption, since forged signatures become possible the moment a capable quantum computer exists, with no advance-harvest grace period.
5. Wait on unfinished standards. Hold off building production dependencies on FIPS 206 (Falcon) or HQC until they’re finalized, expected sometime between 2026 and 2027.
6. Budget against the four-year window. Use Gartner’s “unsafe by 2029, fully breakable by 2034” framing as a planning heuristic for budget approval, not a precise countdown.

The Real Timeline vs. the Headlines

So which date should actually go on your roadmap? Probably more than one. Google’s 2029 is the most concrete forcing function available right now, especially since it comes from the organization that’s done the most original research on how hard this attack actually is. NIST’s 2030 and 2035 dates remain the closest thing to a regulatory backbone, even in draft form, and they’re the dates auditors, cyber insurers, and procurement teams will most likely reference once IR 8547 finalizes. The skeptics aren’t wrong that no cryptographically relevant quantum computer exists today. They’re just answering a different question than “when should my migration start.”

Our read: the binding constraint here isn’t compute, it’s organizational inertia. Most enterprises won’t miss the 2029 or 2030 deadlines because the cryptography isn’t ready. They’ll miss it because the inventory phase alone quietly eats two of the four years they thought they had.

The Y2K comparison shows up constantly in coverage of this story, and it’s useful shorthand with one real flaw: Y2K had a single, fixed, universally agreed date. Q-Day doesn’t. The Global Risk Institute’s seventh annual Quantum Threat Timeline Report, built from structured input from 26 named quantum-computing experts, puts a full-scale cryptographically relevant quantum computer at “quite possible” within 10 years and “likely” within 15. That’s a probability distribution, not a deadline. Plan accordingly.

Frequently Asked Questions

When will quantum computers be able to break encryption?

No cryptographically relevant quantum computer exists yet. The Global Risk Institute’s expert survey puts a full-scale version at “quite possible” within 10 years and “likely” within 15. Google’s own internal deadline targets 2029, six years ahead of NIST’s 2035 federal backstop.

What is NIST’s deadline for RSA-2048?

NIST’s draft document IR 8547 proposes deprecating RSA-2048 and ECC P-256 by 2030 and disallowing all quantum-vulnerable public-key algorithms by 2035. The document remains an unfinalized draft as of mid-2026, so treat the dates as a likely outcome, not finished law.

Why did Google move its quantum deadline to 2029?

Google cited faster than expected progress in quantum hardware and error correction, plus new research showing elliptic curve cryptography could be broken with roughly 20 times fewer qubits than previously estimated, published alongside its March 2026 deadline announcement.

What is harvest now, decrypt later?

It is an attack pattern where adversaries capture encrypted data today and store it, planning to decrypt it once a powerful enough quantum computer exists. It makes long-lived encrypted data vulnerable right now, even though no quantum computer can currently break it.

Is Bitcoin vulnerable to quantum computers?

Bitcoin’s signature scheme relies on the same elliptic curve math Google’s research targeted, so it is theoretically exposed long term. Most cryptographers, including Bitcoin advocate Adam Back, consider the practical threat years to decades away, but support migrating gradually now.

What to Watch Next

Here’s what you didn’t know a few minutes ago: the urgency in this post-quantum cryptography story isn’t coming from a finished government deadline. It’s coming from a trend line, two separate 20-fold reductions in attack-resource estimates from the same Google research group inside a decade, that’s compressing every other timeline built around it.

Over the next 6 to 18 months, watch three things. First, whether NIST finally finalizes IR 8547 or pushes the date again, the way an earlier proposed target was already revised once before. Second, whether other major infrastructure operators follow Cloudflare’s reported move to align with Google’s 2029 date, which would turn one company’s internal policy into something closer to an industry standard. Third, whether FIPS 206 and HQC actually land in their projected 2026 to 2027 window, since both are needed before several hybrid deployment strategies can fully mature.

None of this requires belief in an imminent Q-Day. It requires an honest inventory, a realistic budget conversation, and a migration plan that survives whichever date turns out to be the right one.