Abstract

How many qubits and how long to break RSA is not one number but a function of assumptions, and the assumptions dominate. This piece treats resource estimation as a measurement-methodology problem: it dissects the inputs an estimate depends on, shows that the physical error rate is the sensitive variable that swings the answer superlinearly, explains why estimates have fallen by roughly two orders of magnitude as algorithms improved, and argues that single-date predictions are statistically unsound because there is no underlying time series to extrapolate. It closes with a critical-reading procedure that separates a rigorous, assumption-stated scenario from a qubit-count headline. The takeaway: cite estimates as ranges anchored to explicit assumptions, watch the physical error rate as the load-bearing input, and convert an uncertainty band — never a date — into a migration decision.

Ask when a quantum computer will break RSA and you will get answers spanning decades and hardware counts spanning orders of magnitude, which invites the cynical conclusion that nobody knows anything. That conclusion is wrong, but so is the confident single number it reacts against. A resource estimate is not a prediction plucked from the air; it is the output of a model whose inputs — physical error rate, gate synthesis cost, distillation efficiency, algorithm variant, connectivity — are individually defensible and jointly decisive. Understanding which inputs move the answer, and by how much, converts a confusing spread of headlines into something a planner can actually use. This article reads resource estimates the way a data scientist reads any model output: by interrogating its assumptions, its sensitivity, and its threats to validity, and by refusing to collapse a distribution into a point.

An estimate is a model, not a measurement

A quantum resource estimate composes several layers, each with its own assumptions. At the top is the logical algorithm — how many logical qubits and how many non-Clifford gates a factoring run of a given key size requires, which depends on the specific arithmetic circuits chosen. Below that sits the error-correction layer, which converts a target logical error rate into a code distance given an assumed physical error rate. Below that sits magic-state distillation, whose factory count and footprint depend on the non-Clifford gate budget. At the bottom sit hardware parameters: cycle time, connectivity, and the physical error rate itself.

Because these layers multiply, the final number is a product of assumptions, and stating the number without the assumptions is close to meaningless. The leading concrete result — Gidney and Ekerå (2021), roughly twenty million physical qubits and about eight hours for a 2048-bit modulus — is valuable precisely because it states its assumptions explicitly: a physical error rate somewhat below the surface-code threshold, a specific cycle time, and named algorithmic optimizations. That transparency is what makes it a scenario rather than a slogan.

The correct mental model is therefore a function with several inputs, not a fixed fact. The interesting question is not 'what is the number' but 'which input is the answer most sensitive to,' because that is where both the uncertainty and the leverage live.

Physical error rate and algorithmic efficiency jointly set the qubit count; the two together span orders of magnitude. What drives the estimate physical error rate: low (top) → high (bottom) algorithm: optimized (left) → naive (right) Low p, optimizedfewest qubits Low p, naivemore qubits High p, optimizedmore qubits High p, naivemost qubits
Physical error rate and algorithmic efficiency jointly set the qubit count; the two together span orders of magnitude.

The physical error rate is the sensitive variable

Not all inputs matter equally, and the physical error rate matters most. Recall that the required code distance grows as the physical error rate approaches the threshold, and the physical-qubit overhead grows roughly as the square of that distance. The consequence is a superlinear amplification: a device operating a factor of ten below threshold needs a far smaller distance — and therefore far fewer physical qubits per logical qubit — than one operating just under threshold. A modest improvement in the physical error rate can shrink the total machine by a large factor.

This is why a resource estimate that does not state its assumed physical error rate is effectively unfalsifiable. The same algorithm, at the same key size, can yield estimates differing by more than an order of magnitude purely from the error-rate assumption, with everything else held fixed. Sensitivity analysis — varying one input while holding the rest — is the honest way to present such a model, and the error rate is the input whose variation dominates the output.

For a reader, the practical rule follows immediately: the first question to ask of any estimate is what physical error rate it assumed and how far below threshold that sits. An estimate silent on this is reporting one point of a steep sensitivity curve without saying where on the curve it stands.

\[n_{\text{phys}} \;\propto\; d^{2}, \qquad d \;\sim\; \frac{\log(1/p_L)}{\log(p_{\mathrm{th}}/p)}\]
\[\text{small } \downarrow p \ \Longrightarrow\ \text{large } \downarrow d \ \Longrightarrow\ \text{large } \downarrow n_{\text{phys}}\]
⚠️
No error rate, no estimate. An estimate that omits its assumed physical error rate reports one point on a steep curve without saying where — treat it as unfalsifiable.

