Stop Asking When Quantum Will Break RSA

The most common question about post-quantum cryptography (PQC) is also the least useful one: “When will quantum computers break RSA or ECC?” People try to guess years. 2030. 2035. Maybe never. This focus on timelines creates noise and distracts from the real issue, which is risk management over the lifetime of your data.

If you are responsible for protecting information that must stay confidential for 5, 10, or 20 years, the exact year quantum computers will reach a given capability is almost irrelevant. What matters is that there is a credible path from research to a machine that can break today’s public key systems, and that an attacker can record your traffic now and decrypt it later.

The Real Threat: “Harvest Now, Decrypt Later”

The harvest-now-decrypt-later model is simple:

1. Intercept and store encrypted traffic today.
2. Wait until quantum computers are strong enough.
3. Decrypt everything in bulk.

This model is realistic for adversaries with long time horizons and large storage. Nation states and some well-funded organizations already capture massive amounts of traffic for intelligence and analysis. Once a viable quantum machine exists, old sessions that relied only on RSA or ECDHE for key agreement become readable.

If the confidentiality lifetime of your data is longer than the expected time to quantum break, then you already have a problem, even if the break has not happened yet.

PQC Makes the Timeline Question Irrelevant

Post-quantum key encapsulation mechanisms (KEMs) provide key agreement that is believed to be secure against known quantum algorithms. When you deploy them in a hybrid configuration with classical key exchange, you change the risk profile.

• If the classical algorithm fails in the future but the post-quantum KEM holds, the session keys remain safe and harvested traffic stays confidential.
• If the post-quantum KEM is weakened and the classical part remains strong, the session is still secure.

The important point is that you no longer need to be correct about the quantum timeline. You reduce your dependence on a guess. You design your TLS so that both classical and post-quantum components would have to fail to expose past traffic.

We Have Done This Before

Cryptography evolves. There is a long history of moving away from algorithms once their margin shrinks or new attacks appear.

The migration away from SHA-1 started when the cryptographic community showed structural weaknesses and practical collisions became realistic. The industry did not wait for a spectacular disaster in every protocol that used SHA-1. It treated the weakening as enough signal to move to SHA-256 and beyond.

The same thing happened with short RSA keys and legacy block cipher modes. Once the cost of attacks and the cost of staying on old primitives crossed a certain threshold, moving forward was the only responsible option.

Post-quantum cryptography is another step in that same pattern. The difference is that this time the future break is expected to be much more dramatic.

What “Pragmatic PQC” Looks Like

A pragmatic approach does not mean enabling every experimental algorithm on every endpoint overnight. It means aligning deployment with your actual risk.

For example:

• Prioritize systems that handle data with long confidentiality requirements, such as identity, health, finance, or sensitive internal communications.
• Add hybrid post-quantum key exchange at the TLS termination points for those systems, starting with internet-facing services.
• Track where you are already using PQC, and where you are still relying only on classical key exchange.
• Monitor your external surface over time to detect regressions and new non-PQC endpoints.

You do not need to solve everything in one release. You need a clear picture, a plan, and evidence that you are making progress.

How QCReady Fits In

QCReady exists for a simple reason. It should be trivial to verify whether your public TLS endpoints are using post-quantum capable key exchange or not. The tool scans your domain and reports:

• Which TLS versions and key exchange groups your endpoints actually negotiate.
• Whether you are using NIST-selected post-quantum KEMs or hybrid groups.
• Where you are still exposed to a pure classical key agreement that is vulnerable to harvest-now-decrypt-later.

This turns an abstract discussion about quantum timelines into concrete facts about your own infrastructure. Instead of debating “when will RSA be broken,” you can answer a better question: “If someone records my TLS traffic today, will it still be confidential when a large quantum computer arrives?”

If the honest answer is “probably not,” then the right moment to start is now. Check your PQC readiness with QCReady today. For a more comprehensive TLS health survey, consider SSLboard.

Photo by Braden Collum on Unsplash