Quantum Computers Just Got 1,000x More Efficient at Breaking RSA. Developers Have Less Time Than They Think.

Three separate quantum computing breakthroughs were published in the first week of March 2026. Any one of them would have been a significant research milestone. Together, they represent the clearest signal yet that the timeline for quantum computers threatening RSA and ECC encryption is compressing faster than most security roadmaps assumed.

This is not a "quantum is coming eventually" article. The "eventually" just got a specific date range attached to it.

What Actually Happened This Week

AQTI's JVG Algorithm (March 2, 2026):

The Advanced Quantum Technologies Institute published a paper describing the JVG algorithm — a new quantum algorithm for integer factorisation (the mathematical problem that RSA encryption is based on) that requires approximately 1,000 times fewer quantum resources than previous best-known approaches.

The headline claim: breaking 2048-bit RSA encryption, which previously required estimates of millions of qubits with current error rates, could potentially be achieved with thousands of logical qubits using the JVG approach. The paper uses the phrase "cybersecurity apocalypse" in its abstract — language that is unusual for peer-reviewed research and reflects the authors' assessment of the urgency.

The JVG paper is undergoing peer review. Independent cryptographers have not yet fully validated the claims. Extraordinary claims require extraordinary evidence — but the paper is from a credible institution and the preliminary reaction from quantum computing researchers has been "this deserves serious attention."

Iceberg Quantum's Pinnacle Architecture (March 2026):

Separately, Iceberg Quantum published details of their Pinnacle Architecture using Quantum Low-Density Parity-Check (QLDPC) codes — a class of quantum error correction that dramatically reduces the number of physical qubits needed to produce a single reliable logical qubit.

Quantum computers make errors constantly. To get a single "logical qubit" that behaves reliably, you currently need hundreds or thousands of physical qubits just for error correction. Iceberg's QLDPC approach reduces this overhead by approximately 10x, according to their published numbers.

A 10x reduction in error correction overhead means a machine that today needs 1 million physical qubits to run a meaningful algorithm could potentially do the same with 100,000. This directly affects the timeline for cryptographically relevant quantum computing.

Phasecraft and DARPA's 2033 Target (March 3, 2026):

Phasecraft, a quantum software company focused on near-term quantum algorithms, announced a DARPA-funded programme specifically to measure and define the path to "utility-scale" quantum computing — machines that outperform classical computers on real problems — by 2033.

The DARPA framing is significant: the US government's advanced research agency is putting resources behind a 7-year timeline to useful quantum computing. DARPA does not fund things it considers science fiction. The 2033 utility-scale target is consistent with independent estimates from IBM (who published their quantum roadmap targeting useful quantum in the 2030-2035 window) and Google.

The Encryption Timeline You Need to Understand

Before this week, the consensus among cryptographers was roughly:

• 2030-2035: Quantum computers large enough to threaten 1024-bit RSA in ideal conditions
• 2035-2040: Threat to 2048-bit RSA (current standard) becomes credible
• Post-2040: 4096-bit RSA potentially threatened

The March 2026 breakthroughs compress this. If the AQTI JVG algorithm holds up to peer review and the Iceberg QLDPC approach delivers its claimed efficiency gains, the revised estimate looks more like:

• 2028-2030: Quantum computers that can credibly threaten 1024-bit RSA in research conditions
• 2032-2035: Threat to 2048-bit RSA in operational conditions
• 2033: DARPA/Phasecraft's stated target for utility-scale quantum

The gap between "research conditions" and "operational threat" matters. A quantum computer that can break RSA in a million-dollar lab under ideal conditions is not the same as one an adversary can deploy operationally. But the direction is clear and the pace is accelerating.

The "harvest now, decrypt later" threat:

There is an attack that does not wait for quantum computers to be deployed: adversaries — primarily nation-state intelligence agencies — are already collecting encrypted internet traffic today with the intent to decrypt it once quantum computers are available. Your HTTPS sessions, your VPN traffic, your encrypted emails sent in 2026 may be stored in a database waiting for a 2033 quantum computer to break the key exchange.

This is called a "harvest now, decrypt later" or "store now, decrypt later" attack. It is not theoretical — CISA and NSA have both issued advisories about this attack vector. Any data that must remain confidential for more than 7-10 years is potentially at risk from data encrypted today.

NIST Post-Quantum Standards: What's Already Available

NIST finalised its post-quantum cryptographic standards in 2024. These are algorithms designed to resist attacks from both classical and quantum computers. The three primary standards:

ML-KEM (formerly CRYSTALS-Kyber):

• Purpose: Key encapsulation (replaces RSA/ECDH for key exchange)
• Based on: Module Learning With Errors (MLWE) problem
• Status: NIST FIPS 203, finalised August 2024
• Supported in: OpenSSL 3.2+, BoringSSL, liboqs

ML-DSA (formerly CRYSTALS-Dilithium):

