Stop Debating When Quantum Breaks RSA. Start Building the Ability to Switch.

Another week, another quantum breakthrough. On March 2, the Advanced Quantum Technologies Institute announced the JVG algorithm, a hybrid classical-quantum approach that, they claim, could factor RSA keys with fewer than 5,000 qubits. That is three orders of magnitude below the million-qubit estimates we have been working with for years.

The security press ran the story immediately. “Much closer than expected.” “Cybersecurity apocalypse.” The predictable alarm bells.

Here is the thing: it does not matter whether this particular paper is right.

The Pattern You Should Actually Be Worried About

The JVG paper is a preprint. It has not been peer-reviewed. The institute behind it is not widely known in the quantum computing community. These are not reasons to dismiss it, but they are reasons to hold the specifics loosely.

What matters more is the trend. In May 2025, Google’s Craig Gidney published research showing RSA-2048 could be factored with under a million noisy qubits, a 20x reduction from his own 2019 estimate. Earlier this year, Iceberg Quantum’s Pinnacle Architecture proposed doing it with under 100,000 physical qubits using quantum LDPC codes. Now the JVG claim takes it to under 5,000.

Each paper uses a different approach. Each arrives at the same conclusion: the bar is dropping. Fast.

Whether the realistic timeline is three years or fifteen is a question that genuinely smart people disagree on. And that disagreement is exactly the problem, because organisations are using the uncertainty as permission to wait.

The Wrong Question

“When will quantum computers break RSA?” is the question every board deck asks. It is also the wrong question.

The right question is: if we decided to switch our cryptographic algorithms today, could we?

For most organisations, the honest answer is no. Not quickly. Not cleanly. Not without breaking things.

The reason is straightforward. Cryptographic algorithms are not a setting you toggle. They are embedded in TLS configurations, certificate chains, VPN tunnels, API authentication, database encryption, hardware security modules, firmware, IoT devices, and a thousand other places where the algorithm choice was made years ago by someone who has since left the company.

Migrating to post-quantum cryptography is not a security project. It is an infrastructure transformation. And infrastructure transformations take years regardless of urgency.

Crypto-Agility Is the Actual Deliverable

The term the industry uses is crypto-agility: the architectural ability to swap cryptographic algorithms, keys, and protocols without rebuilding systems. It is not glamorous. It does not make headlines. But it is the thing that actually determines whether an organisation can respond when the timeline question finally gets a definitive answer.

Crypto-agility means three things in practice:

1. Know What You Have

You cannot migrate what you cannot find. Most organisations do not have a complete inventory of where cryptographic algorithms are in use across their environment. Not just certificates. Algorithms. Which systems use RSA-2048? Which use ECDSA P-256? Which use legacy algorithms that are already weak? Where is cryptography used in code, not just in infrastructure?

Automated discovery tools exist. Use them. Build a cryptographic bill of materials the same way you build a software bill of materials.

2. Abstract the Algorithm from the Application

The hardest migrations are the ones where the algorithm choice is hardcoded deep inside application logic. The easiest are the ones where cryptography is consumed through a library or service that can be updated independently.

If your applications call specific algorithm implementations directly, you have a coupling problem. The fix is abstraction. Cryptographic libraries that expose operations (sign, verify, encrypt, decrypt) without binding the caller to a specific algorithm. NIST’s post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) already have implementations in libraries like liboqs and AWS-LC. Your applications should not need to know which algorithm is behind the interface.

3. Automate the Rotation

Certificate and key rotation should not be a manual process. If it takes your team a change window and a runbook to rotate a certificate, you are not going to rotate thousands of them under pressure.

Automate issuance, deployment, and revocation. Test the automation regularly. When the migration order comes (and it will) the difference between “we can do this in weeks” and “we need eighteen months” will be whether you built the machinery in advance.

Monday Morning

Here is what you can do this week:

Start the inventory. Pick one business-critical application. Map every cryptographic dependency: TLS versions, cipher suites, certificate types, key sizes, algorithm choices in code. Multiply the effort by the number of applications you have. That is the size of your migration.

Test a hybrid deployment. NIST’s post-quantum standards are finalised. Pick a non-critical internal service and deploy hybrid key exchange (classical + post-quantum). See what breaks. See what your monitoring misses. See how your team reacts to something they have never done before.

Ask the uncomfortable question. Go to your architecture review board and ask: “If NIST told us tomorrow that RSA and ECDSA are compromised, how long would it take us to switch?” Write down the answer. That number is your actual risk exposure, not the qubit count in the latest preprint.

The Timeline Is Unknowable. Your Readiness Is Not.

Every six months, a new paper will move the quantum goalpost. Some will hold up under scrutiny. Most will not. The JVG algorithm may turn out to be a genuine breakthrough or another in a long line of optimistic extrapolations.

It does not matter. The organisations that will weather the quantum transition are not the ones who predicted the right date. They are the ones who built systems that can adapt regardless of the date.

Stop debating when. Start building the ability to switch.