Not yet, not never: will quantum computers break encryption?

I started this article a few years ago, set it aside, and only now came back to it. It began as an answer to popular tech coverage that presented the quantum computer as the new bogeyman of the digital era, inflated partly for the clicks. The question underneath was plainer than the headlines: what do quantum computers mean for the cryptography in use today?

I wrote it then, and write this now, as a software engineer and security engineer, not as a quantum physicist. The physics comes from people who do physics. The judgement calls are mine, and in a field this fast, judgement calls age.

So this is a revisit, not a quiet rewrite. The old draft made forecasts, and in 2026 they can be checked. Near the end I score five of them against what happened, misses included. Everything around them is new.

A quantum processing unit (QPU) is an accelerator beside the CPU and GPU, not a faster PC: it pays off only where a quantum algorithm wins. An earlier post covers what qubits, superposition and Grover's search are. For cryptography that means two algorithms, and the machine matters only as what runs them.

Public-key cryptography is a bet on hardness: multiplying two large primes is quick, recovering them from the product has no known efficient classical algorithm, and nobody has proven that one cannot exist, since that would settle P versus NP. If how symmetric, asymmetric and key-exchange algorithms differ is hazy, start there. The quantum damage follows that split.

Shor's algorithm, from Peter Shor's 1995 paper, solves integer factoring and discrete logarithms in polynomial time on a quantum computer. The second half is easy to miss. Diffie–Hellman and elliptic-curve cryptography rest on discrete logarithms, so they fall with RSA: NIST's November 2024 draft transition plan lists RSA, ECDSA, EdDSA, and finite-field and elliptic-curve Diffie–Hellman as vulnerable. Moving to elliptic curves buys nothing; if anything, they are the cheaper target.

Grover's algorithm (1996) is the other threat, and a far weaker one. It searches N unsorted entries in about √N steps, which NIST reads as a brute-force key search with quadratically fewer steps. That squeezes a symmetric key rather than breaking it, and the squeeze is smaller than it looks.

Hash functions land on Grover's side. The same NIST draft rates them, with its other symmetric standards, as significantly less vulnerable to known quantum attacks than public-key cryptography. SHA-256, SHA-384, SHA-512 and SHA3-256 to SHA3-512 rank above its lowest post-quantum category for collisions; SHA-1, SHA-224 and SHA3-224 are not among them, and less vulnerable is not immune.

Bits of security is a measure of the attacker, not the key. A scheme offers n bits when the best known attack costs about 2ⁿ operations, so the number moves whenever a better attack appears, and Shor and Grover are better attacks. Classical values are from NIST's SP 800-57 (2020 revision), the quantum verdicts from the previous section:

• RSA-1024: at most 80 bits classically; Shor breaks it.
• RSA-2048: 112 bits; Shor breaks it.
• ECC-256 (P-256): 128 bits; Shor breaks it.
• ECC-384 (P-384): 192 bits; Shor breaks it.
• AES-128: 128 bits; NIST places it in post-quantum Category 1, not at 64 bits.
• AES-256: 256 bits; whatever Grover does to AES-128, it does to a key twice as long.

The 64 comes from taking Grover's quadratic speed-up at face value: the square root of 2¹²⁸ is 2⁶⁴. NIST does not. Its post-quantum FAQ notes that the full speed-up needs Grover's steps run in series, while real attacks run in parallel. It concludes that Grover will likely give AES little or no advantage, and that AES-128 will remain secure for decades.

Grassl and colleagues concluded the opposite in 2015. Their Grover search on AES-128 needed just 2,953 logical qubits but a circuit depth of about 2⁸¹, which they said makes it hard to run. Even so, they judged it prudent to move away from 128-bit keys once a moderate-size quantum computer is expected. That is the 2015 view. For ordinary systems, cite NIST, and nothing in how AES works inside has to change.

So a vendor's key-strength table reads simply: the RSA and ECC rows go to zero the day a large enough quantum computer exists, and the AES rows barely move.

Qubit counts in the thousands, like the roughly 6,200 in Gidney and Ekerå's 2019 design, are logical qubits, the error-corrected units an algorithm runs on. Gidney's May 2025 design needs at most 1,409 of them active at once. Hardware is counted in physical qubits, and error correction makes each logical one expensive. Gidney's layout spends 1,352 physical qubits per active logical qubit; Google's 2024 below-threshold experiment used 101 for one logical memory.