• Purpose: Digital signatures (replaces RSA-PSS and ECDSA)
• Based on: Module Learning With Errors
• Status: NIST FIPS 204, finalised August 2024
• Supported in: OpenSSL 3.2+, liboqs

SLH-DSA (formerly SPHINCS+):

• Purpose: Digital signatures (hash-based, conservative choice)
• Based on: Hash functions (well-understood security assumptions)
• Status: NIST FIPS 205, finalised August 2024

These standards exist. Libraries support them. The migration can begin now.

What Developers Need to Do, In Priority Order

Priority 1: Inventory your cryptographic dependencies (do this now)

Before you can migrate, you need to know what you are migrating from. Create a cryptographic inventory:

• Which TLS certificate authorities are you using and what key types?
• Do you use RSA or ECDSA for internal signing (JWT signatures, API signing, code signing)?
• Do you store encrypted data at rest with RSA-encrypted symmetric keys?
• Do you use PGP or S/MIME for email?
• Do you have IoT or embedded devices with hard-coded keys?

Most development teams cannot answer all these questions quickly. Building the inventory now — before the urgency is acute — is the first practical step.

Priority 2: Enable TLS 1.3 everywhere if you have not already

TLS 1.3 supports hybrid key exchange modes that can combine classical ECDH with post-quantum ML-KEM in the same handshake. This means you can start deploying post-quantum key exchange without fully replacing classical cryptography — providing defence-in-depth.

Google Chrome, Firefox, and Cloudflare have already enabled hybrid post-quantum TLS by default for many connections. Your server needs to support it. If you are running OpenSSL 3.2+ or using Cloudflare/AWS CloudFront as your TLS terminator, you may already have partial post-quantum protection without knowing it.

Priority 3: Identify long-lived secrets that need migration first

Not all encryption is equally urgent. Prioritise for migration:

• High urgency: Root CA keys, code signing keys, API signing keys that are used across many systems and are expensive to rotate
• High urgency: Data encrypted at rest that must remain confidential for 10+ years (medical records, legal documents, financial records with long retention requirements)
• Medium urgency: TLS certificates (short-lived by default, 90 days with Let's Encrypt — rotate to post-quantum algorithms at renewal)
• Lower urgency: Ephemeral session keys (these already have forward secrecy in TLS 1.3; quantum threat is lower)

Priority 4: Test post-quantum algorithms in non-production

The liboqs library (Open Quantum Safe project) provides implementations of NIST post-quantum algorithms that integrate with OpenSSL. You can test ML-KEM and ML-DSA in development environments without production impact. Performance benchmarks for your specific hardware are worth establishing now so you understand the overhead (typically 10-30% slower than current algorithms for most use cases).

Priority 5: Follow government mandates if applicable

If you work in US federal contracting, US critical infrastructure, or provide services to government agencies: the NSA and CISA have issued timelines for post-quantum migration that are now mandatory for government systems. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires post-quantum algorithms for new systems by 2025 and full migration by 2030. If your customers are in this category, you have contractual obligations, not just best practices.

What The Big Tech Companies Are Already Doing

Google: Deployed ML-KEM (formerly Kyber) in Chrome for TLS connections by default since 2023. Already protects a significant fraction of HTTPS traffic globally.

Apple: Added post-quantum cryptography to iMessage (PQ3) in February 2024. iMessage now uses a hybrid classical/post-quantum protocol for forward secrecy.

Signal: Upgraded its secure messaging protocol (PQXDH) to include post-quantum key exchange in 2023.

Cloudflare: Enabled hybrid post-quantum TLS on all Cloudflare-proxied connections by default.

AWS: Launched AWS Key Management Service post-quantum TLS support. Post-quantum algorithms available in AWS Certificate Manager.

The major platform providers have largely already started. The gap is in the long tail: applications built by development teams that have not yet prioritised this, internal systems with hard-coded cryptographic dependencies, and IoT devices that cannot be easily updated.

The Developer Mindset Shift Required

Post-quantum migration is fundamentally different from most security updates. It is not "patch a vulnerability" — it is "replace the foundational cryptographic algorithms your entire security model depends on." The analogies are:

• Migrating from SHA-1 to SHA-256 (which took years even after SHA-1 was known to be weak)
• Migrating from HTTP to HTTPS (which took a decade of industry effort to reach current adoption)

Those migrations happened gradually, driven by browser warnings, CA requirements, and eventually mandatory deprecation. Post-quantum migration needs to happen faster because the threat materialises on a specific timeline — and the harvest-now-decrypt-later attack means data encrypted today is at risk even before quantum computers are deployed.

The first week of March 2026 has provided three independent data points that the timeline is compressing. The correct response is not panic but prioritisation: start the inventory, establish the baseline, understand which systems carry the highest risk, and begin the migration for those systems first.

---

The quantum computer that breaks RSA does not exist yet. But the algorithm that makes it 1,000x more feasible was published this week. The engineering choices you make in 2026 about cryptographic systems will determine whether your long-lived data is protected when it does.