Skip to content
All guides
Training & education

Harvest now, decrypt later: the threat that makes PQC urgent today

8 min
TL;DR

Read this first

Harvest-now-decrypt-later (HNDL) means an adversary records your encrypted traffic today and stores it until a quantum computer can break the key exchange that protected it. The decryption is in the future; the exposure is now. Any secret whose value outlives the time-to-quantum is already at risk. The fix is not to wait for Q-day — it is to migrate key exchange to a post-quantum standard before then.

The headline worry about quantum computing is that Shor's algorithm breaks RSA and elliptic-curve cryptography — the asymmetric algorithms behind almost every TLS handshake, VPN tunnel, and signed software update. The intuitive response is: no such machine exists yet, so there is time. Harvest-now-decrypt-later is the argument for why that intuition is wrong.

The threat model

An adversary who can observe your network — a nation-state at an internet exchange, a cloud tenant on a shared fabric, anyone with a tap — does not need to break your encryption in real time. They record the ciphertext and the key-establishment messages and archive them. Storage is cheap; patience is free. When a cryptographically-relevant quantum computer arrives, they replay the archive and recover the session keys retroactively. Everything you sent under those keys is then readable.

This works specifically against the asymmetric key exchange, not the symmetric bulk cipher. AES-256 is not meaningfully threatened by quantum computers; the problem is that the AES session key was itself established using RSA or (EC)DH, which Shor's algorithm breaks. Recover the key exchange and you recover the session key and thus the plaintext.

The maths of the exposure window

Whether a given secret is at risk is a simple inequality, usually attributed to Michele Mosca. Let X be how many years your data must stay confidential, Y the years it takes you to migrate to post-quantum cryptography, and Z the years until a quantum computer can break today's algorithms. If X + Y > Z, you have a problem: your data is still sensitive at the moment it becomes decryptable.

  • **X — shelf life.** Health records, state secrets, biometric identifiers, and long-term contracts stay sensitive for decades. Session cookies do not.
  • **Y — migration time.** For a real organization this is years, not weeks: you have to find every use of vulnerable crypto, plan the change, and roll it out without breaking production.
  • **Z — time to quantum.** Nobody knows Z precisely, which is exactly the point — you must plan against a range, and the policy deadlines (CNSA 2.0's 2033, the US federal timeline) encode the conservative end of that range.
Pitfall

"We'll migrate when quantum computers are real" is already too late

By the time Z is known, the harvesting has been happening for years and Y still has not started. The whole force of the HNDL argument is that the decision to migrate must be made while Z is still uncertain — because the data being recorded today is decrypted on the adversary's schedule, not yours.

What this means in practice

HNDL reorders the migration priority list. Signatures — code signing, document signing, certificates — are not exposed to harvesting in the same way, because a forged signature is only useful after the quantum computer exists; you cannot forge retroactively. Key exchange is different: the damage is being set up right now. That is why the first concrete step almost everyone takes is moving TLS to hybrid key exchange, which wraps a post-quantum KEM (ML-KEM) around the classical exchange so recorded traffic is protected even though the endpoints are unchanged elsewhere.

How quantakrypto helps

The hard part of HNDL is not understanding it — it is knowing which of your systems are exposed and in what order to fix them. We build the cryptographic inventory that tells you where vulnerable key exchange actually lives, translate it into a migration roadmap sequenced by data shelf life, and train your teams (education) so the reasoning above becomes part of how they design systems. Start with the inventory: you cannot protect what you have not found.

Frequently asked questions

Is harvest-now-decrypt-later a real, current threat or a hypothetical one?

The harvesting is current and cheap — recording and storing encrypted traffic requires no quantum computer at all. Only the decryption step waits on future hardware. So for any data that must stay confidential for years, the risk is present-tense today even though the break is in the future.

Does harvest-now-decrypt-later threaten AES and symmetric encryption?

Not directly. AES-256 remains secure against known quantum attacks. The exposure is the asymmetric key exchange (RSA, ECDH) used to establish the AES session key — break that retroactively and the recorded AES-encrypted data falls with it. That is why migrating key exchange comes first.

How do I know which of my data is actually at risk?

Apply Mosca's inequality per data class: if its required confidentiality lifetime plus your migration time exceeds the time-to-quantum, it is at risk. In practice this means starting with a cryptographic inventory that maps where long-lived secrets are protected by quantum-vulnerable key exchange.

What is the single most effective first step against HNDL?

Move externally-facing TLS to hybrid post-quantum key exchange (X25519MLKEM768). It protects recorded handshakes against future decryption while remaining interoperable with classical clients, and it can be deployed ahead of a full migration.

Take the next step

Related reading

References

Get started

Turn quantum risk into a credential.

Book a discovery call and get an indicative scope and pricing for your organisation.