The ratio depends on the hardware, the code and the error rate targeted: on Helios, Quantinuum used 10 with one code and up to 37 with another (October 2026). Estimates therefore compare only under fixed assumptions, which is what the chart opening Gidney's May 2025 paper provides: published physical-qubit estimates for RSA-2048, by year.

On its log scale the estimates drop about a thousandfold, from about a billion physical qubits (Fowler et al., 2012) to about 20 million (Gidney and Ekerå, 2019) and about a million (2025). The 2019 point is the famous one: eight hours on 20 million noisy qubits, for a gate-based superconducting machine running the surface code at a 0.1% gate error. By 2025, the same assumptions give under a million qubits, taking under a week instead of eight hours.

The chart ends at 2025; the estimates did not. In February 2026, Webster and colleagues at Iceberg Quantum put RSA-2048 under 100,000 physical qubits with quantum LDPC codes, at the same error and timing assumptions. In March 2026, Cain and colleagues argued that Shor's algorithm can run at cryptographically relevant scale on as few as 10,000 reconfigurable atomic qubits.

Elliptic curves come cheaper. Babbush and colleagues at Google Quantum AI estimated, also in March 2026, that a 256-bit elliptic-curve key falls to Shor with under 1,200 logical qubits. The attack runs in minutes on fewer than 500,000 physical superconducting qubits at a 0.1% error rate. Cain's group puts P-256 at a few days on 26,000 neutral-atom qubits, and RSA-2048 at one to two orders of magnitude longer.

None of the 2026 numbers belongs on the chart: they change the code, hardware or target, and exist only on paper. Read them as a range beside the chart, not its next point. The range runs from about a million physical qubits under the 2019 assumptions, to under 100,000 with newer codes, to about 10,000 atoms at the far end, where the attack takes days or longer. Since 2012, the direction has been down.

The requirement is counted in logical qubits: about 1,400 active at once for RSA-2048, and under 1,200 for a 256-bit curve. Today's machines run tens.

In November 2025, Quantinuum's 98-qubit Helios produced 48 error-corrected logical qubits at a 2:1 encoding, and 94 error-detected ones. The two counts are not interchangeable: detection notices an error, correction repairs it, and Shor needs correction. Which count is the record depends on that definition, so I give the order of magnitude, not a winner.

Vendor roadmaps converge on the end of the decade. IBM plans Starling, "the world's first large-scale, fault-tolerant quantum computer", for 2029 (June 2026), and Quantinuum expects its fault-tolerant Apollo by 2029 (October 2026). Microsoft anticipates a scalable machine by 2029, and Google commercially relevant superconducting machines by the end of the decade, both writing in 2026. These are plans for their own machines, not dates for breaking RSA-2048.

The experts are more cautious. In 2025, the Global Risk Institute asked 26 experts about the odds of a machine that breaks RSA-2048 within 24 hours. Most rated the risk of one appearing in the next five years as low, at an optimistic average of about 15%. They put it at 28–49% within ten years, and 51–70% within fifteen. Those answers predate the 2026 estimates.

For a hands-on look at today's machines, the earlier post covers cloud quantum SDKs such as Qiskit.

Encrypted traffic keeps, which is why waiting for Q-day is the wrong trigger. NIST's November 2024 draft transition plan describes adversaries collecting encrypted data now, to decrypt it once quantum technology matures.

Harvest now, decrypt later turns the question into arithmetic, which NIST's draft calls Mosca's theorem. Let X be the years your data must stay secret, Y the years your migration takes, and Z the years until a machine that runs Shor at scale exists. If X + Y is greater than Z, some of what is encrypted before the migration ends will still need to be secret when that machine arrives.

X and Y can be measured; Z is what the last two sections argue about. The EU has already put a number on X. Its June 2025 roadmap treats a use case as high-risk if disclosing its data after ten years or more would still cause significant damage. Under that test, data sent today must stay secret until 2036, past every deadline below.

The calendar is already published. Each body sets dates for its own scope, so ask whom each one binds:

• NIST IR 8547 (November 2024, still a draft in October 2026): RSA, ECDSA and finite-field and elliptic-curve Diffie–Hellman at 112-bit strength are deprecated after 2030, and every quantum-vulnerable scheme, EdDSA included, is disallowed after 2035. The draft is written for US federal systems, whose 2035 target NSM-10 already sets; other organisations meet it through the products and vendors that sell to them.
• CNSA 2.0 (NSA, September 2022, tightened by the CNSSP 15 update): for US National Security Systems, CNSA 2.0 is required in new acquisitions from 1 January 2027, equipment that cannot support it is phased out by 31 December 2030, and it is mandated by 31 December 2031. A company meets it as a supplier into those systems.
• UK NCSC (March 2025): discovery and an initial migration plan by 2028, the highest-priority migrations by 2031, and complete migration by 2035. The NCSC's timelines are guidance, and expect small firms on commodity IT to migrate largely through vendor updates.
• EU roadmap (June 2025): national strategies started by the end of 2026, high-risk use cases migrated by the end of 2030 with quantum-safe software and firmware upgrades on by default, and as many systems as practically feasible by 2035. The roadmap is addressed to Member States, and reaches a company through national plans and sector regulators.
• Google (March 2026): 2029 for its own post-quantum migration, authentication first.
• Cloudflare (April 2026): 2029 for its own full post-quantum security, authentication included.

The last two are targets the operators set for themselves, not deadlines on anyone else. Google gives its reason for putting authentication first: the threat to encryption is live today through store-now-decrypt-later, while signatures are a future threat that must migrate before a cryptographically relevant machine exists. Key exchange is the half already moving. A signature cannot be harvested, but it cannot be late either: the day such a machine exists, any certificate still on RSA or ECC can be forged.

Now set the 2029 targets beside the estimates. The machine for RSA-2048 fell under a million physical qubits in May 2025 and under 100,000 on paper in February 2026; Google and Cloudflare announced 2029 in March and April 2026. I put these side by side, not as cause and effect. The expert survey above, collected in 2025, predates both, while Cloudflare now writes that Q-day has been pulled forward from typical 2035+ timelines.

Either way, the dates bind. Whoever is right about Q-day, 2030–2035 is written down and 2029 is what Google and Cloudflare plan for. Which date reaches you depends on whom you sell to and where you operate.

The long-term fix exists, and it is not quantum. Post-quantum cryptography is classical mathematics, running on ordinary computers, built on problems with no known efficient quantum attack. NIST's process began with a call for proposals in 2016. Its first three standards were published on 13 August 2024: FIPS 203 (ML-KEM) for key encapsulation, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. The first two rest on lattices, the third on hash functions.

NIST's project page tracks the rest. HQC was selected as a second key-encapsulation mechanism on 11 March 2025, with a final standard expected about two years later, and as of August 2026 the Falcon and HQC standards were still underway.

NIST ran the process in the open, as it ran the AES and SHA-3 competitions, and not every candidate survived. In 2022, Beullens recovered Rainbow keys at its level-1 parameters in about 53 hours on a laptop, and Castryck and Decru broke SIKEp434 in about ten minutes on a single core, both with classical attacks. That is the process working: a scheme broken in public before it is standardised is cheap to drop.

For most systems, the migration is a software update. The new algorithms run on today's computers, and for commodity IT the change should arrive through vendor updates. The exceptions are hardware: HSMs and TPMs must be upgraded or redesigned, and some legacy systems and long-lived physical infrastructure cannot be transitioned at all. Those are the lines in a migration budget that are not a patch.

Part of the migration has already happened, by default. Hybrid key exchange runs a classical algorithm and a post-quantum one together, so a session holds unless both are broken. Chrome made ML-KEM768+X25519 its default hybrid key share in Chrome 131, announced in September 2024. OpenSSL 3.5.0, released on 8 April 2025, offers X25519MLKEM768 by default.

OpenSSH has defaulted to a hybrid post-quantum key exchange since 9.0 in April 2022, moved to mlkem768x25519-sha256 in 10.0 in April 2025, and since 10.1 in October 2025 warns when a connection negotiates key agreement that is not post-quantum. The OpenSSH release notes date each step. At the other end of the wire, Cloudflare reported in April 2026 that over 65% of human traffic to it was post-quantum encrypted.

All of it covers key exchange, which is what harvest-now-decrypt-later threatens. Certificates and signatures are a separate migration, and the one Google and Cloudflare now put first.

You can check a connection yourself. In Chrome, open DevTools and read the connection details for the page, where the key exchange is named. On the connection below it is X25519MLKEM768, the hybrid from the defaults above. It protects the key exchange and says nothing about the certificate that authenticated the server.

