Last week a number travelled fast through the security world: 22,593. That is how many physical qubits the French quantum company Alice & Bob estimates Shor's algorithm would need to factor RSA-2048, in about 3.14 days, on its cat-qubit architecture. The paper, "Shor's algorithm compiled on cat qubits: 22 593 qubits for RSA-2048 in 3.14 days," was posted to the IACR ePrint archive on October 28, and the company announced it the next day.

If you build software that encrypts things, this number deserves a careful read, not a panicked one. It is real progress in resource estimation. It is not a machine, and it is not a date.

Where the number comes from

The headline figure is the latest point on a steep downward curve. Alice & Bob's own estimates for breaking RSA-2048 on cat qubits were roughly 350,000 in 2023 and just under 100,000 in 2024. Now it is about 23,000. For comparison, the company says its architecture needs about 40 times fewer physical qubits than Google Quantum AI's Craig Gidney estimated in 2025, which was on the order of one million transmon qubits. The same paper puts a Bitcoin key at roughly 30,000 physical qubits in about one hour.

The reason cat qubits get a smaller number is hardware-level error suppression. A cat qubit is designed so that bit-flip errors are suppressed by the physics of the device itself, which means the error correction layer only has to deal with phase flips. Fewer errors to correct means fewer physical qubits per logical qubit, and the whole machine shrinks. Alice & Bob also switched from the repetition code used in its earlier estimates to more efficient LDPC-cat codes, which is a large part of why the number fell so far between 2024 and now.

That is genuinely interesting engineering. It is also the part of the story where the fine print starts to matter.

The assumption doing all the work

The headline figure assumes no bit flips at all during the computation. In the company's own words, that is equivalent to a bit-flip time of about one century. If bit flips instead occur about once an hour, the same calculation needs roughly 45,000 qubits, nearly double.

That assumption has not been demonstrated at scale. Cat qubits exist in labs and show the promised bit-flip suppression in small devices, but nobody has built tens of thousands of them into a fault-tolerant machine running Shor's algorithm for three days straight. The paper is a preprint, not yet peer reviewed, and the "record low" framing comes from the company's own press release. Other researchers quoted in coverage made the same point: the estimate is a blueprint of a machine that would be built, not a measurement of a machine that exists.

So the honest summary is this: if cat qubits scale the way their designers hope, breaking RSA-2048 gets much cheaper than the previous best estimates suggested. The "if" is doing a lot of work, and it will stay that way until hardware catches up with the math.

Why the number still matters

It would be a mistake to dismiss the estimate entirely because of its assumptions. Resource estimates for breaking RSA have fallen repeatedly, across different architectures and different research groups, for more than a decade. Every time someone finds a smarter way to compile Shor's algorithm or a more efficient error-correcting code, the machine that does not exist yet gets smaller. The direction of travel is consistent even when individual numbers are optimistic.

That direction matters because of one specific threat: harvest now, decrypt later. An attacker does not need a quantum computer today. They need to record encrypted traffic today and keep it until a machine capable of breaking it exists. Session keys protected by forward secrecy limit that damage for live conversations, but long-term keys, stored backups, signed documents, and anything encrypted with a static RSA key do not get that protection. Data with a long shelf life, medical records, state secrets, private messages archived for years, is exposed to a machine that might arrive in the 2030s.

This is also why the timing of the announcement matters. Two days before it, NIST published the final version of its transition report, IR 8547, which says quantum-vulnerable public-key cryptography will be deprecated after 2030 and disallowed under NIST standards after 2035. The two documents are independent, but they point the same way: the window for treating migration as a future project is closing.

What I would actually do about it

I build a messenger, so this is not abstract for me. My own project already pairs ML-KEM-768 key exchange with ML-DSA-65 signatures, and working through that migration taught me a few practical things that apply far beyond one app.

First, find out where RSA and elliptic-curve cryptography actually live in your system. Most teams are surprised. It is in TLS certificates, in old API clients, in backup encryption, in signed update packages, in the identity keys that users never rotate. You cannot migrate what you have not inventoried.

Second, start with key exchange, not signatures. Key exchange is where harvest-now-decrypt-later bites, and it is also the easier migration. A hybrid approach, ML-KEM alongside a classical algorithm like X25519, is the pragmatic choice while post-quantum standards are still bedding in: if either one holds, the session stays secret. TLS 1.3 already supports hybrid key exchange in practice, and libraries for ML-KEM are available in the major stacks now.

Third, design for crypto agility from the start. The algorithm you pick today will not be the last one you ship. Parameter sets get revised, standards get updated, and a migration that requires rewriting your protocol is a migration that will be postponed. If your code treats the key exchange mechanism as a replaceable module rather than something baked into every message format, the next migration costs weeks instead of months.

Fourth, do not wait for a perfect plan. The gap between "we should migrate" and "we have migrated" is measured in years for any real system, and the estimates above suggest the machine on the other side of that gap keeps getting smaller. Starting with the highest-value, longest-lived data first is a better strategy than waiting until every dependency is ready.

What not to do

Do not announce that Q-Day has arrived. No cryptographically relevant quantum computer exists today, and a preprint resource estimate is not one. Do not rip RSA out of everything overnight either; badly rushed migrations create outages and real vulnerabilities that are worse than the theoretical one you are trying to fix. And do not treat any single vendor's number as a timeline. Alice & Bob itself says it expects hardware improvements and falling resource requirements to converge in the early 2030s, and that is a company forecast, not a fact.

The number to remember from last week is not really 22,593. It is the trend behind it: every few years, breaking RSA gets estimated to be substantially cheaper than we thought. Builders who act on the trend, quietly and early, will be fine. Builders who wait for certainty will get it at exactly the moment they no longer need it.

Sources: Alice & Bob, "Shor's algorithm compiled on cat qubits: 22 593 qubits for RSA-2048 in 3.14 days," IACR ePrint 2026/2665; Alice & Bob press release, October 29, 2026; NIST IR 8547 (final, October 27, 2026).