Harvest Now, Decrypt Later: The Attack That's Already Happening — NyxqLab

If you ask most security leaders about their exposure to quantum computing, the typical answer is some variant of "that's still far off, it's not a priority now." It's an understandable answer, and also an incomplete one — because it assumes the risk starts the day a quantum computer capable of breaking encryption exists. In reality, the risk may have already started.

The attack doesn't need the quantum computer, it needs patience

Harvest now, decrypt later is an attack strategy with brutally simple logic: if you know that the cryptography your target uses today will be breakable in the future, you don't need to break it today. You only need to capture and store the encrypted traffic now, and wait.

This turns any communication encrypted with classical algorithms (RSA, ECC, Diffie-Hellman) that crosses a network an adversary can intercept — the public internet, in most cases — into a potential target for passive collection, with the victim having no way of knowing it's happening, and no way to retroactively prevent it once it's already occurred.

Why this isn't laboratory science fiction

It's not an exotic hypothesis. It's a concern explicitly acknowledged by the most serious national security agencies in the world:

• The NSA published its post-quantum cryptography migration roadmap (CNSA 2.0) in 2022, with concrete deadlines for national security systems, explicitly citing the risk of collecting encrypted data for future decryption.
• NIST itself accelerated its post-quantum algorithm standardization process precisely because of this concern — not because a quantum computer capable of breaking RSA was around the corner, but because the collection risk was already present.
• Multiple threat intelligence reports (from cybersecurity firms and government agencies) have pointed to large-scale traffic interception infrastructure as part of advanced state actors' capabilities for years — the technical capacity to capture encrypted traffic at scale already exists and is used today, regardless of when it can be decrypted.

Who actually has the threat profile for this attack

It's important to be realistic about who would execute this strategy, because it's not within everyone's reach. It requires:

• Large-scale interception infrastructure, capable of capturing massive volumes of encrypted traffic sustainably.
• Long-term storage capacity, potentially for a decade or more, until decryption technology matures.
• A time horizon belonging to an organization with institutional continuity — this fits state actors, not opportunistic cybercrime groups seeking immediate profitability.

This means the organizational profile with the most real exposure isn't "any company," but those handling information with sustained intelligence value: critical infrastructure, defense, government bodies, companies with strategic intellectual property, the financial sector with long-term data, healthcare with genetic data or medical histories.

How to assess your real exposure (without panic or denial)

The right question isn't "is this happening to me right now?" — there's no way to know for certain, and obsessing over that question doesn't lead to any useful action. The right question, the one we work through with every client, is:

What data do I encrypt today with classical algorithms that needs to remain confidential 10, 15, or 20 years from now?

If the answer is "none" — short-lived data, information that quickly loses value — your practical exposure to harvest now, decrypt later risk is low, and post-quantum migration priority can be moderate.

If the answer includes long-lived data — and in most organizations we audit, it does, even if they hadn't framed it in these terms — then every day that passes without starting to mitigate is another day of traffic potentially captured that will be exposed to whoever holds it, once the technology matures.

What can realistically be done today

1. Inventory what traffic crosses untrusted networks with what algorithm. You don't need to start with the most visible thing (public web TLS) — start with what combines the highest sensitivity and lifespan: inter-site VPNs, communication with critical vendors, backups leaving your network.

2. Prioritize migration to hybrid schemes (classical + post-quantum combined, like X25519+Kyber) on the channels identified as highest risk, not all at once — it's a progressive exposure reduction process, not an all-or-nothing project.

3. Demand a post-quantum roadmap from critical vendors. If you depend on third parties to process or transmit long-lived sensitive data, their exposure is also yours — it's worth explicitly asking what they're doing about it, not assuming they already have it solved.

4. Don't wait for it to be "fully ready." The NIST FIPS 203/204/205 standards are already published and stable. Migration doesn't have to be perfect from day one — it has to start, prioritized by real risk.

The real cost of inaction

The damage from this attack, if it's occurring, doesn't show up today. It shows up the day quantum decryption technology matures enough — and by then, there's no retroactive action possible on what was already captured. It's, literally, the only type of cybersecurity risk where waiting for "total certainty" before acting guarantees that, if the risk was real, it's already too late to do anything about it.