Quantum physics is also sold to defenders directly, in two products. A quantum random number generator (QRNG) draws its randomness from a quantum measurement. Neither the NSA nor the NCSC prefers it. CNSS policy does not favour QRNGs over other generators (NSA, October 2026), and the NCSC's August 2025 paper says classical ones still meet security needs, though it wants QRNG research to progress. A QRNG is another entropy source, not a new security model.

Quantum key distribution (QKD) has a real selling point: published theories suggest physics lets the two ends detect an eavesdropper, which standard cryptography cannot do. The practice is harder. QKD needs dedicated fibre or free-space links, cannot be delivered in software or as a network service, and its networks frequently rely on trusted relays, which add cost and insider risk.

Laying fibre from a bank to each account holder is not a business model. Micius makes the relay point: in 2018, Liao and colleagues reported the satellite creating a key between ground stations in China and Austria, 7,600 km apart, by acting as a trusted relay.

QKD also provides no authentication, so it still needs the cryptography it was meant to replace, and the NCSC's August 2025 paper says it should not be relied on for substantial security value. The NSA lists five technical limitations, from "only a partial solution" to a higher denial-of-service risk, and does not support QKD for National Security Systems. My verdict: buy neither as a quantum defence. In the same August 2025 paper, the NCSC names post-quantum cryptography as the primary mitigation.

Five forecasts from the draft I began a few years ago, each against what has happened since:

• NIST's standards by 2022–2024: hit. I expected NIST's final post-quantum result between 2022 and 2024. FIPS 203, 204 and 205 were published on 13 August 2024, though Falcon and HQC were still underway in August 2026.
• Mostly a software update: hit, exceptions too narrow. I predicted the migration would mostly mean a software update, except for constrained devices. Hybrid key exchange went on by default in OpenSSH, Chrome and OpenSSL between 2022 and 2025. But NIST (November 2024) and the NCSC (March 2025) name wider exceptions: HSMs, TPMs, legacy systems and long-lived infrastructure.
• QKD for very few: half a hit. I judged QKD not useful for most organisations, except for links carrying extremely confidential data. The first half held: in its October 2026 FAQ, the NSA does not consider QKD practical for National Security Systems. The exception did not: in August 2025 the NCSC ruled QKD out for government and military use, where the most confidential links are.
• Longer keys as the stopgap: miss. I recommended longer classical keys, per the NSA's list, as the short-term defence. That list was CNSA 1.0: RSA at 3072 bits or more, and elliptic curves on P-384. The CNSSP 15 update replaced it with CNSA 2.0, and the NSA's October 2026 FAQ answers "No" to larger RSA or ECC keys.
• A 20-million-qubit annealer around 2037: miss, twice. I extrapolated D-Wave's qubit growth to a 20-million-qubit machine around 2037, treating the 20-million-qubit RSA-2048 estimate as if it applied to annealers. It never did: the 2019 estimate is for a gate-based superconducting machine. And the target did not wait: by May 2025 it was under a million qubits.

The calls that held were about what institutions would publish and do. The worst miss extrapolated a machine; the other leaned on a list its own publisher has since replaced. So my advice to my earlier self is the one this article rests on: trust published deadlines over anyone's Q-day estimate, mine included. The estimate I used has since fallen more than twentyfold, and the two operators who set new dates in 2026 chose 2029.

None of this waits for a quantum computer, and each step decides something:

1. Inventory RSA and ECC against data lifetime. List where RSA and ECC protect something (TLS, VPN, PKI, code signing, vendor integrations) and, next to each, how long that data must stay secret. That is your X: it decides which systems sit inside the harvest-now-decrypt-later window, and it is the discovery the NCSC's March 2025 timelines ask for by 2028.
2. Confirm hybrid key exchange where it already ships. Check browsers, OpenSSL and OpenSSH versions, and the TLS endpoints in front of your services for X25519MLKEM768 or mlkem768x25519-sha256. That sorts the traffic already out of the harvest window from the stacks that lag.
3. Ask your vendors for a dated PQC roadmap, signatures included. Key exchange is the easy half. Certificates, firmware signing, HSMs and TPMs are where a product may need replacing rather than patching, and the published deadlines cover signatures too. The answers set your budget and your real date.

Start with the inventory: it is the one step you cannot outsource.