What is harvest now, decrypt later?

Recording encrypted traffic now to decrypt it later, once a quantum computer can break the key exchange that protected it.

Harvest now, decrypt later — sometimes "store now, decrypt later" — is simple to state and easy to underestimate.

An attacker captures encrypted traffic today. They cannot read it. They keep it. Years later, when a cryptographically relevant quantum computer exists, they use it to break the key exchange that protected the session, and read everything they recorded.

Why the timing is the whole point

The usual reaction is that quantum computers do not exist yet, so this is a problem for later.

That is true of most quantum risks. It is not true of this one, because the capture happens now. The attacker does not need the quantum computer at the moment of interception; they need it at the moment of decryption, which is whenever they like.

So the question is not "when will quantum computers arrive?" but:

How long does the data I am transmitting today need to stay secret?

If the answer exceeds the time until capable quantum hardware, the data is already exposed. Nothing done in 2032 protects a session captured in 2026.

Who has long-lived secrets

For a service where the data is stale within a week, this genuinely is a smaller problem. Being honest about that distinction is more useful than treating every system as equally urgent.

What is and is not exposed

Key exchange is exposed. If the session key was established with X25519, RSA, or any classical mechanism, recovering it later opens the recording.

Certificate signatures are not, in the same way. Forging a signature requires the quantum computer while the certificate is still valid. A signature on a session that already happened cannot be forged retroactively.

Symmetric encryption largely holds. AES-256 remains adequate; Grover's algorithm weakens symmetric cryptography, but not catastrophically.

This is why an assessment that treats every quantum-vulnerable finding as equally urgent is unhelpful. The key exchange is the thing.

The worst case

A host with no forward secrecy — static RSA key exchange — is the severe version. There, one recovered private key decrypts every session ever recorded under it, rather than one session at a time.

What fixes it

Hybrid post-quantum key exchange, in practice X25519MLKEM768. It requires TLS 1.3, and it derives the session key from both a classical and a post-quantum exchange, so a recording cannot be opened by breaking only one.

A session that negotiated a hybrid group today is not in the harvest.

Related

AlgorithmX25519The most widely deployed classical key exchange on the web, and why it leaves TLS sessions exposed to harvest-now-decrypt-later.AlgorithmX25519MLKEM768The hybrid post-quantum key exchange used by default in Chrome, Firefox, Cloudflare and OpenSSL 3.5. What it is and how to tell if you have it.GuideInventory your cryptographyA practical order of operations for discovering what cryptography an organisation actually uses, starting with internet-facing services.TermForward secrecyWhy a stolen server key should not decrypt past sessions, and why static RSA key exchange is the worst case for harvest-now-decrypt-later.AlgorithmRSA-2048Still the most common certificate key size on the web. What NIST's transition timeline means for RSA-2048, and why key exchange matters more than signatures.IndustryFinancial servicesWhy banks and insurers face harvest-now-decrypt-later sooner than most sectors, and what an external cryptographic inventory finds first.IndustryGovernment & defenceCNSA 2.0 deadlines, classification periods measured in decades, and why the browser-default post-quantum group is not sufficient for national security systems.

Last reviewed 2026-07-21.