Harvest Now, Decrypt Later: Which Data Is Actually at Risk

The oldest attack in signals intelligence

In early 1943, the US Army’s Signal Intelligence Service began archiving Soviet diplomatic cables it had no way to read. The first partial break came in 1946. The program, later declassified under the name Venona, kept working that same intercepted traffic until 1980, recovering messages as much as 37 years after they were sent.

That is harvest now, decrypt later (HNDL), and it predates quantum computing by eight decades. The mechanic has not changed: capture ciphertext today, store it cheaply, break it when the tools catch up. What quantum computing changes is the size of the class of traffic that becomes readable, and how quickly. Shor’s algorithm, running on a cryptographically relevant quantum computer (a CRQC, meaning a machine large and stable enough to factor numbers the size of RSA keys), does not chip away at RSA and elliptic-curve cryptography. It removes them.

Most writing about HNDL stops at that explanation, and the explanation is the easy part. The harder question, and the one a security lead actually has to answer, is narrower. Which of our data is genuinely exposed to this, and in what order do we fix it? Answered badly, the answer is “everything,” which produces a program nobody funds. Answered well, it produces a shortlist.

We teach this triage before we teach algorithms, because the algorithm choice is downstream of it.

The three numbers

The cleanest way into the problem is a piece of arithmetic that Michele Mosca of the University of Waterloo published in 2015. Three variables, one comparison.

X is your data’s shelf life. How many years must this information stay confidential before disclosure stops causing harm? The question is how long the information can hurt you, not how long you keep it.

Y is your migration time. How many years will it take to replace the vulnerable cryptography in the systems that carry this data, end to end, including the vendors and partners you do not control.

Z is the time until a CRQC exists. Nobody knows this number. Treat it as a range rather than a date.

If X plus Y is greater than Z, the data is already exposed rather than due to be exposed, because the harvesting happens now and only the decryption waits.

Two things about this arithmetic deserve attention. The first is that Y is the variable organizations get most wrong, and they get it wrong in the optimistic direction. The US federal government set 2035 as its migration target in OMB Memorandum M-23-02, issued in November 2022 pursuant to National Security Memorandum 10, and NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) guidance runs its dates out to 2033 for national security systems. Those are timelines for a coordinated national program with legislative backing. A mid-sized enterprise with a decade of accumulated TLS terminations, embedded devices, and third-party integrations should not assume it moves faster than that.

The second is that Z is the number the market is worst at estimating, and estimates tend to track the funding cycle of whoever is publishing them. Craig Gidney and Martin Ekerå estimated in 2019 that factoring RSA-2048 would need 20 million noisy qubits, and Gidney’s 2025 revision put the same job under one million. That is a twentyfold move in six years, from one research group, on one algorithm, and it is the argument for planning against a range: an organization whose plan only works if Z lands in one particular decade does not have a plan.

Tiering by shelf life

Run X across your data and three groups fall out.

Decades. Genetic and clinical records, which describe a person for a lifetime and their relatives for longer. Biometric templates, which cannot be reissued. National security material, where a 25-year default declassification period is the floor rather than the expectation. Nuclear and defense engineering designs. Long-lived contractual and legal instruments. Source identities and human intelligence. Anything that reveals a person’s association with something they concealed.

For this group, X alone usually exceeds any plausible Z. The arithmetic does not need Y to come out badly.

Years. Pre-patent research, where the useful secrecy window is the time to filing plus the enforcement period. Pharmaceutical trial data. M&A material before announcement. Litigation strategy. Source code for products with long field lifetimes. Pricing models and cost structures for multi-year contracts. Customer lists in industries with slow churn.

This group is where the triage actually happens, because the answer genuinely varies. A drug candidate’s trial data is a decade-class secret. Next quarter’s pricing is not.

Months or less. Session tokens. Rotating credentials. Transaction authorization codes with same-day validity. Operational telemetry. Anything that is regenerated on a schedule shorter than the gap to any credible Z.

An adversary running a storage budget applies the same filter you do. Ciphertext that will be worthless when it becomes readable is not worth the disk. Well-resourced state collectors take everything, but even they prioritize what they process first, and the processing is where the cost sits.

The exposure axis, which matters more than the tiering

Shelf life alone over-scopes the problem badly. A decade-class secret that has never crossed a network you do not control, encrypted at rest with AES-256, is not the thing to fix first.

Here the source material most people are working from tends to mislead, so it is worth being precise. Grover’s algorithm gives a quadratic speedup against symmetric ciphers, not an exponential one. AES-256 retains roughly 128 bits of effective security against it, and Grover parallelizes poorly enough that the practical position is better than that. The HNDL emergency sits in key establishment rather than in symmetric encryption at rest with 256-bit keys.

When two systems negotiate a TLS session, they agree on a symmetric key using RSA or elliptic-curve Diffie-Hellman. An adversary who records the full handshake and the encrypted session can, given a CRQC, recover the ephemeral key from the handshake and then decrypt everything that followed. Forward secrecy, which discards session keys after use so that a later server compromise cannot decrypt past traffic, does not help here. The whole point of forward secrecy is that the ephemeral keys are never stored, and the whole point of Shor’s algorithm is that they do not need to be stored. They can be recomputed from the handshake.

