In December 2024, Google Quantum AI published a 105-qubit superconducting chip called Willow alongside a Nature paper demonstrating that errors can be suppressed exponentially as the code distance grows. Two months later, in March 2026, the same team published a revised resource estimate suggesting that breaking elliptic-curve cryptography on a cryptographically relevant quantum computer may take roughly 20 times fewer physical qubits than the prior 2024 estimate. Google also shipped Merkle Tree Certificates into Chrome and Cloudflare in the same month. The cryptographic timeline moved, the engineering response is already in production, and the threat to AI infrastructure is real now — not in some hypothetical 2035 — because of a threat model called harvest-now-decrypt-later that does not require quantum computers to exist at all.
This is the explain-first version of what changed, what did not, and what to do about it if you ship, train, or sign AI systems. The recommendations are the ones the Federal Reserve’s Office of Financial Research, CISA, and the Cloud Security Alliance’s May 2026 AI-infrastructure report converge on.
What Willow Actually Is: 105 Qubits, Below-Threshold Error Correction, and the End of the Scaling Skeptics
The headline fact is the qubit count — 105, almost double the 53 of Google’s 2019 Sycamore chip. But the qubit count is the least interesting thing about Willow. The interesting fact is how the error rate behaves when you group physical qubits into logical ones. For 30 years, the central open problem in quantum error correction has been whether scaling the number of physical qubits per logical qubit actually reduces the logical error rate. Most theoretical analysis said yes below a threshold and no above it. Willow is the first superconducting chip where Google could demonstrate the below-threshold regime experimentally. As the surface-code distance grew from a 3×3 patch to a 5×5 to a 7×7, the logical error rate roughly halved each step — the exponential suppression the theory predicted, finally shown on real hardware.
The other headline number is the random-circuit-sampling benchmark: Willow ran a task in under five minutes that the Frontier supercomputer would need an estimated 1025 years — 10 septillion years — to reproduce. That number vastly exceeds the age of the universe. It is a stress test rather than a useful workload, but it is the standard for demonstrating that the chip is doing something classically intractable, and it sets a public floor for the engineering trajectory.
The combination — below-threshold error correction plus ~5x Sycamore’s T1 coherence (~100 µs), per the APS Physics writeup — is what changed the cryptographic timeline. Qubit count is now an engineering scaling problem, not a theoretical one.
From Sycamore (2019) to Willow (2024): The Two Numbers That Moved the Encryption Timeline
Sycamore took three minutes and 20 seconds on the original 2019 random-circuit-sampling benchmark and Google claimed the world’s then-fastest supercomputer, the 200-petaflop Summit, would need 10,000 years. Five years later, Willow ran a larger instance of the same benchmark in under five minutes, against a faster machine (the 1.35-exaflops Frontier), and the classical runtime estimate jumped to 1025 years. The gap is widening — Google’s framing is double-exponential separation between classical and quantum hardware on this benchmark.
That is the engineering story. The cryptographic story is different and landed in March 2026 with the revised ECDLP-256 resource estimate. The prior estimate assumed breaking elliptic-curve cryptography with Shor’s algorithm would require hundreds of thousands of stable logical qubits, which translated to roughly 5–15 years of further hardware scaling even on an aggressive roadmap. The new estimate cuts that to under 1,200 logical qubits — a ~20x reduction — and arrives on the same day as another independent team (Oratomic, ex-Google/Caltech) published a parallel 40x reduction for Shor’s algorithm on reconfigurable atomic qubits. When two independent groups move the same threshold in the same week, that is not another estimate. It is a reassessment — and Google framed its own paper as a call to accelerate post-quantum migration.
Why 2029: Shor’s Algorithm, RSA-2048, and the New Resource Estimates
To break RSA-2048 with Shor’s algorithm, the field needs ~2,000 logical qubits. Google’s revised trajectory — cryogenic CMOS controllers, modular quantum interconnects, Willow-2 in testing — has them forecasting arrival of that machine in less than 40 months from the original Willow announcement. That is the source of the 2029 figure, which Google has set as its internal PQC migration deadline — six years ahead of the US federal government’s 2035 target.
To be precise about what 2029 means: it is the date Google wants its own production systems to be quantum-resistant by, not the date a cryptographically relevant quantum computer (CRQC) goes live. The CRQC could land before, on, or after 2029 — nobody in the field is willing to put a tight bound on it because engineering breakthroughs are discontinuous by nature. Hartmut Neven’s own public statements have consistently placed commercial quantum advantage at least 10 years out from 2024. The conservative reading is: 2029 is when Google is done migrating, which implies the cryptographic threat is real enough to warrant a six-year engineering program, and that is the only signal worth acting on.
Meanwhile, the gap between physical-qubit counts needed for breaking RSA and the Willow chip is still five orders of magnitude — 105 physical qubits versus the 4 to 20 million that naive estimates produce. But that gap matters less now that error correction has been shown to work below threshold. The remaining problem is qubit overhead per logical qubit, not whether scaling reduces errors. The engineering community has shifted from can this be built? to how fast can it be built?
What Stays Standing: Symmetric Crypto, AES-256, and What Grover’s Algorithm Actually Does
Not all crypto falls to quantum computers. Grover’s algorithm provides at most a quadratic speedup against unsorted search and symmetric ciphers, which effectively halves the effective key length. AES-256 becomes AES-128-equivalent under Grover, which is still computationally infeasible to brute-force. SHA-256 is similarly degraded but not broken. The threat from a future quantum computer targets the asymmetric layer — RSA, ECDH, ECDSA — not the symmetric layer. The right architectural response is to wrap existing AES keys in post-quantum key exchange (ML-KEM), not to replace AES itself.
That distinction is also why the asymmetric attack surface in modern AI systems is unusually broad. Every TLS handshake, VPN session, API call, code-signing verification, model-registry artifact signature, OAuth token, JWT, and signed model weight has at least one RSA/ECC primitive in its chain. The symmetric layer inside is fine. The public-key layer wrapping it is not.
The Standards Already Exist: NIST FIPS 203/204/205 and the Chrome MTC Migration
The defensive half of this story is older than people realize. NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, the lattice-based key encapsulation mechanism formerly known as Kyber), FIPS 204 (ML-DSA, the lattice-based digital signature scheme formerly known as Dilithium), and FIPS 205 (SLH-DSA, the hash-based signature scheme formerly known as SPHINCS+). A fourth signature standard, FIPS 206, is in development for FALCON. HQC was selected as the fifth standard in March 2025 as a backup KEM. These are not draft proposals — they are FIPS, the same standard-track that defines AES and SHA-2 for federal systems.
Adoption in federal systems is governed by the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). New NSA-controlled deployments must be CNSA 2.0-compliant by January 1, 2027. The full National Security System migration target is 2035, with non-compliant equipment phased out by December 31, 2030. CISA’s PQC migration program executes the federal civilian side under OMB Memoranda M-23-02 and M-26-15. India and Australia have independently moved into the 2030–2033 range. The regulatory clock is real and visible.
What is less visible — and what Willow makes urgent — is the HTTPS certificate layer. Post-quantum signatures are larger than ECDSA signatures, which means a TLS handshake that uses PQC signatures in traditional X.509 certificate chains adds bandwidth on every connection. Google and Cloudflare’s answer is Merkle Tree Certificates (MTCs): instead of every browser downloading a long chain of signatures, the certificate authority signs a single “tree head” representing millions of certificates, and the certificate sent to the browser is a compact proof of inclusion. Chrome has been running an MTC feasibility study with Cloudflare since Q1 2026 — Phase 1 of a three-phase rollout that ends with a Chrome Quantum-resistant Root Store in Q3 2027. This is not research. This is production deployment on real internet traffic with a fail-safe backed by traditional X.509.
Harvest Now, Decrypt Later: The Threat That Started Yesterday
The attack that the post-quantum migration timeline is built around is not the one where a quantum computer breaks your TLS session tomorrow. It is the one where an adversary already has your ciphertext, has had it for years, and is waiting. This is harvest-now-decrypt-later (HNDL), and it has three properties that make it qualitatively different from conventional cybersecurity threats:
- It is invisible. A passive wiretap on a fiber trunk produces no anomaly, no alert, no integrity-check failure. The ciphertext is operationally indistinguishable from normal encrypted traffic. From the defender’s perspective, you cannot prove you were or were not harvested.
- It is irreversible. Once the adversary has your ciphertext, you cannot unharvest it. You can only make it worthless at the time of decryption by re-encrypting it with a quantum-resistant scheme — but that only protects data you re-protect, not the historical archive.
- It is cheap. Storage is near-free at exabyte scale. The National Security Agency’s Utah Data Center, completed in 2014 at $1.5B, has an estimated 3–12 exabytes of capacity. China’s equivalent facilities operate at comparable or greater scale per Congressional Research Service assessments. The marginal cost of archiving another gigabyte of intercepted traffic is effectively zero.
The Palo Alto Networks analysis frames the urgency correctly: organizations should not measure risk by whether quantum computers can break encryption today, but by how long the data must remain protected. If the data’s confidentiality lifespan extends beyond the expected strength of the cryptography protecting it, the organization has quantum-era exposure. The Federal Reserve’s Office of Financial Research published a 2025 threat assessment confirming that adversaries are actively harvesting encrypted traffic from financial networks, and CISA issued advisory AA-2024-QC-001 recommending that critical infrastructure operators begin post-quantum migration planning immediately.
The operational rule: any data that retains its sensitivity for more than five years is high HNDL exposure today. That includes government records, medical data, financial transactions, intellectual property, model weights, training datasets, and signed model artifacts.
Why AI Is Unusually Exposed: Model Weights, Training Data, and Signed Model Supply Chains
The Cloud Security Alliance’s May 2026 research on HNDL risk to AI infrastructure lays out the specific exposure profile, broader than most teams realize. Model weights represent years of compute investment — billions in GPU cycles, curated data, engineering labor. Exfiltrated weights could replicate capabilities that took years to develop, reverse-engineer training data for sensitive PII, or enable adversarial research against the model’s intended use. Training datasets may contain health records, financial transactions, or communications encrypted under indefinite-confidentiality assumptions. Inference logs contain the actual queries and responses, which in enterprise deployments may include privileged legal analysis, medical diagnoses, financial projections, and strategic planning.
The targeting rationale is substantial enough that AI infrastructure should be treated as a separate category from conventional enterprise IT for HNDL planning. A single future decrypt can yield both the model and the private data it learned from — a complete picture of an organization’s proprietary AI investment.
The second dimension is the supply chain. The emerging ecosystem of model signing and attestation — including the OpenSSF Model Signing specification, NVIDIA’s integration with NGC, and Sigstore-based provenance chains — relies on digital signature schemes that will be compromised by a CRQC. An adversary who harvests signed model artifacts today could, in the future, forge provenance claims by breaking the signatures on legitimate artifacts, potentially enabling supply-chain attacks that insert backdoored weights into production systems while presenting valid historical attestations. The economics that drive this exposure also apply to the broader AI hardware race: if your proprietary weights sit on third-party GPU clusters, you have already outsourced part of your HNDL risk surface to someone else’s network. This is why AI tool logging and provenance is part of the same problem set as cryptographic hygiene — they are both audit trails that adversaries want to forge, and both currently rest on ECDSA signatures that a CRQC will break.
The CSA report classifies the components by HNDL sensitivity:
| Component | Typical Cryptographic Protection | HNDL Sensitivity | Primary Risk |
|---|---|---|---|
| Training data in cloud storage | AES-256 at rest; RSA/ECC key wrapping | High | IP and PII exposure when keys are broken |
| Data pipelines in transit | TLS 1.3 (ECDHE key exchange) | High | Long-lived sensitive data intercepted in transit |
| Distributed training gradients | TLS between worker nodes | Medium-High | IP leakage; reconstruction of training data |
| Model checkpoints / weights | TLS in transit; AES-256 at rest | Very High | Core IP; years of compute investment |
| Model registry / artifact store | TLS + code signing (ECDSA/RSA) | Very High | Provenance forgery; backdoor insertion |
| Inference API endpoints | TLS 1.3 | High | Reveals usage patterns, queries, outputs |
| Agent-to-agent communication | TLS (per connection) | Medium-High | Operational intelligence; decision rationale |
| Authentication (API keys, tokens) | RSA/ECDSA; JWTs | High | Future credential compromise |
| Federated learning aggregation | TLS + homomorphic/differential privacy | Medium | Gradient reconstruction at scale |
For AI organizations, this analysis has a concrete implication: the highest-sensitivity AI data flows should be prioritized for early PQC adoption regardless of where they fall in a comprehensive migration roadmap. Model weight distribution channels, training data pipelines, and model registry signing should be early-phase priorities, not items deferred to later in a multi-year program.
What Practitioners Should Actually Do in 2026: A Pragmatic Migration Order
The Cloud Security Alliance recommendation, mirrored by the Federal Reserve threat assessment and CISA’s advisory, is layered. Data in transit must be protected with post-quantum TLS — hybrid key exchange today (OpenSSL 3.2+, BoringSSL) or full PQC cipher suites as they mature. Data at rest must be re-encrypted with quantum-resistant algorithms. Network architecture should minimize exposure by reducing hops that encrypted AI traffic traverses.
Below is the priority order for an AI organization that has not yet started its PQC migration. For broader context on AI architecture and tool-selection decisions that interact with this cryptographic layer, the 2026 AI tool decision guide covers the full stack.
- Build a cryptographic bill of materials (CBOM). Inventory every place your AI systems use RSA, ECDH, ECDSA, or RSA-PSS. Focus first on data pipelines, model registries, and inter-service communication in agentic architectures. Practical patterns for inventorying cryptographic surfaces across agentic AI security boundaries and the Microsoft Agent Governance Toolkit are the closest reference implementations we have today. You cannot migrate what you cannot find.
- Upgrade TLS on the highest-sensitivity channels first. Model weight distribution, training data ingestion from external sources, and external inference APIs. Deploy hybrid TLS with ML-KEM (FIPS 203). The connection is secure if either the classical or the PQC key exchange holds, so you get immediate protection without breaking compatibility.
- Migrate model signing to ML-DSA (FIPS 204). New model artifacts, SBOMs, and attestations should be signed with ML-DSA. The OpenSSF Model Signing specification already supports post-quantum algorithm selection. A model signed today with ECDSA may need to be trusted in 2031, by which point the signature could in principle be forged.
- Re-sign critical existing artifacts. For any model artifact with a sensitivity horizon beyond 2030, re-sign with ML-DSA now. This is cheap and forward-looking.
- Plan KMS, HSM, and PKI migration to support ML-KEM key wrapping. Internal-only crypto can wait. Customer-facing crypto cannot.
- Adopt crypto-agility at the protocol layer. Build your systems so you can swap cryptographic algorithms without redesigning the protocol. The lattice-based schemes in FIPS 203/204 are likely to remain secure for some time, but a future cryptographic breakthrough — or a future quantum-speedup against a specific lattice assumption — would force another migration. Plan for the next one now.
- Reduce unnecessary retention. Delete data that is no longer needed for business, legal, or compliance purposes. Reducing unnecessary archives lowers the volume of sensitive data that attackers can harvest. The training-data pressure driving the industry toward synthetic-data substitutes is the same HNDL dynamic playing out at the corpus layer: archive today’s training data, decrypt it (or re-derive insights) when capability arrives.
Prioritize what you would most regret losing: model weights encoding years of proprietary training, training datasets with long regulatory retention, inference endpoints serving sensitive decisions. Private local-AI deployments with direct fabric connectivity eliminate the public-internet exposure entirely — the strongest architectural mitigation against HNDL collection, and one no shared-infrastructure cloud provider can replicate.
What to Watch Over the Next 18 Months
Four inflection points to track between now and mid-2027:
- Chrome’s MTC Phase 2 launch (Q1 2027). Qualified Certificate Transparency log operators get invited to bootstrap public MTCs. The Q3 2027 Phase 3 launch — the Chrome Quantum-resistant Root Store (CQRS) — is when post-quantum HTTPS becomes a default option for new connections. Watch for cloud and CDN vendors announcing PQC-default configurations.
- NSA’s CNSA 2.0 enforcement deadline (January 1, 2027). All new NSA-controlled deployments must use post-quantum cryptography by this date. Federal contractors and defense-industrial-base suppliers will feel the second-order effects roughly 6–12 months later as procurement language hardens.
- Independent CRQC claims. Watch for any group claiming a public demonstration of Shor’s algorithm running at scale on a cryptographically relevant input set. The threshold for “credible claim” is high — a real CRQC would be a Nature/Science paper, not a press release. The bigger near-term signal is a credible chip vendor (IBM, IonQ, Quantinuum, Atom Computing) announcing a logical-qubit count and below-threshold demonstration on a par with Willow.
- The lattice-break watch. On July 28, 2026, Anthropic announced an AI model helped discover a vulnerability in HAWK, a lattice-based signature under NIST consideration. HAWK was withdrawn. NIST’s official guidance: finalized standards (ML-KEM, ML-DSA) rely on different foundations that remain secure. The event is a useful reminder that PQC foundations are themselves subject to AI-accelerated cryptanalysis, and that crypto-agility is not optional. Practical deployment patterns from the Mr. Technology network — including Mythos AI testing, GitHub Actions security hardening, and post-quantum cryptography in production pipelines — show the same crypto-agility principle applied at the CI/CD layer.
Willow is a milestone, not an attack. It made the timeline visible, exposed the gap between where asymmetric crypto is and where it needs to be by the end of the decade, and triggered the largest coordinated cryptographic migration in the history of the public internet. Chrome is running it. NIST has the standards. The engineering work is in flight. The question for AI practitioners is not whether post-quantum migration will happen — it will — but whether your model’s weights, training pipeline, and signed model artifacts will be quantum-resistant before an adversary decides your historical ciphertext was worth archiving.
Frequently Asked Questions
Is Google Willow going to break RSA encryption this year?
No. Willow is 105 physical qubits and has demonstrated below-threshold error correction and a beyond-classical random-circuit-sampling benchmark, but the cryptographic resource estimate for breaking RSA-2048 is in the millions of physical qubits and years of further engineering. Hartmut Neven’s own public timeline has consistently said a cryptographically relevant machine is “at least 10 years away.” The 2029 figure is Google’s internal PQC migration deadline, not the date a CRQC arrives.
What is the difference between Willow and Sycamore?
Sycamore (2019) had 53 qubits with ~20 microsecond T1 coherence and was the first chip to claim quantum supremacy on the random-circuit-sampling benchmark. Willow (2024) has 105 qubits with ~100 microsecond T1 (~5x longer) and, crucially, demonstrated below-threshold error correction: as the surface-code distance grew from 3×3 to 5×5 to 7×7, the logical error rate fell exponentially rather than rising. That second fact — not the qubit count — is what changed the cryptographic timeline.
Should I be using post-quantum cryptography now, even if quantum computers cannot break my keys yet?
Yes, for any data with a secrecy life of more than five years — and AI artifacts almost always qualify. Model weights, training datasets, signed model artifacts, and long-lived inference logs are the assets HNDL operations are most interested in archiving today, because they retain their value through 2030 and beyond. The Federal Reserve’s 2025 threat assessment, CISA’s AA-2024-QC-001 advisory, and the Cloud Security Alliance’s May 2026 report all converge: prioritize hybrid TLS (ML-KEM) and ML-DSA model signing on the highest-sensitivity channels now, regardless of where you sit in a multi-year migration roadmap.
Does post-quantum cryptography also protect against prompt injection, model extraction, or adversarial examples?
No. PQC addresses exactly one threat: a future cryptographically relevant quantum computer running Shor’s algorithm against your RSA or elliptic-curve keys. It does nothing for prompt injection, jailbreaks, model-stealing via API probing, or adversarial inputs. Treat PQC as one layer of an AI security program, not the whole program. The non-cryptographic attack surface is still dominant for most production AI deployments today.
What is hybrid TLS, and should I deploy it?
Hybrid TLS runs a classical key exchange (X25519/ECDHE) and a post-quantum key exchange (ML-KEM, FIPS 203) simultaneously and combines both derived keys. The connection is secure if either algorithm holds. This is the recommended transitional posture because it provides immediate PQC protection while maintaining compatibility with infrastructure that has not yet deployed PQC. Hybrid TLS with ML-KEM is supported in OpenSSL 3.2+, BoringSSL, and major CDN edges including Cloudflare. For any AI data channel handling model weights, training data, or sensitive inference traffic, deploying hybrid TLS is a concrete step you can take today.
What about AES-256 — is it also broken by quantum computers?
No. Grover’s algorithm provides at most a quadratic speedup against symmetric ciphers, halving the effective key length: AES-256 becomes AES-128-equivalent, which is still computationally infeasible to brute-force. The HNDL threat targets the asymmetric layer — RSA, ECDH, ECDSA — not AES. The fix is to wrap existing symmetric keys in post-quantum key exchange (ML-KEM), not to replace AES.
Last updated: 2026-09-11. Sources cited inline; primary-source URLs verified via direct HTTP probe at publication time.