Harvest now, decrypt later

Harvest now, decrypt later is a patient attack. An adversary records encrypted traffic, or copies an encrypted archive, while the cryptography protecting it still holds. The ciphertext is stored. Years later, when hardware capable of solving the underlying mathematical problem exists, the stored material is decrypted. Only the final step needs a quantum computer. Every step before it needs storage, access and patience.

#The mechanic, in order

It helps to separate the attack into stages, because four of the five are ordinary operations that well-resourced organisations already perform for other reasons. There is nothing exotic about the first four.

1. 1

   Access

   Passive visibility into a network path, a peering point, a submarine cable landing, a cloud egress route, a backup target or a decommissioned storage array. Passive access is enough. The adversary never needs to modify a packet.

2. 2

   Capture

   Record the session as it is: the handshake, the negotiated parameters, the certificate chain and the ciphertext. The handshake matters as much as the payload, because it is where the key agreement happens.

3. 3

   Store

   Write it to cold storage with an index. Selection is usually coarse at this stage — by source, destination, protocol or peer organisation rather than by content, because content is not yet readable.

4. 4

   Wait

   Do nothing for as long as it takes. The stored ciphertext does not decay. Neither does the value of the plaintext inside it, if that plaintext was long-lived to begin with.

5. 5

   Decrypt

   Recover the session key by breaking the asymmetric key agreement that established it, then decrypt the recorded payload with the recovered symmetric key. This is the only stage that depends on capability that does not exist in public today.

#Why it is a rational strategy for the people who would run it

The strategy makes economic sense before it makes technical sense, which is why it does not depend on anyone believing a particular hardware timeline.

• The cost is dominated by storage, and storage keeps getting cheaper. Retaining selected traffic for a decade is a small line item against a national intelligence budget. The decision to collect does not require the decision to decrypt.
• The capture window closes permanently. Once an organisation deploys quantum-resistant key establishment, the sessions it negotiates from that day forward are out of reach. An adversary who waits for certainty about hardware collects nothing from the intervening years.
• The payoff is asymmetric. Most captured material will turn out to be worthless. A single recovered archive of diplomatic cable traffic or clinical records can justify the entire programme.
• Passive collection carries almost no attribution risk. There is no intrusion to detect, no malware to find, no lateral movement in your logs. The target's telemetry looks normal because, from the target's side, nothing happened.
• It needs no new tradecraft. Organisations that already run bulk collection are not being asked to build a new capability. They are being asked to change a retention setting.

On who plausibly does this: state signals-intelligence services are the obvious candidates, because they already hold the access, the storage and the mandate, and because their planning horizons are measured in decades. Organised criminal groups are a weaker fit, since their economics reward conversion within months rather than years. Insider access to backup systems and long-lived encrypted archives sits somewhere between the two, and is the variant most enterprises can actually do something about.

#Which data is genuinely at risk

There is one test, and it is a timing test rather than a sensitivity test. Does the confidentiality of this data need to survive past the point at which capable hardware plausibly exists? If yes, it belongs in scope. If no, it does not, however sensitive it feels today.

Biometric templates and signing keys deserve separate attention because both defeat the usual remedy. For most breaches the answer is rotation: change the password, reissue the card, revoke the token. Neither a fingerprint nor an already-signed artefact can be rotated after the fact.

#Why short-lived data is a much lower priority

A large share of the encrypted traffic an enterprise emits protects material that will be worthless long before any decryption becomes possible. Treating that traffic with the same urgency as a clinical archive wastes the migration budget you need elsewhere.

• Session cookies and bearer tokens with lifetimes measured in minutes or hours.
• One-time passcodes, challenge values and nonces.
• Market data, price quotes and telemetry samples whose value is intraday.
• Cache fills, health checks and internal service discovery chatter.
• Build artefacts already superseded by a later release, provided the signing key is handled separately.

This is also where traffic analysis matters. Even where the payload is genuinely ephemeral, the pattern of connections between two organisations can itself be the sensitive fact, and no cryptographic upgrade in the key exchange changes that. We score the cryptography. We do not claim to solve metadata exposure.

#What nobody can honestly claim

No one can prove to you that a specific interception has occurred. Passive collection leaves no trace on the target side. There is no log entry, no alert and no forensic artefact to find, which means there is also no evidence to present. Any vendor telling you your traffic has definitely been harvested is asserting something they cannot know.

So the argument for acting is not evidential. It is about the shape of the error you can afford to make.

You migrate, and no capture occurred

You modernised cryptography that standards bodies were deprecating anyway, on your own schedule, with your own change windows. The cost is the migration budget.

You migrate, and capture did occur

Everything recorded before the cutover remains exposed. Everything after it is not. You have bounded the loss.

You do not migrate, and no capture occurred

You saved the budget and were fortunate. You still face the same deprecation deadlines later, under more schedule pressure.

You do not migrate, and capture did occur

The exposure is unbounded and retrospective, and no control you deploy afterwards can retract the ciphertext already in someone else’s storage.

That asymmetry is the whole case, and it is enough. It does not need a countdown clock or an invented breach statistic on top of it. We set out what we refuse to assert, and why, in Claims we refuse to make.

#Turning the argument into a work plan

The practical version of this threat model is unglamorous inventory work. You cannot prioritise long-lived confidentiality if you do not know which systems carry it, and most estates do not know. In our pilot estate AutoPQC discovered 42 cryptographic assets, classified 36 of them vulnerable, and produced an aggregate risk score of 75 / 100. The same review took 22 hours by hand against 14 minutes on the platform.

1. 01Inventory the asymmetric cryptography in the estate, including the instances nobody documented. See How discovery finds cryptography.
2. 02Tag each protected data flow with the secrecy horizon its regulator, contract or clinical duty actually requires.
3. 03Run the timing arithmetic before ranking anything, using The migration window, with the arithmetic.
4. 04Sequence hybrid key establishment for the long-horizon flows first, keeping a rollback path. See Hybrid modes and keeping your rollback.
5. 05Record what you changed and when, so a future auditor can see the date your capture window closed.