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.
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.
The attack has three stages, and only the last one needs a quantum computer:
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.
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:
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.
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.
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:
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.
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.
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.
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.