Harvest now, decrypt later: the quantum risk that exists today

The threat in one sentence

An adversary who cannot break your encryption today can still copy it today, keep it, and break it later. This is called harvest now, decrypt later (HNDL), sometimes "store now, decrypt later". It turns the quantum threat from a future problem into a present one for any data that needs to stay confidential for a long time.

Why key exchange is the weak point

When you connect to a site over TLS, your browser and the server use an asymmetric key exchange (today usually ECDHE) to agree a session key, then encrypt the data with a symmetric cipher such as AES. If an attacker records the whole session, including the handshake, and later gains a quantum computer able to run Shor's algorithm, they can recover the session key from the handshake and decrypt everything. The AES part is not the problem; the key exchange is.

Perfect forward secrecy, where each session uses fresh keys, still matters, because a stolen long-term server key will not unlock old sessions. But forward secrecy based on classical Diffie-Hellman does not protect against a quantum attacker who targets each recorded handshake.

Capturing traffic at scale is realistic for well-resourced actors, such as those with access to internet backbone links, undersea cables or compromised network equipment. The data that is worth storing for years is the data that will still be valuable when it is finally decrypted.

Which data is at risk

Michele Mosca's simple inequality helps you decide. If the number of years your data must stay secret (X) plus the years you need to migrate your systems (Y) is greater than the years until a cryptographically relevant quantum computer exists (Z), you have a problem today. Nobody knows Z precisely, which is why agencies urge organisations not to wait.

What to do now

1. Identify data flows that carry long-lived sensitive data: VPN links between sites, backups sent over networks, partner connections and remote access.
2. Enable hybrid post-quantum key exchange where your software already supports it, such as TLS 1.3 groups like X25519MLKEM768 and hybrid SSH key exchange.
3. Ask VPN, firewall and cloud vendors for their post-quantum roadmap and timelines.
4. Reduce exposure: do not send sensitive data over the network unless needed, and avoid keeping unnecessary archives.
5. Prefer AES-256 for long-term stored data and for symmetric pre-shared keys.
6. Feed the findings into your wider post-quantum migration plan.

Tip: some VPN technologies let you mix a symmetric pre-shared key into the key exchange as an interim quantum-resistant measure. Check whether your platform supports it, but treat it as a stop-gap, not a replacement for standard PQC.

In exams, HNDL is the usual answer to the question "why act before quantum computers exist?" At work, it is the clearest way to explain quantum urgency to managers: the attack's first stage may already be happening.