Harvest Now, Decrypt Later: The Quantum Deadline That Already Started

Most discussion of quantum computing and cryptography argues about dates. Will a cryptographically relevant quantum computer arrive in 2032, 2035, or never? It is an interesting argument, and for a large class of organisations it is also the wrong one.

The reason is a strategy usually called harvest now, decrypt later. An adversary does not need a quantum computer today. They need only to capture encrypted traffic today and keep it. The decryption happens whenever the capability arrives. For any data that must stay confidential for a decade or more, the deadline is not the arrival of the machine. The deadline is now.

What harvesting actually looks like

Bulk capture of encrypted traffic is neither exotic nor expensive. Storage is cheap, and an adversary with access to a network tap, a compromised intermediary, or a cooperative transit provider can archive TLS sessions indefinitely without breaking anything. Nothing about that traffic looks unusual at the time. There is no alarm, no incident, and nothing to detect after the fact.

The encrypted payload is only half of what is worth keeping. The key exchange is the real prize. Today’s TLS sessions overwhelmingly establish keys using elliptic-curve Diffie-Hellman or RSA. Both rest on mathematical problems that Shor’s algorithm solves efficiently on a sufficiently large quantum computer. Recover the session key later and the entire captured conversation opens.

This is the asymmetry that makes the strategy attractive. Capture is cheap and passive. Decryption is expensive and deferred. An adversary can afford to be patient with data that stays valuable.

The arithmetic that tells you whether to care

Michele Mosca framed this as a simple inequality. Let x be the number of years your data must remain confidential. Let y be the number of years it will take your organisation to migrate to quantum-resistant cryptography. Let z be the number of years until a cryptographically relevant quantum computer exists.

If x + y > z, you have a problem, and you have it today.

What makes this useful is that two of the three variables are yours. You may not know z, and reasonable people disagree about it by a decade. But you can estimate how long your data stays sensitive, and you can measure — usually to your discomfort — how long a cryptographic migration actually takes in your environment. Most organisations discover that y alone is five to seven years once you account for embedded systems, vendor dependencies, and hardware refresh cycles.

Run the numbers honestly and the argument about z often stops mattering.

Who actually has this problem

Not everyone does. If your data is worthless in eighteen months, harvesting is not your threat model, and you should spend your attention elsewhere. The organisations that genuinely need to act are the ones holding data with a long confidentiality half-life:

• Health records. A diagnosis disclosed in 2040 is as damaging as one disclosed today.
• Legal and financial archives. Contracts, settlements, and due-diligence material stay sensitive for decades.
• Government and defence communications. The classic case, and the reason national agencies moved first.
• Journalism and source protection. A source’s identity does not stop being dangerous because time passed. This one is rarely on the list and probably should be near the top.
• Identity and biometric data. You can rotate a password. You cannot reissue a fingerprint or a face.

I spent several years responsible for the digital infrastructure of a national broadcaster, and the category that surprised me was the archive. Newsrooms accumulate unaired footage, contributor details, and internal correspondence that nobody classifies as sensitive because nobody ever revisits it. It is exactly the sort of material that stays quietly damaging for twenty years.

What to do about it that is not panic

The instinct is to wait until the standards settle and the vendors ship. The standards have settled — NIST finalised its first three post-quantum standards in August 2024 — and the useful work does not depend on vendors anyway.

1. Build a cryptographic inventory

You cannot migrate what you cannot find. Most organisations do not know where RSA and ECC are used across their estate, and the answer is invariably worse than expected: hardcoded in firmware, buried in a vendor appliance, baked into a certificate pinning implementation nobody has touched in six years. This step is unglamorous, takes months, and is the only one that is genuinely mandatory.

2. Classify data by confidentiality lifetime, not by sensitivity

Standard classification schemes ask how damaging a disclosure would be. For this threat you need a different question: how long does this need to stay secret? A moderately sensitive record with a thirty-year lifetime is a bigger harvesting risk than a highly sensitive one that expires next quarter.

3. Move to hybrid key exchange where you can

Hybrid schemes combine a classical algorithm with a post-quantum one so that the session is secure unless both are broken. This is the single highest-value change available right now, because it directly defeats harvesting: traffic captured today cannot be opened later by breaking ECC alone. Major browsers and several CDNs already support hybrid key exchange, which means for a lot of web traffic this is a configuration change rather than a project.

4. Design for crypto-agility, not for a specific algorithm

The systems that will survive this transition comfortably are the ones that can change cryptographic primitives without a rewrite. That is an architectural property, and it is worth more than picking the right algorithm today — because whatever you pick, you will change it again.

The part that is genuinely uncomfortable

Everything above protects data going forward. None of it helps with traffic that has already been captured. If an adversary archived your key exchanges in 2019, that material is already outside your control, and no migration undoes it.

That is worth stating plainly because it changes how you should think about the timeline. This is not a risk you can address on a comfortable schedule and then declare closed. Every month of delay adds permanently to a set of data you can never protect again. The migration is slow and the window is not.

The honest summary is that harvest now, decrypt later converts an uncertain future capability into a present-tense obligation. You do not need to believe any particular forecast about quantum hardware to act on it. You only need to believe that some of your data will still matter in 2040.