Skip to content
Get in touch

Harvest now, decrypt later: why your traffic is already at risk

No quantum computer today can break the encryption protecting your network traffic. That fact gets repeated so often it's easy to hear it as reassurance. It isn't one because breaking the encryption is not the step an adversary needs to take right now.

Your traffic doesn't need to be broken today to be stolen today

The step that matters right now is copying the traffic. Encrypted data flowing across a data center interconnect, a site-to-site link, or a backbone connection can be intercepted and stored today, at negligible cost, without decrypting a single bit of it.

The decryption happens later whenever a cryptographically relevant quantum computer (CRQC) becomes available. Security teams call this harvest-now-decrypt-later. What it means in practical terms is that the theft already happened. Decryption is just the adversary collecting on an investment they made years earlier.

This why it’s important for critical organizations to inventory which of its network traffic would still matter to someone in ten or fifteen years.

How harvest-now-decrypt-later actually works

The attack has three stages, and only the last one needs a quantum computer:

  1. Intercept. An adversary with access to a network path, such as a state actor tapping a subsea cable or peering point, a hostile insider, a compromised carrier, copies encrypted traffic as it passes. This is passive. It requires no exploit, leaves no trace on the systems generating the traffic, and is already routine tradecraft for well-resourced intelligence services.
  2. Store. Bulk encrypted data is cheap to retain. Storage costs have fallen faster than almost any other input to this calculation, so holding years of intercepted traffic against a future payoff is a rational bet.
  3. Decrypt. Once a quantum computer capable of running Shor's algorithm at sufficient scale exists, the stored traffic's key exchanges are broken retroactively. Everything encrypted under them becomes readable, including the traffic captured years before the machine that finally reads it was built.

Nothing about this requires today's cryptography to be weak. TLS, IPsec, and SSH sessions secured with classical Diffie-Hellman or RSA key exchange are working exactly as designed against a classical adversary.

Harvest-now-decrypt-later isn't a flaw in the encryption but it's a mismatch between how long that encryption is expected to hold and how long the data actually needs protecting.

The only clock that matters: data lifetime versus decryption timeline

Nobody can tell you the exact year a cryptographically relevant quantum computer will exist. Estimates from researchers and national agencies range across the next decade and beyond, and the honest answer is that the uncertainty is real.

But planning around harvest-now-decrypt-later doesn't require solving that timeline but comparing two numbers you can actually estimate for your own data:

  • How long must this data stay confidential? A tactical military communication might need protection for months. A patient record, a national security file, or a long-term financial position may need it for decades.
  • How long until that quantum computer plausibly arrives, plus however long your organization needs to migrate once it's clear the deadline is real?

When the first number exceeds the second, the data is already exposed from the moment it crosses the network unprotected against harvest-now-decrypt-later. This is sometimes called Mosca's inequality, and it's the reason regulators and standards bodies have stopped treating "quantum computers don't exist yet" as a reason to wait.

Governments, defense, banks, healthcare systems, and critical infrastructure operators transmit sensitive data whose confidentiality needs to outlive a five-to-ten-year horizon. For them, the migration clock and the threat clock are running at the same time.

Why this isn't hypothetical anymore

Three things have moved harvest-now-decrypt-later from a theoretical talking point to an operating assumption inside serious security and compliance functions:

Standards bodies built the response before the threat fully arrived. NIST finalized its first post-quantum cryptography standards in 2024 specifically because the migration timeline, not the attack timeline, was the binding constraint. Large organizations take years to move cryptographic infrastructure, and that migration must be well underway before a quantum computer exists.

Regulators have written it into law and supervisory expectation. CNSA 2.0 requires new US national security systems to be quantum-safe from January 2027. The EU's NIS2 framework mandates a post-quantum transition for critical infrastructure by 2030.

DORA already requires EU financial entities to monitor quantum risk today, instead of some future review cycle. None of these bodies would set binding deadlines this far in advance for a purely speculative threat, but the deadlines reflect the years of lead time the harvest-now-decrypt-later math demands.