Estimates fall over time — because algorithms improve

A striking and underappreciated fact is that resource estimates for the same task have trended downward, not upward, as the field has matured. The reason is algorithmic: better modular-arithmetic circuits reduce the non-Clifford gate count, and more efficient magic-state distillation reduces the factory footprint per gate. The 2021 estimate is roughly two orders of magnitude smaller than some earlier analyses of the same problem, a reduction driven by optimization rather than by any change in the underlying hardware.

This trend cuts against a naive intuition that the target is fixed and only hardware moves. In reality both move: hardware improves the physical error rate and qubit count, while theory improves the algorithm and the error-correction overhead. An estimate is a snapshot of the best known method at a moment, and the best known method keeps getting cheaper. A responsible reading therefore treats today's estimate as an upper bound likely to be revised down, not as a stable floor.

The data-science caution is to avoid survivorship and recency bias: the most-cited estimate is not necessarily the most current or the most conservative. When comparing figures across sources, normalize them to the same key size, the same assumed error rate, and the same algorithmic assumptions before drawing any conclusion — otherwise the comparison measures modelling choices, not physics.

Successive algorithmic optimizations reduced the same-task qubit estimate by roughly two orders of magnitude. Estimates have fallen with better algorithms algorithmic progress → Earlier analyses~10^9 qubits Better arithmeticfewer non-Clifford gates 2021 study~2x10^7 qubits
Successive algorithmic optimizations reduced the same-task qubit estimate by roughly two orders of magnitude.

Why a single date is statistically unsound

The most common misuse of resource estimates is to attach a calendar date — 'RSA falls in year Y.' This is unsound not because the future is unknowable in principle but because the inference has no valid basis. A date requires extrapolating a trajectory of hardware quality and scale, but there is no long, stable time series of the relevant metric (sustained logical qubits at a fixed logical error rate) from which to extrapolate; the field is young and the metric definitions have shifted. Fitting a line to a handful of noisy, non-comparable points and reading off a crossing year is a textbook overfit.

Expert-survey approaches, which aggregate specialists' subjective probabilities, are more honest because they report a distribution rather than a point, but they inherit the well-known biases of expert forecasting and should be read as elicited belief, not measurement. The correct output of any such exercise is a probability spread across years, widening with horizon — not a single most-likely date presented as a deadline.

The threats to validity are worth naming explicitly, in data-science terms: no stationary time series (the generating process is changing), non-comparable measurements (metric definitions differ across sources), small sample size (few independent estimates), and selection effects (dramatic estimates are cited more). Each argues for reporting a range with stated assumptions and against reporting a date.

  • No stationary time series: the metric that would be extrapolated is young and shifting.
  • Non-comparable measurements: estimates differ in key size, error rate, and algorithm.
  • Small sample: only a handful of independent, rigorous estimates exist.
  • Selection bias: the most dramatic numbers get the most citations.

A procedure for reading a claim

Given all this, reading a resource claim well is a short, disciplined procedure rather than an act of faith. First, check whether the claim states its assumed physical error rate and its relation to the code threshold; if not, weight it near zero, because it reports an unlocated point on a steep curve. Second, check whether it states the code distance and the magic-state distillation assumptions, or at least the logical-qubit and non-Clifford-gate counts, so the overhead can be reconstructed. Third, check whether it presents a range or a single point, and prefer sources that give a range.

Only claims that survive those checks deserve to be read as scenarios and folded into planning, and even then as one scenario among several, with its assumptions carried alongside the number. A claim that fails them is a headline, useful for gauging attention but not for engineering decisions. This is not pedantry; it is the difference between planning against a modelled range and planning against a rumour.

The output of the procedure is never a date. It is a weighted set of scenarios — best case, central, conservative — each tagged with its assumptions, from which a planner extracts the one input that matters for their decision: is a machine of sufficient scale and quality plausible within the shelf-life of the secrets they must protect.

A short gate that separates an assumption-stated scenario from a qubit-count headline. Reading a resource claim no yes yes no A resource claimqubits + time States error rate?vs threshold Weight ~ zerounlocated point States d & distillation?reconstructable? Read as scenariowith its bands Treat as headlinelow weight
A short gate that separates an assumption-stated scenario from a qubit-count headline.

From a range to a decision

