For decades, quantum cryptanalysis was a “eventually, maybe” problem. Somewhere past 2050. Far enough away to be theoretical.

Three papers in twelve months changed that. Not faster hardware. Better math. And consequences that arrive sooner than expected. We’re on the cusp of the quantum era, and the question has become how fast can we be ready.

Gidney and Schmieg at Google Quantum AI (May 2025) showed through simulation that RSA-2048 could be broken with under 1 million qubits instead of 20 million. That’s a 20x improvement over Gidney’s own 2019 estimates through better compilation and arithmetic. The algorithms improved instead of a hardware breakthrough.

Iceberg Quantum followed three months later with a different approach: switch to LDPC error correction instead of surface codes, bringing RSA-2048 estimates down to under 100,000 qubits.

Then in March 2026, Google published resource estimates for Bitcoin and Ethereum that involve the same cryptographic systems currently protecting $2 trillion in assets. Result: fewer than 500,000 qubits estimated to be needed. Execution time: minutes, not months.

The same week, Oratomic and Caltech released results showing ~10,000 atomic qubits could run Shor’s algorithm at cryptographically relevant scales. Their approach: use AI to search error-correction designs. The initial algorithms were 1,000x worse than needed. AI-assisted exploration found viable candidates. The paper hasn’t undergone peer review; the authors note “many open challenges remain.”

Google and Cloudflare both moved their post-quantum targets to 2029, and the same week the Oratomic and Google papers landed. Multiple papers converging on lower qubit estimates is the signal. Companies could be reacting to the papers, or to internal breakthroughs they haven’t published, or to customer pressure, or to vendor timelines. The exact cause isn’t known, but virtually simultaneous movement suggests they’re no longer treating this as a 2040s problem.

How We Got Here So Fast: The AI Accelerant

The interesting part of Oratomic isn’t the qubits. It’s how they got there. Their error-correction algorithms started 1,000x worse than viable. That’s normally the end of the conversation. Dead end. Try something else.

Instead, Robert Huang looped Claude and Gemini to explore the design space systematically. Not manually. Not one person’s hunches. The search found solutions. Dolev Bluvstein (lead author): “We used AI to accelerate development. Without it, this doesn’t work.”

The implication is harder than it first sounds: AI isn’t just a tool for building quantum systems. It’s expanding what’s possible in quantum architecture optimization. The concern: if the same search-and-refine loop can accelerate your quantum computer design, it accelerates an adversary’s too. Security convergence is happening not because the threat is inevitable, but because multiple independent efforts are all moving in the same direction simultaneously. Timelines compress if this continues.

The Composed Threat

Harvest-now-decrypt-later isn’t new. State actors are collecting encrypted traffic now. When quantum arrives, it becomes readable. Until now, that meant 2040 or later. Now sooner is plausible.

But decryption is the easy part. After you decrypt terabytes of data, you still need to find the most important pieces. Which intercepts have credentials? Which have keys? But at that point, it’s just a data problem.

The NSA gets this. Their AI/ML strategy documents talk about “machine learning and scalable analytic techniques to draw actionable intelligence from raw data.”

Here’s the problem: NIST IR 8547 doesn’t address AI-enabled threats. Neither does CISA/NSA quantum guidance. The quantum-AI collision has no integrated government threat model. The threat of harvesting traffic now, decrypting later with quantum, and identifying target data with AI, falls between two playbooks. NIST and NSA work from separate ones.

Organizations get guidance on quantum migration or AI governance. Not both. Not together. You’re on your own to connect them.

Why The Deadline Just Accelerated

Three intersecting factors create urgency:

First: The immediate threat to financial systems. Google’s Bitcoin analysis explores quantum attack scenarios against transaction confirmation timelines—finding feasibility windows where private keys could be exposed before blockchain finalization. For Bitcoin, that means security could collapse before anyone can move assets. Ethereum has similar ECC vulnerabilities. As with everything else in this article, it isn’t distant. It’s a question of when, not if.

Second: The data already collected. State actors are archiving encrypted traffic right now. Any long-lived sensitive data from the last 5–10 years using RSA or ECC will be readable once quantum capability arrives. Authentication credentials, configuration files, archived source code, financial records—if they were encrypted with current algorithms and archived, they’re targets. The data being collected now is the future damage.

Third: The migration window is short. NIST guidance indicates classical crypto should be deprecated for new uses after 2030, with full transition expected by 2035. Enterprise crypto migrations typically take as many as 7-10 years, which means the transition could extend to 2032–2035. IF you start now. The math is simple: if your deadline is 2035 and you need 7–10 years, you should have started in 2025–2027. Most organizations haven’t. Google and Cloudflare set 2029 targets, giving themselves a 6-year buffer before the NIST deadline. That thinking demonstrates insurance logic.