The economics favor the attacker, not the defender. Interception infrastructure for high-value network links is a known, already-built capability for state-level actors. Storage is cheap and getting cheaper.

Building the quantum computer is the only expensive, uncertain part of the attack, and a cost the adversary can defer indefinitely while the collection continues in the background. Waiting favors whoever is doing the harvesting, instead of whoever is deciding whether to defend against it.

What's already exposed

Harvest-now-decrypt-later doesn't threaten all data equally but concentrates on whatever has a confidentiality shelf life longer than the migration-plus-threat clock above. That describes, disproportionately:

  • Government and defense communications, where classification periods routinely run 25 years or more and the data is a standing target for foreign intelligence collection today.
  • Financial transactions and positions, where interbank, payment, and data-center links carry information with long regulatory retention requirements and real market value if exposed even years later.
  • Patient records and genomic data, which don't expire: a health record intercepted today is exactly as sensitive in 2040 as it is now, and in some cases more so.
  • Intellectual property and trade secrets, where the whole value of the data is that it stays unknown to competitors for as long as possible.
  • Operational technology and industrial control telemetry, running on infrastructure with decades-long lifecycles and, frequently, network protocols that were never designed to be re-keyed at all.

If your organization touches any of these categories, the question isn't whether harvest-now-decrypt-later applies to you. It's which of your network links are carrying that data right now, unprotected against it.

Why the exposure sits specifically in the network

Harvest-now-decrypt-later is fundamentally an interception attack where interception happens on the wire instead of the application generating the data, or the storage system holding it afterward.

Encrypting a database at rest, or hardening the application that produces a report, does nothing to stop an adversary who is copying that same data as it travels between a data center, a site, or a cloud region.

That's also why the fix doesn't wait for every application, every legacy system, and every piece of operational technology to individually adopt post-quantum cryptography. This is a process that, for hardcoded or vendor-locked systems, may never fully happen.

Quantum-safe encryption applied at the network layer has one big advantage: it protects traffic in transit deep in the network level and every layer above regardless of what generated it. This closing the harvest-now-decrypt-later window for everything crossing that link on day one of deployment, without touching the systems on either end.

Closing the window

Every day a high-value network link runs without quantum-safe key exchange is another day of traffic added to whatever an adversary is already storing against a future decryption date.

That traffic doesn't become retroactively safe once you eventually upgrade the link, since it's already been copied. The only variable still within your control is how much more gets added to that pile before you act.

Closing the window doesn't require solving post-quantum cryptography everywhere at once. It requires putting hybrid key exchange [a classical algorithm running alongside a NIST-standardized post-quantum one, such as ML-KEM (FIPS 203)] on the specific links carrying your longest-lived, highest-value data.

It also requires starting now, at whatever throughput those links actually run. A software-based, crypto-agile approach means today's algorithm choice isn't a permanent bet either. As standards mature, the same infrastructure adopts them without a hardware refresh.

Where to start

  1. Inventory what has a long confidentiality lifetime — the data categories above, specific to your organization.
  2. Map which network links carry it — data center interconnects, site-to-site backbones, cloud and partner connections.
  3. Estimate each link's exposure window using the data-lifetime-versus-decryption-timeline comparison above, and rank links accordingly.
  4. Deploy quantum-safe (hybrid) encryption on the highest-ranked links first — the ones where the exposure window is already open.
  5. Extend coverage on a timeline you control, rather than waiting for a single, organization-wide cutover date.

Get a headstart with network encryption

SSH's NQX applies quantum-safe, wire-speed encryption (up to 100 Gbps) at Layer 2 and Layer 3 to exactly the links this page describes. It is deployed transparently, without touching the systems generating the traffic.

Start by exploring NQX quantum-safe network encryption, read the fuller picture in Quantum-safe network encryption explained, or go deeper on the underlying regulatory pressure in Quantum-safe security: why the clock is already running.