Listen to this article
Jump to a section
In this article
Executive Summary
Every AI system depends on public-key cryptography. RSA and elliptic-curve algorithms protect the connections that carry training data and prompts, the signatures that prove a model file is genuine, and the tokens that identify an AI agent to the systems it acts on. A large, error-corrected quantum computer running Shor’s algorithm would break all of them. No such machine exists today, and nobody has broken RSA-2048. What has changed is the estimated size of the machine required: in 2025 Craig Gidney put RSA-2048 within reach of under a million noisy qubits, down from twenty million in 2019, and in March 2026 Google Quantum AI cut the figure for 256-bit elliptic curves by about twentyfold. Data intercepted today can be stored and decrypted later, so the exposure has already started for anything that must stay secret into the 2030s. The replacement standards exist. The work is finding every place your AI stack uses the old algorithms and moving it.
<1m
noisy qubits estimated to factor RSA-2048 in under a week, down from 20 million in 2019, Gidney, Google Quantum AI, 2025
~20x
reduction in physical qubits needed to break 256-bit elliptic-curve cryptography, Google Quantum AI, March 2026
28–49%
averaged expert estimate that a cryptographically relevant quantum computer arrives within ten years, Global Risk Institute, 2025
2029
Google’s own target date for completing its post-quantum migration, a year ahead of NIST’s 2030 deprecation date
Core conclusions
- Public-key algorithms are the exposure. RSA, Diffie-Hellman and elliptic-curve cryptography fall to Shor’s algorithm. AES-256 and SHA-256 remain sound, so encrypted storage is mostly safe once its keys are exchanged and wrapped with quantum-safe methods.
- AI adds two specific risks. Training data, prompts and model weights sent over today’s links can be harvested now and read later, and model signatures and agent credentials can be forged once a large quantum computer exists.
- The fix is a managed migration: a cryptographic inventory that covers the AI stack, hybrid ML-KEM key exchange now, a plan for ML-DSA signatures, and contract terms that hold AI vendors to the same dates.
The argument, in ten slides
Save it, or send it to whoever owns cryptography in your organisation.
Most of the AI risk conversations I sit in are about the model: bias, hallucination, what an agent is allowed to do. Very few cover the cryptography underneath it, because cryptography has been a solved problem for most executives’ entire careers. Quantum computing reopens it. This post sets out what a quantum computer would break, how close that machine is on the published evidence, where an AI programme is exposed, and what I would ask a board to approve this year.
Which encryption quantum computers break
Modern systems use two families of cryptography. Symmetric algorithms such as AES encrypt the data itself. Public-key algorithms such as RSA and elliptic-curve cryptography do the harder job of agreeing those keys between strangers over the internet and of signing things so that a recipient can prove who sent them. In 1994 Peter Shor showed that a large enough quantum computer could solve the mathematical problems behind public-key cryptography efficiently. The symmetric side is affected far less: Grover’s algorithm gives a quantum computer a square-root speed-up against AES, which a 256-bit key absorbs.
| Algorithm | What it does | Effect of a large quantum computer |
|---|---|---|
| RSA | Key exchange, digital signatures, certificates | Broken by Shor’s algorithm |
| Elliptic-curve (ECDH, ECDSA, EdDSA) | Key exchange in TLS, signatures on code, tokens and certificates | Broken by Shor’s algorithm |
| Diffie-Hellman | Key exchange in VPNs and older TLS | Broken by Shor’s algorithm |
| AES-128 | Encrypting data | Weakened by Grover’s algorithm; move to AES-256 |
| AES-256 | Encrypting data at rest and in transit | Remains secure |
| SHA-256 and SHA-3 | Hashing and integrity checks | Remain secure at current sizes |
Sources: NIST IR 8547 (initial public draft, 2024); UK NCSC, Timelines for migration to post-quantum cryptography (2025).
The first three rows are the problem. They are in every TLS connection, every VPN, every signed software update and every certificate a browser checks. I want to be precise about the state of play, because the phrase “quantum breaks encryption” is often used as if it had already happened. It has not. No quantum computer has factored a real RSA key, and today’s machines have far too few error-corrected qubits to try.
How close the machine is
The useful measure is the size of machine the published algorithms require, and that number has fallen fast.
| Year | Target | Estimated machine | Runtime | Source |
|---|---|---|---|---|
| 2019 | RSA-2048 | About 20 million noisy qubits | About 8 hours | Gidney and Ekerå |
| 2025 | RSA-2048 | Fewer than 1 million noisy qubits | Under a week | Gidney, Google Quantum AI |
| 2026 | 256-bit elliptic curve | Fewer than 500,000 physical qubits | A few minutes | Babbush, Neven and colleagues, Google Quantum AI |
All three estimates assume a superconducting machine with a physical error rate of about 0.1 per cent. Sources: arXiv 1905.09749; arXiv 2505.15917; Google Research, March 2026.
Hardware still has a long way to go to meet those numbers. The direction of travel is the point. Each improvement in algorithms and error correction brings the target closer to the hardware, from both ends at once. The Global Risk Institute’s 2025 survey of 26 quantum experts put the chance of a cryptographically relevant quantum computer within ten years at between 28 and 49 per cent, the highest ten-year estimate in the survey’s seven-year history. In March 2026 Google moved its own migration deadline to 2029, citing “progress on quantum computing hardware development, quantum error correction, and quantum factoring resource estimates.”
When the company that builds some of the most advanced quantum hardware sets itself a 2029 deadline, I stop treating 2035 as the planning date.
Where AI depends on public-key cryptography
AI systems do not use special cryptography. They inherit whatever the surrounding infrastructure uses, and they add new traffic, new identities and new artefacts that need protecting. Mapping an AI programme against the table above gives a list most security teams have not written down.
| AI asset | Cryptography it relies on | Quantum exposure |
|---|---|---|
| Training data moving between sources, lakes and training clusters | TLS key exchange, usually elliptic-curve | Harvest now, decrypt later |
| Prompts, retrieved documents and outputs sent to model APIs | TLS key exchange | Harvest now, decrypt later |
| Model weights stored in the cloud | AES for the data; RSA or elliptic-curve keys to wrap and share the encryption keys | Data is safe; key wrapping and transfer are exposed |
| Model files downloaded from a hub or vendor | Digital signatures, for example OpenSSF Model Signing on Sigstore | Forged signatures on a tampered model |
| AI agents calling tools and APIs | OAuth tokens and certificates signed with RSA or elliptic-curve keys | Forged credentials that impersonate an agent or a service |
| Content provenance on generated media | Content Credentials (C2PA) signatures | Forged provenance on synthetic content |
My mapping, based on common enterprise AI architectures. The exposure column follows the algorithm table above.
Two rows deserve particular attention. The first is model weights. A frontier or fine-tuned model can hold a large share of an organisation’s AI investment, and RAND’s 2024 study of weight security identified 38 distinct attack vectors for stealing them. Encrypting the weights with AES-256 protects them at rest. The keys that unlock them still travel and get wrapped with public-key algorithms, and that is where a quantum-capable attacker would aim.
The second is agents. Every agent that acts on a system carries a credential, and most of those credentials are tokens signed with RSA or elliptic-curve keys. An organisation running hundreds of agents has hundreds of new machine identities, all resting on signature schemes that a quantum computer would let an attacker forge. The signing infrastructure behind them, from certificate authorities to token issuers, is some of the slowest to replace.
New algorithms also depend on the random numbers used to generate their keys, and post-quantum guidance mostly assumes that randomness is sound. It usually is, but there is a known failure. In 2012 researchers scanning the internet recovered the private keys of about 0.5 per cent of TLS hosts, because devices had generated keys before their random number generators were properly seeded, and many ended up sharing key material. Modern operating systems have largely closed that gap at boot. Cloned virtual machine images and snapshot restores are harder: a program that drew randomness before the snapshot can carry the same state into every copy. If agent credentials are issued on machines launched from a shared image, one bad state becomes many related keys, and ML-KEM key generation needs good randomness as much as RSA ever did. The practical control is to generate agent keys inside a validated key management service or hardware security module, and to keep evidence of its entropy source for the auditor.
When each risk arrives
The two halves of the threat run on different clocks.
Confidentiality is already exposed. An adversary can record encrypted traffic today and store it until a quantum computer can recover the keys. Michele Mosca’s rule of thumb states the test: if the years your data must stay secret, plus the years your migration will take, add up to more than the years until a quantum computer arrives, you are already late. Proprietary training data, customer records used for fine-tuning, health and financial data in retrieval systems and model weights all have shelf lives measured in years. For them the risk window opened when the data first crossed a network.
If secrecy plus migration outlasts the wait, you are already late.
Already late: data recorded today is still secret 6 years after the machine could arrive.
Illustrative defaults; set your own. Anything past the dashed line is data an adversary can record now and read later. The 2025 Global Risk Institute survey put the chance of such a machine within ten years at 28 to 49 per cent.
Authenticity fails later but costs more to fix. A signature cannot be forged retroactively in any useful sense, so the threat to model signing, code signing and agent credentials starts on the day a capable machine exists. The difficulty is that roots of trust, such as certificate authorities, firmware signing keys and hardware security modules, take years to replace. That is why Google now prioritises signature migration, stating that “digital signatures are a future threat that require the transition to PQC prior to a Cryptographically Relevant Quantum Computer.”
The replacement standards and deadlines
The standards question is settled. NIST published the first three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key exchange, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. It selected HQC in March 2025 as a backup key-exchange algorithm built on different mathematics. Hybrid key exchange, which combines ML-KEM with a classical algorithm, is already the default in Chrome, Edge and Firefox, and by October 2025 Cloudflare reported that more than half of the human traffic reaching its network used it.
Regulators have set dates.
| Body | Guidance | Key dates |
|---|---|---|
| NIST (US) | IR 8547, initial public draft, November 2024 | RSA and elliptic-curve at 112-bit security deprecated after 2030; all quantum-vulnerable public-key algorithms disallowed after 2035 |
| UK NCSC | Timelines for migration, March 2025 | Discovery complete by 2028; highest-priority migration by 2031; full migration by 2035 |
| European Union | Coordinated implementation roadmap, June 2025 | National plans started by end 2026; high-risk systems, including finance and health, migrated by end 2030; as much as feasible by 2035 |
| MAS (Singapore) | Advisory MAS/TCRS/2024/01, February 2024 | Financial institutions to maintain a cryptographic inventory and build a quantum migration strategy |
| CSA (Singapore) | Quantum-Safe Handbook and Quantum Readiness Index v1, July 2026 | Reported expectations for CII owners: migration plan by March 2027, quantum-safe procurement from 2028, migration complete by end 2031 |
| PQC migration timeline, March 2026 | Its own migration complete by 2029 |
Sources as listed. The CSA milestones are as reported by secondary coverage of the handbook; the handbook describes its guidance as not mandatory.
For a Singapore bank or a critical infrastructure operator, the practical deadline is the early 2030s at the latest. For most other organisations it is 2030 to 2035, arriving through procurement: suppliers to regulated firms will be asked to meet the same dates.
What to do this year
Nothing here requires a quantum computer or a quantum specialist. It is inventory, prioritisation and ordinary engineering change, done across a longer list of systems than most teams expect.
- Build a cryptographic inventory that includes the AI stack. MAS asked for this in 2024 and the NCSC wants discovery finished by 2028. Record every place RSA, Diffie-Hellman or elliptic-curve algorithms are used: model API connections, data pipelines, vector databases, model registries, agent credentials, key management and vendor links. Record where each key is generated as well, and whether that happens inside a FIPS 140-3 validated module or on a cloned virtual machine. Most organisations find far more instances than they expected, many inside third-party products.
- Rank data by how long it must stay secret. Apply the Mosca test. Training data, fine-tuning sets, model weights and retrieval corpora with a secrecy requirement past 2032 go to the top of the list.
- Turn on hybrid ML-KEM key exchange now. It is available in current browsers, major cloud load balancers and recent TLS libraries. The gap is usually internal: service-to-service traffic, training clusters, on-premise inference and legacy VPNs.
- Plan the signature migration. Model signing, code signing, agent tokens and internal certificate authorities need an ML-DSA path. Begin with anything whose trust anchor lives longer than five years, such as firmware and hardware roots.
- Design for crypto-agility. Algorithms belong in configuration. If swapping an algorithm means rewriting an application, the next change will be as expensive as this one. I also ask teams to check AI-generated code for hard-coded classical algorithms, because coding assistants learn from years of code written before these standards existed.
- Write the dates into contracts. Ask every model provider, cloud platform and AI vendor for its post-quantum roadmap, and put the dates in the contract. Your migration is only as fast as the slowest supplier holding your data.
Be wary of anything sold as a shortcut. The UK NCSC and the US NSA both advise against relying on quantum key distribution as the answer for most organisations, and both point to the NIST algorithms as the main route. A vendor badge that says “quantum-safe” is worth checking against FIPS 203 and 204.
Questions for the board
Before the next AI budget round, I would want written answers to five questions:
- Do we have a cryptographic inventory, and does it cover our AI platforms, data pipelines and agents?
- Which of our data must stay confidential beyond 2032, and is any of it crossing networks without hybrid post-quantum key exchange?
- Who owns the post-quantum migration, what is the target date, and how does it compare with NIST’s 2030 and our regulator’s dates?
- How are model files and agent credentials signed today, and what is the plan to move them to ML-DSA?
- Which AI and cloud vendors have committed to post-quantum dates in writing?
Free tool
Technology Risk Board Pack
Twenty questions on resilience, change management and technology risk oversight, with the evidence to request and the rule behind each gap. A post-quantum migration runs through all four areas.
Evidence & Methodology
The resource estimates, standards and regulatory dates come from the researchers and agencies that published them. The mapping of AI assets to cryptographic exposure and the six steps are my own, drawn from assurance work on AI platforms, and I have marked them.
| Claim | Source | Grade |
|---|---|---|
| RSA-2048 factored with fewer than 1 million noisy qubits in under a week, against 20 million qubits and 8 hours in 2019 | Gidney, arXiv 2505.15917 (2025); Gidney and Ekerå, arXiv 1905.09749 (2019) | Forecast, peer research estimate |
| 256-bit elliptic-curve cryptography broken with fewer than 500,000 physical qubits in minutes, about a twentyfold reduction | Google Quantum AI, March 2026 | Forecast, research estimate |
| 28 to 49 per cent chance of a cryptographically relevant quantum computer within ten years | Global Risk Institute, Quantum Threat Timeline Report 2025, 26 experts | Expert survey |
| Google migration target of 2029 and priority on signatures | Google, March 2026 | Reported by Google |
| FIPS 203, 204 and 205 published August 2024; HQC selected March 2025 | NIST | Measured, standards record |
| More than half of human traffic to Cloudflare uses post-quantum key agreement | Cloudflare, October 2025 | Measured by Cloudflare |
| NIST, NCSC, EU and MAS dates and requirements | Primary documents listed below | Measured, regulator record |
| CSA milestones for CII owners (2027, 2028, 2031) | Secondary coverage of the CSA handbook, July 2026 | Reported, not checked against the handbook text |
| Private keys recovered for about 0.5 per cent of TLS hosts because of weak randomness at key generation | Heninger, Durumeric, Wustrow and Halderman, USENIX Security 2012 | Measured, internet-wide scan |
| 38 attack vectors against model weights | RAND, Securing AI Model Weights (2024) | Measured, structured study |
| Mapping of AI assets to quantum exposure; the snapshot risk to agent keys; AI coding assistants reproducing classical algorithms; the six steps | My assessment | My call |
Sources
- Gidney, C. (2025). How to factor 2048 bit RSA integers with less than a million noisy qubits. arXiv 2505.15917.
- Gidney, C., and Ekerå, M. (2019). How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. arXiv 1905.09749.
- Babbush, R., and Neven, H. (2026). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly. Google Research.
- Adkins, H., and Schmieg, S. (2026). Google’s timeline for PQC migration. Google.
- Mosca, M., and Piani, M. (2026). Quantum Threat Timeline Report 2025. Global Risk Institute.
- National Institute of Standards and Technology. (2024). Post-quantum cryptography standardization: FIPS 203, 204 and 205.
- National Institute of Standards and Technology. (2024). NIST IR 8547 (initial public draft): Transition to post-quantum cryptography standards.
- National Cyber Security Centre. (2025). Timelines for migration to post-quantum cryptography.
- NIS Cooperation Group. (2025). A coordinated implementation roadmap for the transition to post-quantum cryptography. European Commission.
- Monetary Authority of Singapore. (2024). MAS/TCRS/2024/01: Advisory on addressing the cybersecurity risks associated with quantum.
- Cyber Security Agency of Singapore. (2026). Quantum-Safe Handbook and Quantum Readiness Index.
- Cloudflare. (2025). State of the post-quantum Internet in 2025.
- Heninger, N., Durumeric, Z., Wustrow, E., and Halderman, J. A. (2012). Mining your Ps and Qs: Detection of widespread weak keys in network devices. USENIX Security Symposium.
- Nevo, S., et al. (2024). Securing AI model weights: Preventing theft and misuse of frontier models. RAND.
- Open Source Security Foundation. (2025). Launch of Model Signing v1.0.
- National Cyber Security Centre. (2020). Quantum security technologies.
- National Security Agency. Quantum key distribution (QKD) and quantum cryptography (QC).
AI Is Now the Weapon and the Shield in Cybersecurity. Most Organisations Are Behind on Both.
The wider security picture the post-quantum migration sits inside.
What the DBS Outages Teach Boards About Technology Risk
Why the oversight for a large technology change has to be in place before the change starts.
How Financial Institutions Should Use AI to Keep Up With Regulatory Change
How regulated firms track a stream of new requirements, of which post-quantum dates are one.
An AI Management System Is Not a Policy Binder. It's the Machine ISO 42001 Actually Audits.
The management system where a cryptographic inventory of AI assets belongs.
My thanks to Maria Singh for her contribution to this post. Her work on the research and the argument made it a stronger piece.
Thanks also to Greg Garville Jr of Qrypt for reviewing the post after publication. His question about where agent keys get their randomness led to the paragraph on cloned virtual machines and the added note in step one, both added on 26 September 2026.
If your organisation is planning its post-quantum migration and has not yet mapped the AI stack, the inventory in step one is where I usually start. My consulting work covers technology and AI risk governance for boards of regulated firms and public agencies.
Was this useful?