These three things intersect at a point. Infrastructure companies see it. They’re responding to the window, not a specific date.

A Note on Risk and Certainty

Jeff Thompson at Princeton (CEO of Logiqal, a competing quantum startup) argues that the Oratomic estimates are “untested” and that qubit counts are easy to reduce if you just assume better qubits. He’s not wrong, especially as the Oratomic paper hasn’t undergone peer review yet. The compression results are architecture-dependent and rest on assumptions about quantum-error rates that haven’t been proven at scale.

But here’s the thing: Google and Cloudflare didn’t wait for certainty. They accelerated anyway. When infrastructure companies move that fast despite valid skepticism about the timeline, it’s not because they’re certain. It’s because the cost of being wrong is too high. They’re not betting on the Oratomic timeline, they’re hedging against it.

As an organization, you should do the same: assume the worst-case timeline is real, plan for the mid-case timeline, and hope the skeptics are right. But don’t wait for certainty.

That’s the hedging logic, but there’s another problem an organization will probably face in the interim.

Most organizations treat cryptography as a static property: “Uses TLS.” “Encrypted at rest.” This works fine if encryption never breaks. Quantum changes that completely. Encryption that’s fine today might be broken in five years, retroactively exposing data collected now.

The hard question organizations aren’t asking: “How long does each piece of our encrypted data need to stay secret, and is our current crypto adequate over that horizon?”

This reshapes the entire risk model. “Doesn’t matter if it breaks in ten years” is a completely different risk posture than “catastrophic if it’s readable in five.” Most organizations haven’t categorized their data this way. They haven’t mapped which secrets have indefinite value (keys, credentials, authentication material) versus which have expiration dates.

That’s the gap. Consider a concrete example: your AWS KMS root keys need protection forever. Your OAuth tokens expire in hours. Your archived TLS session keys from 2020 are still a target if they’re being stored today. Your SSH host keys for infrastructure that will be decommissioned in 2028 have a different timeline than those for systems running until 2035. Each requires different migration urgency, but most organizations apply the same timeline to all of them.

Here are some things to do about it:

1. Cryptographic inventory. Know which systems use RSA, elliptic curve, or Diffie-Hellman. Don’t just list the algorithms, but capture what they protect and how long that data needs to stay secret. Long-term secrets (cryptographic keys themselves, authentication credentials with indefinite value, sensitive data) are the highest exposure.

2. Long-lived data mapping. Identify archives: email backups, log retention stores, database dumps, backup snapshots. These are where HNDL risk is concentrated. If you’re archiving encrypted data today that will be sensitive in 2035, that data is the target.

3. Trust chain visibility. Map who has cryptographic keys and under what authority. Service principals, API tokens, OAuth grants… each of these represent transitive trust chains that can fail. Know which components are on your critical path.

4. Post-quantum standard evaluation. NIST finalized post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) in August 2024. Production implementations exist now (OpenSSL 4.0 shipped April 2026 with hybrid post-quantum support, Linux 7.0 landed ML-DSA support in February 2026). The standards aren’t coming; they’re already here. The question is when to pilot.

5. Crypto-agility by design. New systems should be designed to swap cryptographic primitives without full re-architecture. This is less about “migrate now” and more about “build in the flexibility so migration isn’t catastrophic later.”

The next part is knowing which moves matter. Which announcements can indicate that standards enforcement is coming.

CISA guidance. Formal advisories move budgets. Watch for “Year of Quantum Security” positioning and anything that ties quantum to AI governance.

Vendor announcements. When AWS or Azure announce automatic OAuth scope auditing or key lifecycle enforcement, they’re hedging too. Standards enforcement follows shortly after.

IR 8547 finalization. Expected later this year. Once it’s final, auditors will start to cite it within months. That’s when “best practice” switches to “audit finding.”

Compliance updates. FedRAMP and CMMC will shift from “uses encryption” to “encryption adequate for data sensitivity and retention horizon.” That cascades to contractors.

Funding shifts. Post-quantum migration vendors get serious VC money when customers stop treating this as R&D. Watch the funding announcements, because they’re leading indicators of the market moves.

What Happens Next

The qubit requirements are shrinking. The hardware is catching up. The window for migration is already closing. These are solvable problems separately, but combined they create urgency that infrastructure companies are already responding to.

The gap between what governments are saying (NIST on quantum, NSA on AI) and what organizations need to know (quantum + AI together) is yours to bridge. Start with the hard question: what data needs to stay secret after 2030, and does your current crypto protect it?

The data being collected now can become be the vulnerability of 2030. Planning can determine whether you’re ready then.