The purpose of reading estimates critically is not to arrive at certainty but to bound a planning horizon. Once an estimate is expressed as a range anchored to assumptions, the decision-relevant question is narrow: across the plausible scenarios, is there a meaningful probability that a sufficiently large, sufficiently low-error machine exists within the number of years your most sensitive secrets must remain confidential. If yes, the migration decision is made now, because the alternative — waiting for the date to be certain — guarantees that long-lived data harvested today is exposed later.

This reframing dissolves the apparent paradox that we must act on an uncertain timeline. We do not need a date; we need a defensible upper bound on when the capability could plausibly arrive, compared against a well-known quantity — how long our data must stay secret. The uncertainty in the estimate widens the safety margin we should demand, it does not license inaction.

The disciplined summary is this: treat every resource estimate as a model output with a dominant sensitive input (the physical error rate), a downward trend (algorithms improve), and no valid single-date interpretation; report it as a range; and convert that range into a migration decision by comparing it to data shelf-life, not to a calendar.

Reading checklist applied (illustrative weighting, not a scoring rubric).
Property stated?If yesIf no
Physical error rate + thresholdlocate on sensitivity curveweight near zero
Code distance / distillationreconstruct overheadcannot verify
Range vs single pointuse as scenario bandtreat as headline
Key size normalizedcompare across sourcescomparison invalid

Key takeaways

  • A resource estimate is a model whose output is the product of several assumption layers (algorithm, error correction, distillation, hardware); the number is meaningless without its assumptions.
  • The physical error rate is the dominant sensitive input: overhead grows roughly as the square of the code distance, so small error-rate improvements shrink the machine superlinearly.
  • Estimates for the same task have fallen by roughly two orders of magnitude over time because algorithms improve — today's figure is an upper bound likely to be revised down.
  • Single-date predictions are statistically unsound: there is no stationary, comparable time series to extrapolate, so report a probability spread widening with horizon, not a deadline.
  • Read a claim by checking it states its error rate, its distance/distillation assumptions, and a range; claims failing these are headlines, not engineering inputs.
  • Convert the resulting range into a decision by comparing it to the shelf-life of your secrets — migrate long-lived data now rather than waiting for a certain date.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

✅Resource-estimate critique gatechecklist

Weight a published estimate before using it in planning.

  • Does it state the assumed physical error rate and its ratio to threshold?
  • Does it give code distance and distillation assumptions (or logical-qubit and gate counts)?
  • Does it report a range, not a single point?
  • Is the key size stated so it can be normalized against other estimates?
  • Does it avoid attaching a calendar date as a prediction?
🚀Turn estimates into a horizonquickstart

Convert a spread of estimates into a single planning input.

  • Collect estimates; normalize each to your key size and a common error-rate assumption.
  • Express the result as best / central / conservative scenarios, not a date.
  • Compare the conservative scenario to your longest data shelf-life.
  • If overlap is plausible, trigger migration of long-lived secrets now.
🔒Estimate-hygiene assertionpolicy

A documentation gate for any internal quantum-timeline claim.

quantum_timeline_claim:
  must_state:
    - assumed_physical_error_rate
    - ratio_to_threshold
    - code_distance_or_gate_counts
    - key_size
  must_be: range          # reject single-point or dated predictions
  decision_input: compare_conservative_band_to_data_shelf_life
audit:
  reviewer_signoff: required
Illustrative governance policy, not a product config.

Glossary

Resource estimate
A modelled count of physical qubits and time to run a quantum algorithm, conditioned on stated hardware and algorithmic assumptions.
Sensitivity analysis
Varying one model input while holding others fixed to see how much the output moves; here the physical error rate dominates.
Magic-state distillation footprint
The qubit and time cost of producing the clean resource states needed for non-Clifford gates; a major driver of the total.
Threats to validity
Reasons a measurement or inference may mislead — here: no stationary series, non-comparable estimates, small samples, selection bias.
Uncertainty band
A range of plausible outcomes with stated assumptions, the correct output of estimation rather than a single point or date.
Data shelf-life
How long a secret must remain confidential; the fixed quantity an estimate range is compared against for a migration decision.

References

  1. Gidney & Ekerå, How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits (Quantum, 2021; arXiv:1905.09749)
  2. Fowler, Mariantoni, Martinis & Cleland, Surface codes: Towards practical large-scale quantum computation (Phys. Rev. A, 2012; arXiv:1208.0928)
  3. Mosca, Cybersecurity in an era with quantum computers: will we be ready? (IEEE Security & Privacy, 2018; arXiv:1512.06466)
  4. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (SIAM J. Comput., 1997)
  5. Grover, A Fast Quantum Mechanical Algorithm for Database Search (STOC, 1996)