So the second axis is capture exposure, and it produces a much shorter list:

• Traffic that crosses infrastructure you do not control. Internet paths, leased circuits, satellite links, subsea cable.
• Sessions terminating at third parties. Cloud, SaaS, managed services, partner VPNs. Every one of these is a place your plaintext exists on someone else’s decision-making timeline.
• Long-lived tunnels. Site-to-site IPsec and industrial links that renegotiate rarely and carry years of traffic under a small number of key exchanges.
• Backups and replication shipped offsite, particularly where the transport encryption is older than the retention period.
• Data already taken. If you had a breach in 2019 and the attacker exfiltrated encrypted archives, that data has been harvested. No future control changes its status. It belongs on the register as a known exposure with an unknown clock.

Cross the two axes and the priority list writes itself. Decade-class data moving over uncontrolled paths, or terminating at third parties, or already gone. That is usually a handful of systems, not a hundred.

One caution on the exposure axis: interception at scale is not hypothetical. Internet routing has been misdirected through unexpected jurisdictions repeatedly over the past decade, including the April 2020 Rostelecom route leak, which briefly announced routes for traffic destined to Google, Amazon, Facebook, and Cloudflare and pulled it through Russian networks. Public evidence does not establish intent in these cases, and we do not claim it does. What they establish is capability, and capability is what the risk assessment runs on.

What triage buys you

The output of this exercise is a cryptographic inventory that is ranked, not just complete. Plenty of organizations now have a list of every place they use cryptography. Far fewer have that list ordered by when each entry stops being defensible.

Ranking changes what you do next in three ways.

It tells you where hybrid key exchange goes first. NIST finalized ML-KEM (Module-Lattice Key Encapsulation Mechanism, published as FIPS 203) in August 2024, and hybrid modes that run ML-KEM alongside a classical exchange have already shipped in major browsers and content delivery networks. Hybrid means both algorithms must fail for the session to fail, which is the right posture while the new algorithms are still young. If your triage says your decade-class traffic runs over three specific external integrations, those three get hybrid key exchange this year, and the internal file server does not.

It tells you where crypto-agility is worth the engineering cost. Crypto-agility means being able to change the algorithm without changing the application: negotiated rather than hardcoded, centralized rather than scattered, versioned rather than assumed. Retrofitting it everywhere is expensive. Retrofitting it into the systems your triage flagged is a project.

And it gives you a defensible answer to the board. “We have twelve systems above the line, here is what X and Y are for each, here is the sequence” is a fundable position. “Quantum computers will break encryption” is not.

The half of the problem that is not about secrecy

HNDL is a confidentiality failure with a delay on it. There is a second failure mode with the opposite timing, and organizations that only migrate key exchange will walk straight into it.

Trust now, forge later (TNFL) is the signature-side analogue. A CRQC that can derive a private key from a public key can produce signatures indistinguishable from yours. That is impersonation rather than disclosure, and it reaches software updates, firmware images, certificates, documents, device attestations, and transaction authorizations.

Three differences from HNDL matter for triage.

TNFL requires no theft. The adversary needs your public key, which you publish by design. There is no exfiltration event to detect and no earlier breach to remediate.

TNFL is immediate rather than gradual. Decrypting a harvested archive is a per-item cost. Deriving one signing key compromises every place that key is trusted, all at once.

And TNFL’s worst exposure is in the things you cannot easily update. Embedded and industrial controllers, satellites, e-passports, medical devices in the field, root certificates burned into hardware. A trust anchor with a fifteen-year deployment life and no update path is a decision you already made, years ago, about your position in 2040.

NIST finalized ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) alongside ML-KEM, and FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm) is announced as a further signature standard. The migration order for signatures is driven by rotation difficulty rather than data shelf life, which makes it a separate triage from the one above. Run both.

A short version

If you want a first pass this quarter rather than this year:

1. List the data classes where X, the shelf life, exceeds ten years. Be strict. Most organizations find fewer than a dozen.
2. For each, trace where it crosses infrastructure or organizations you do not control. That trace, not the data list, is your exposure register.
3. Add every historical breach where encrypted data left the building. Mark those as harvested and move on; there is no remediation, only disclosure planning.
4. Separately, list every signing key you cannot rotate inside twelve months. That is your TNFL register.
5. Estimate Y honestly for the top three items on each register, including vendor dependencies. If Y surprises you, that is the finding.

None of this requires a decision about post-quantum algorithms. It requires knowing which decisions are urgent, which is a different and more useful thing to know.

Where to take this next

The triage above is the opening move in a longer migration, and it is the part that determines whether the rest of the program is proportionate or performative. Getting the arithmetic right, and getting it right in front of a board, takes a working grasp of what Shor’s and Grover’s algorithms do and do not threaten, how the NIST standards map onto real protocol stacks, and how to build an inventory that is ranked rather than merely long.

The Post-Quantum Foundation program at Quantum Academy covers that ground for security and risk professionals, including the shelf-life and exposure analysis in this article. For migration methodology once the triage is done, pqcframework.org carries the framework material, and PostQuantum.com goes deeper on the underlying cryptography.

Venona took 37 years to finish reading 1943. The organizations that come out of this decade well will be the ones that decided, early and specifically, which of their 2026 traffic they were willing to have read in 2050.