Part 11: Reading the Field Like a Professional
Table of Contents
(Updated: July 2026)
This is Part 11 of Quantum Computing for Cybersecurity Professionals, an 11-part series that builds quantum computing from the ground up for security and IT professionals who know classical crypto but have no physics background. No lies-to-children, no hype, every claim checkable with arithmetic. Read the full series online or download the free ebook.
Four numbers, fourteen years apart. In 2012, Austin Fowler and colleagues estimated that breaking RSA-2048 would take roughly a billion physical qubits. In 2019, Gidney and Ekerå brought it down to 20 million, running for eight hours. In May 2025, Gidney cut his own figure to under a million. By February 2026, the Pinnacle architecture claimed under 100,000, and a neutral-atom study argued the job could run on as few as 10,000 atoms.
A drop of five orders of magnitude in fourteen years, and none of it came from better hardware. Gidney’s 2025 paper assumes the same gate error rates and cycle times as his 2019 paper; the 2026 papers change the error-correcting code and the machine’s architecture, not the physical qubits underneath. The devices did not improve. The mathematics and the engineering of how to arrange them did.
That fact organizes this final part. Ten articles built you the physics; this one turns it into equipment. You will get the two clocks that govern your exposure and why you can only see one of them, the specific milestones that would move a timeline and the announcements that never will, the standing answers to the questions you will be asked for the rest of your career, and the arithmetic that sets your actual deadline. Which, as it happens, was never Q-Day.
The clock you cannot see
Every roadmap you will be shown tracks hardware. Qubit counts, error rates, delivery dates, a tidy line climbing to the right. Hardware is visible because it is expensive, physical, and announced by companies who want credit for it. You can track it, and Part 10 taught you how.
The second clock tracks the resource model, and it runs in silence. It ticks when a researcher finds a cheaper circuit for modular arithmetic, when a new code stores idle logical qubits more efficiently, when someone works out how to make magic states without a distillation factory the size of the rest of the machine. Gidney’s twentyfold drop came from exactly that: approximate residue arithmetic borrowed from Chevignard and colleagues, yoked surface codes, magic state cultivation. The 2026 papers moved the number again by swapping the whole error-correcting architecture, qLDPC codes in one case, reconfigurable atoms in another. No new hardware, no announcement schedule, no roadmap, no warning. A preprint appears (Gidney’s appeared on a Wednesday in May, with no press cycle at all), and the number that governs your exposure changes by an order of magnitude overnight.
Your organization’s exposure is a function of both clocks, and most executive information diets cover one of them. When a CISO tells me they are watching the hardware roadmaps closely, my honest reply is that they are watching the clock that has moved least. Real, demonstrated physical qubit counts have grown by roughly two orders of magnitude since 2012. The modeled requirement to break RSA-2048 has fallen by five. Those are different kinds of number, a device that exists against an estimate on paper, and you should never plot them on one axis. But the asymmetry in how fast each moves is the whole point: the clock nobody puts on a slide is the one setting the pace.
FOR THE RECORD: The trajectory, and the honest counterweight.
Published estimates of the physical qubits needed to factor RSA-2048:
| Study | Estimate | Runtime | Architecture / status |
|---|---|---|---|
| Fowler et al., 2012 | ~1,000,000,000 | ~1 day | Surface code; peer-reviewed |
| Gidney-Ekerå, 2019 | 20,000,000 | 8 hours | Surface code; peer-reviewed (2021) |
| Gidney, 2025 | <1,000,000 | <1 week | Surface code, yoked storage; preprint |
| Pinnacle (Webster et al.), 2026 | <100,000 | trade-off | qLDPC; preprint |
| Cain et al., 2026 | ~10,000 | much longer | Neutral-atom; preprint |
Do not read this as one smooth trend line. Only the 2019-to-2025 step is like-for-like, same assumptions, so its 20× reduction is a clean measure of algorithmic progress. The rest change codes, connectivity, and runtimes, and the last three rows are unreviewed preprints on machines nobody has built. Google’s public tracker follows the 2012-2025 surface-code sequence and predates the 2026 architecture studies.
Now the counterweight, because a curve extrapolated without friction is a fantasy. These estimates model idealized machines. They assume independent errors, and Part 10 showed you Google’s own finding that correlated bursts strike roughly hourly and break codes designed for independence. They assume decoders keep pace, control electronics scale, cryogenic plumbing scales, and fabrication yields hold across a million qubits, none of which is demonstrated. Real engineering has a way of adding zeroes back. The trend is real and the friction is real, and anyone selling you only one of them is selling.
What would actually change my mind
Given both clocks, the professional question stops being “when is Q-Day” and becomes “what would I have to see.” Here is my list, framed against the capabilities in my CRQC Quantum Capability Framework, and I offer it as a falsifiable commitment rather than an opinion.
A logical qubit that runs for hours rather than seconds, with real-time decoding holding the whole way, would move me. Shor against RSA-2048 needs days of unbroken operation, and nothing demonstrated so far runs anything like that long. A logical two-qubit gate measured at an error rate far below anything shown today would move me, and I want to see a gate error, not a memory error borrowed from an idle encoded qubit and quoted as though the two were the same number. A cheap solution to magic state production would move me, since non-Clifford gates currently dominate the machine’s footprint and a large improvement there compresses every estimate at once. An architecture that handles correlated error bursts would move me, because that problem is unsolved and unpriced. And a genuine end-to-end Shor run on a number large enough that the circuit could not have been pre-simplified using the answer would move me most of all, because it would mean the integration problem is solved and only scale remains.
One of my tripwires has already fired, and I am obliged to say so rather than quietly revise the list. Two years ago I would have told you that an order-of-magnitude drop below Gidney’s million physical qubits would be a significant event. Pinnacle and the neutral-atom studies delivered exactly that, on paper, within a single quarter. It did not move Q-Day, because none of those machines exists and none of those papers has been through review. It did move my estimate of how fast the number can move without any hardware changing.
Now the announcements that will be pushed at you as evidence. A new qubit-count record moves nothing on its own; those are physical qubits, the easiest number in the field to grow, and Part 10 explained why the headline number is the wrong number. A “quantum supremacy” or random-circuit-sampling result carries no cryptanalytic content whatsoever, though it does test control and calibration at scale, so give it that much and no more. A factoring “record” achieved with annealing, variational methods, or Schnorr-style hybrid tricks moves nothing; those claims have appeared repeatedly for a decade and none has scaled, which is why implementations of Shor’s algorithm have still factored nothing bigger than 15 and 21 and why a 48-bit factoring demonstration tells you nothing about RSA-2048. And a vendor roadmap slipping two years should update your confidence in that vendor, by rather less than a demonstrated capability would. Roadmaps are marketing documents with engineering attached.
WHERE THIS BREAKS: The two clocks are not independent.
The two-clock model is the most useful frame I know for this problem, and it has one limit worth naming. The clocks are coupled. Gidney’s yoked surface codes assume a particular hardware geometry; magic state cultivation assumes particular gate fidelities; algorithmic wins are frequently made possible by hardware properties, and hardware roadmaps are steered by what the algorithms need. A better model is two runners tied at the ankle, sometimes helping and sometimes tripping each other. The operational lesson holds regardless: you are watching one runner and betting on both.
The standing answers
You will be asked these for the rest of your career, often by people who have just read something breathless. Each answer is one sentence, with the full argument a click away.
“Isn’t a quantum computer just a much faster computer?” No, it is a different machine that wins on a narrow class of structured problems and loses everywhere else. (Part 1)
“Isn’t a qubit 0 and 1 at the same time?” No, it holds a weighted combination of 0 and 1 whose weights can cancel, which is what “0 and 1 at once” cannot describe. (Part 3)
“Doesn’t measurement require a conscious observer?” No, a measurement is any interaction that leaves a record anywhere, and minds have never entered into it. (Part 3)
“Isn’t the qubit really 0 or 1, and we just don’t know which?” No, and this one is settled experimentally: treating a superposition as a hidden value predicts a coin where the bench delivers certainty. (Part 4)
“Doesn’t it try every answer at once?” It computes with the amplitudes of every possibility, then reads out one string, so parallelism alone yields a random guess; interference aimed by structure is where all the advantage lives. (Part 5)
“Can’t entangled qubits communicate instantly?” No, local statistics never move no matter what the far end does, so there is no channel and no bit. (Part 6)
“Will quantum computers break all encryption?” No, they break public-key algorithms built on factoring and discrete logs, while symmetric ciphers and hashes hold. (Part 9)
“Do we need AES-512?” No, AES-256 is the answer, and the reasons why are more interesting than the answer. (Part 9)
“They just announced a thousand qubits, are we close?” Those are physical qubits, the easiest number to grow; RSA-2048 needs thousands of logical ones, and the number of physical qubits each takes depends entirely on the error-correcting architecture. (Part 10)
“Should we buy quantum encryption?” Ask which of four unrelated products they mean, and the answer for general systems is post-quantum cryptography, which is software. (Part 1)
Your deadline was never Q-Day
Everything above concerns a machine whose arrival nobody can date. Notice how little that matters.
Go back to Mosca’s inequality from Part 1: if the years your data must stay secret, plus the years your migration will take, exceed the years until a cryptographically relevant machine exists, you are already late. Two of those three numbers belong to you. Only the third belongs to the physicists, and it is the only one anyone argues about.
Used properly, Mosca’s inequality is not a doomsday clock. It is a sorting function. Run it per data class and it partitions your estate immediately: session tokens with a ninety-day life and a three-year migration are comfortable under any plausible timeline, while patient records with a fifty-year confidentiality requirement are already past due under every plausible timeline, and no argument about Q-Day changes either verdict. The arithmetic box below works both cases. What falls out is a priority order you can defend to a board without ever predicting anything.
And your true deadline is set elsewhere, which is the argument I have made at length and stand behind. Regulators have published dates. NIST IR 8547 remains an Initial Public Draft, but its proposed deprecation of quantum-vulnerable RSA and ECC after 2030 and disallowance after 2035 already has teeth: Executive Order 14412 and OMB M-26-15 treat those dates as federal compliance deadlines, and procurement, audit, and insurance pressure follows the dates regardless of the document’s formal status. CNSA 2.0 binds national security systems and their supply chain on a schedule already running. Insurers are asking. Clients are asking, and their procurement questionnaires do not have a field for your Q-Day estimate. None of these actors will wait for a physicist to ring a bell, and every one of them can hurt you before the first CRQC boots.
THE ARITHMETIC: Solve it for your own estate.
Mosca: you are late when $$x + y > z$$, where $$x$$ is your data’s required confidentiality lifetime, $$y$$ is your migration time, and $$z$$ is the years until a CRQC.
Case one, session tokens. $$x = 0.25$$ years. $$y = 3$$ years for a contained TLS-layer migration. So $$x + y = 3.25$$. Is a CRQC more than three years away? Almost certainly. Verdict: comfortable, and it can wait its turn.
Case two, patient records. $$x = 50$$ years, because a genome does not expire. $$y = 7$$ years, which is realistic for a large hospital network with embedded devices and vendor dependencies. So $$x + y = 57$$. Is a CRQC more than fifty-seven years away? Nobody serious will make that claim. Verdict: you are already late, and were late when the data was first transmitted.
Neither verdict required a Q-Day prediction. The first is safe under every estimate and the second is doomed under every estimate, so the uncertainty that dominates public argument is irrelevant to both. That is the whole trick: the estimate for $$z$$ only matters for data in the middle band, and for everything else your own two numbers decide it. Run the inequality across your data classes and the sorting does itself. My CRQC Readiness Benchmark lets you vary $$z$$ under your own assumptions if you want to see the middle band move.
So the action list is short, and none of it depends on knowing anything about physics. Build a cryptographic inventory, because you cannot migrate what you cannot see, and remember from Part 9 that the exposure lives in key exchange and signatures rather than in the cipher suite. Sort the inventory by data lifetime, using the arithmetic above. Demand crypto-agility in every procurement from today onward, so the next transition is a configuration change. Start moving key establishment to the standardized algorithms, hybrid where prudent. And treat signatures as the slower, harder problem they are, since trust now, forge later attacks the roots you cannot swap quickly. My PQC Migration Framework is free and covers the sequencing in detail.
ATTACKER’S-EYE VIEW: The adversary’s project plan is already executing.
Assemble everything this series taught you and look at the problem from the other desk. A well-resourced adversary in 2026 has a program plan with three streams running in parallel, and none of them requires a quantum computer to exist.
Stream one, collection: capture and warehouse quantum-vulnerable handshakes and ciphertext whose value outlives the protection. Note the mechanism precisely, because this is where most threat models go wrong. Forward secrecy does not save you: a recorded TLS session using ordinary ephemeral ECDH is still readable later, because the attacker Shors the ephemeral public values sitting in the transcript. Long-term keys are the richest target wherever static key transport or key wrapping depends on them. Passive collection is cheap and effectively undetectable at the endpoint, which is why you should treat it as a present threat rather than wait for proof of a particular archive. Stream two, positioning: identify long-lived signing roots and code-signing keys whose trust must outlive the machine, because those become forgery opportunities the moment the mathematics gives way. Stream three, patience: fund the hardware, or simply wait for someone else to.
The streams do not all mature on one day, and the runtime is architecture-dependent rather than universal. What holds is the asymmetry. The adversary needs the machine to work once, unreliably, in a lab, with no service-level agreement and no uptime commitment. You need your migration finished before that run happens against data that still matters. The fragility of quantum computers, which is real and which Part 10 documented in detail, protects them and not you.
Date uncertainty changes which assets you move first. It does not remove the need to start a migration whose own duration is measured in years.
What to remember
Two clocks govern your exposure: hardware, which you can watch, and the resource model, which you cannot. The second has moved faster, cutting the RSA-2048 estimate by five orders of magnitude in fourteen years with no hardware improvement at all, which means the number that determines your risk can change on any given Wednesday without warning. Judge announcements by which capability they move, since qubit records, sampling stunts, and annealing-based factoring claims move none. Mosca’s inequality is a sorting function rather than a prophecy, and run across your data classes it produces a defensible priority order without predicting anything. Your real deadline comes from regulators, insurers, clients, and the shelf life of your own secrets, all of which are already set. And the adversary needs the machine to work once; you need to be finished before it does.
The three items, revisited
Part 1 opened with three things crossing your feed in a single week: a processor announcement with a record qubit count, an article explaining that quantum computers try every combination at once, and a colleague forwarding both with the subject line “should we be worried about AES?”
Of the two factual claims in that pile, exactly one was accurate, and I said so before you had any way to check.
You can check now. The qubit count is real and nearly meaningless, because those are physical qubits and the machine’s capability is decided by logical error rates, decoder speed, and sustained operation. The article is wrong, and you can say precisely why: the register does hold every possibility, and the readout returns one Born-random string, so parallelism alone is a very expensive coin toss and only interference aimed by structure converts it into an answer. And your colleague’s email was the right question aimed at the wrong target. No, we should not be worried about AES. We should be worried about the elliptic-curve handshake that delivered the AES key, which a fault-tolerant machine breaks while never touching the cipher at all.
Eleven parts ago that reply would have needed a physicist. It needs you.