Why 2026 Is Already Too Late for Quantum Security

Most organizations are treating quantum security as a 2029 or 2030 problem. That framing is wrong, and it is wrong in a specific, measurable way.

The threat is not "quantum computers will arrive and break your encryption." That part is still a few years away. The threat that is active right now is that your encrypted traffic is being collected today, stored, and held until quantum hardware matures. When it does, everything collected in 2026 becomes readable.

That is called harvest now, decrypt later. And 2026 is exactly where it hits.

The Question Is Not When, It Is How Long

Nobody knows exactly when a cryptographically relevant quantum computer will exist. Estimates from credible researchers and government agencies range from roughly 10 to 20 years. The NSA's CNSA 2.0 mandate sets 2030 as a planning deadline for national security systems, not as a predicted arrival date. Some researchers think that timeline is optimistic. Others think it may be conservative.

That uncertainty is the point. The honest answer is: we do not know. And that is precisely why harvest now, decrypt later is a serious problem today.

The question is not "when will quantum computers arrive?" The question is: how long does your data need to stay confidential?

• Healthcare records: HIPAA requires protection for the lifetime of the patient. A record created today may need to stay confidential for 40 or 50 years.
• Financial data: M&A communications, strategic plans, and trading strategies are routinely sensitive for 5 to 10 years.
• Legal and attorney-client communications: No expiry.
• Government and defense data: Classified materials routinely carry 25 to 75 year protection periods.
• Intellectual property: Source code, unreleased product designs, and R&D data can retain competitive value for a decade or more.

If your data falls into any of these categories and needs to remain confidential for 10 or more years, it is already inside the potential harvest window. Traffic captured today does not need to be re-exposed. It just needs to be held until the hardware to decrypt it exists, whenever that turns out to be.

Who Is Doing This

Harvest now, decrypt later is not a speculative attack. It requires two things: the ability to capture encrypted traffic at scale, and the storage to hold it. Both of those exist today.

The Snowden disclosures in 2013 confirmed that the NSA was collecting internet traffic at scale. China's MSS, Russia's FSB, and other well-resourced intelligence agencies have analogous capabilities. The cost of storing petabytes of encrypted traffic drops roughly 20 percent per year. What was expensive in 2020 is cheap in 2026.

This is not a theoretical risk for a future adversary. It is an ongoing operation by current ones.

Forward Secrecy Helps But Does Not Solve It

A common response to harvest now, decrypt later is: "We use TLS 1.3 with forward secrecy, so each session uses a unique key. Even if someone captures the traffic, they can't decrypt it without that session's ephemeral key."

This is partially true and importantly incomplete.

Forward secrecy prevents a single compromised long-term key from exposing all past sessions. That is valuable. But the ephemeral key exchange itself in TLS 1.3 uses ECDHE, which relies on the elliptic curve discrete logarithm problem. That problem is solved by Shor's algorithm on a quantum computer.

A quantum attacker cannot bulk-decrypt your entire traffic history from one key. But they can attack individual sessions. For high-value targets, that is enough. A nation-state adversary selectively decrypting the sessions most likely to contain valuable data is a realistic threat model.

The only fix is quantum-resistant key exchange: ML-KEM (FIPS 203), standardized by NIST in 2024. Chrome and Cloudflare already support hybrid key exchange combining ECDHE with ML-KEM. The standard exists. Deployment is the gap.

The Migration Window Is Also Closing

There is a second, separate reason not to wait. A full post-quantum migration takes 3 to 5 years for most organizations. Cryptographic inventory, library upgrades, application changes, hardware replacement cycles, and validation all take time. Organizations that have not started yet are not a year behind. They are starting at zero.

The NSA's CNSA 2.0 mandate requires national security systems and their vendors to support post-quantum algorithms by 2030. Supporting means tested, validated, and deployed - not in planning. If that deadline applies to your organization or your customers, the work needs to be underway now.

For commercial organizations outside the defense supply chain, there is no regulatory deadline yet. That absence of a deadline is what makes this problem easy to defer. Most organizations that are behind on PQC are not behind because they made a deliberate decision. They are behind because there was no forcing function, and other work took priority.

What You Can Do Right Now

The first priority is understanding your current exposure. You cannot make good migration decisions without knowing what cryptographic algorithms you are actually running.

1. Audit your certificates

Every RSA and ECC certificate in your infrastructure has a second expiry date: the date a quantum computer can factor or solve its key. Every classical key size is quantum-vulnerable regardless of length, so inventory all of your RSA and ECC certificates - shorter keys and older curves simply carry a higher urgency score.

2. Scan your network services

Identify which services are still negotiating RSA key exchange rather than ephemeral ECDHE. Eliminate static RSA key exchange immediately - it is the worst configuration because it offers no forward secrecy at all. Every past session is recoverable if the private key is ever broken.

3. Audit your binaries and source code

Cryptographic usage is embedded throughout most codebases in ways that are not visible from TLS configurations. Compiled binaries, third-party libraries, and application code calling crypto APIs directly all need to be inventoried. This is where most organizations discover they have far more exposure than they expected.

4. Start the conversation with your vendors

Your exposure is not limited to code you control. Third-party software, SaaS tools, and hardware devices you rely on all have their own cryptographic posture. Ask your vendors for their PQC migration timelines. The ones who do not have an answer are a risk to your own migration.

The Uncomfortable Truth About Timing

Quantum computers capable of breaking current cryptography are not here yet. That creates a false sense of safety. The threat feels abstract because the decryption event is in the future, and the future date is uncertain.

But the collection event is not in the future. Traffic captured today cannot be un-captured. There is no patch for data that has already been harvested. The only protection is ensuring that what gets captured now is protected by algorithms that remain secure regardless of when quantum hardware matures.

The uncertainty about timing is not a reason to wait. It is the reason to act now. You cannot know exactly when the window closes. You can know that it is already open.