Harvest Now, Decrypt Later

What "harvest now, decrypt later" means

Harvest now, decrypt later — often abbreviated HNDL, and sometimes called "store now, decrypt later" or a retrospective decryption attack — is a strategy in which an adversary intercepts and records encrypted data today, even though they cannot read it, and stores it in the expectation of decrypting it in the future. The bet is simple and specific: that a machine capable of breaking today's public-key cryptography will exist within the useful lifetime of the captured data.

What makes this threat different from almost everything else in a security program is that it decouples the moment of compromise from the moment of loss. In a conventional breach, the data is exposed when the attacker gets in. In HNDL, the data is exposed at capture, but the loss only becomes visible years later, when the encryption that was protecting it is finally broken. By then the traffic has long since scrolled off your logs, the session is closed, the employee who sent it has changed roles, and there is no alert to fire — because from the perspective of your defenses, nothing happened. A copy was made in transit and quietly carried away.

That is the uncomfortable core of the idea. The attacker does not need a zero-day, a stolen credential, or a cryptographic breakthrough now. They need three ordinary things: the ability to observe encrypted traffic or exfiltrate encrypted data at rest, somewhere cheap to keep it, and patience. All three are abundant. The cost of storing a petabyte of ciphertext falls every year, while the value of what that ciphertext protects — a patient's genome, a decade of financial positions, a diplomatic cable, a signing key — does not.

It is worth being precise about what is and is not being claimed. HNDL is not a prediction that all encryption is about to fail overnight. Symmetric encryption of the kind that protects a hard drive is expected to remain strong. The specific, well-understood vulnerability is in public-key cryptography — the algorithms that let two parties who have never met agree on a shared secret over an open network, and that let a signature prove who sent a message. Those algorithms underpin nearly every secure connection on the internet, and they are precisely the ones a sufficiently large quantum computer is expected to break. We unpack exactly which algorithms, and why, in the section on Shor's and Grover's algorithms below.

Why this threat is real now, not later

A reasonable objection is that a working quantum computer capable of breaking RSA does not yet exist in public knowledge, so why treat this as a present-tense problem rather than a future one? The answer is that the attack is a two-phase operation, and only the second phase depends on the quantum computer. The first phase — harvesting — is available today, requires no advanced technology, and is almost certainly already underway.

Consider who can perform bulk collection of encrypted traffic. Nation-state intelligence services operate at the level of internet backbones, submarine cables, and internet exchange points. They have both the access and the strategic incentive to record encrypted flows that they cannot currently read, because their planning horizon is measured in decades, not quarters. Public reporting over the past decade has documented programs oriented toward large-scale traffic collection and long-term storage. An adversary with that reach does not need to guess which of your sessions will matter; they can capture broadly and triage later.

The economics reinforce the strategy. Encrypted data compresses poorly, but storage is cheap and getting cheaper, so keeping years of captured ciphertext is entirely tractable for a well-resourced actor. There is no downside to collecting: if the quantum computer never materializes, the attacker has spent a small amount on disks; if it does, they hold a trove of decades-old secrets that were considered safe by everyone who created them. This is a rational, low-risk bet, which is exactly why defenders should assume it is being placed.

Two developments have moved HNDL from a theoretical concern discussed in cryptography circles to an operational priority discussed in boardrooms. First, in 2024 the U.S. National Institute of Standards and Technology (NIST) finalized the first standardized post-quantum algorithms, which means defenders now have concrete, vetted tools to deploy rather than research proposals. Second, governments began setting migration deadlines: U.S. federal guidance directs agencies to inventory their cryptography and plan a transition, with a broad national objective of migrating away from quantum-vulnerable cryptography through the 2030s. When the party with the best visibility into nation-state capability tells its own agencies to start moving, that is a signal worth reading.

The practical conclusion is that the deadline for defending a given piece of data is not the day quantum computers arrive. It is the day that data was first transmitted or stored under vulnerable cryptography, because that is the moment it could have been harvested. Everything sensitive that has already crossed a network in the clear-to-quantum sense may already be sitting in an archive waiting for its key. What you can still control is everything from today forward.

How harvesting works in practice

To defend against HNDL it helps to be concrete about how the harvesting half of the attack actually operates, because the mechanics determine which of your assets are reachable and which are not.

Collection in transit

The largest and most durable source of harvestable data is traffic on the wire. When a browser, an application, or an API client establishes a TLS connection, the two endpoints perform a key exchange to agree on a symmetric session key, and that key exchange is protected by public-key cryptography — historically RSA, and today most often an elliptic-curve Diffie-Hellman exchange such as X25519. An adversary who records the full session captures both the key-exchange handshake and the encrypted payload that follows.

Here is the crucial point: modern TLS uses ephemeral keys to provide forward secrecy, which is excellent protection against a future compromise of the server's long-term private key. But forward secrecy assumes the underlying key-exchange math is hard. If a quantum computer can solve the elliptic-curve discrete logarithm that the ephemeral handshake relied on, the attacker can reconstruct the session key directly from the recorded handshake and decrypt the captured payload. Forward secrecy protects against key theft; it does not protect against the key-agreement algorithm itself being broken. Recorded TLS sessions are therefore the canonical HNDL target.

Collection at rest and in backups

Data that is exfiltrated in encrypted form — a stolen backup, an encrypted database snapshot, a copied disk image, an intercepted encrypted email — is harvestable in the same way if the mechanism protecting the encryption keys is quantum-vulnerable. Bulk data is usually encrypted with a symmetric algorithm like AES, which is quantum-resistant when the key is long enough, but the AES key itself is frequently wrapped or exchanged using public-key cryptography. If that key-wrapping step uses RSA or ECC, then breaking the wrapper exposes the symmetric key, which exposes the data. The strength of the symmetric layer is only as good as the key management above it.

What the attacker keeps, and why

A sophisticated harvesting operation does not just grab payloads; it retains the associated key-exchange material, certificates, and metadata needed to make the future decryption efficient. Metadata alone — who talked to whom, when, and how much — has intelligence value even before decryption, and it also lets the attacker prioritize which archives to attack first once a quantum capability is available. This is why the threat model assumes a patient, well-organized adversary rather than an opportunist: the whole strategy only pays off for someone with the discipline to store, index, and eventually process the harvest.

Notice what this means for defense. You cannot detect harvesting after the fact, and you cannot un-send data that has already crossed a monitored link. The only lever that works is changing the math so that a future quantum computer cannot break the key exchange in the first place. That is a cryptographic change, and it has to be made upstream of the harvesting. We cover how in the migration response, and in depth in our guide to the enterprise encryption stack.

Shor's algorithm versus Grover's algorithm

The entire HNDL threat rests on two quantum algorithms, and confusing them is the most common source of both panic and complacency. They do very different things, and understanding the distinction tells you exactly which parts of your cryptography are in danger and which are merely inconvenienced.

Shor's algorithm: the one that breaks public-key crypto

In 1994 Peter Shor described a quantum algorithm that can factor large integers and compute discrete logarithms in polynomial time. On a classical computer, the presumed difficulty of these problems is what makes public-key cryptography secure: factoring the product of two large primes, or solving the discrete logarithm on an elliptic curve, is believed to require astronomically long time as the key grows. Shor's algorithm collapses that difficulty. A sufficiently large, error-corrected quantum computer running Shor's algorithm would move these problems from effectively-impossible to efficiently-solvable.

That single capability breaks the cryptography the internet is built on:

• RSA — security depends on the hardness of integer factorization. Shor factors, so RSA falls.
• Diffie-Hellman and elliptic-curve Diffie-Hellman (including X25519) — security depends on the discrete logarithm problem. Shor solves it, so these key exchanges fall.
• ECDSA and other elliptic-curve signatures — same discrete-logarithm foundation, so signature forgery becomes possible.

Because these are exactly the algorithms used to establish keys and prove identity in TLS, VPNs, secure email, code signing, and countless proprietary protocols, Shor's algorithm is the reason HNDL is a serious strategy. Everything an adversary harvests that was protected by a Shor-vulnerable key exchange becomes readable once a cryptographically-relevant quantum computer exists.

Grover's algorithm: the one that only weakens symmetric crypto

Grover's algorithm, published in 1996, is a general method for searching an unstructured space, and it offers a quadratic speedup rather than the exponential one Shor achieves. Applied to a symmetric cipher, Grover's algorithm reduces the effort of a brute-force key search from roughly 2ⁿ to roughly 2^n/2 operations. In plain terms, it effectively halves the security level of a symmetric key.

This is a meaningful but manageable effect. A 128-bit key would offer roughly 64 bits of security against a Grover attack, which is uncomfortable; a 256-bit key would offer roughly 128 bits, which remains comfortably beyond reach. This is precisely why the guidance for symmetric cryptography is not "replace it" but "use larger keys." AES-256 is considered quantum-resistant for the foreseeable future, and hash functions like SHA-256 and SHA-384 are similarly addressed by preferring longer outputs. Grover does not break symmetric cryptography; it shifts the recommended key size up by a factor of two, and the industry already had headroom to absorb that shift.

The takeaway for an HNDL defense is therefore focused rather than sweeping. You do not need to rip out AES-256; you need to replace the Shor-vulnerable public-key algorithms that establish and protect your keys. That is a smaller, more tractable target than "all of our encryption," and it is exactly what the post-quantum standards are designed to fill. For a fuller treatment of the algorithms and the standardization process, see our companion guide to post-quantum cryptography.

Which data is most at risk

Not all data is equally exposed to harvest now, decrypt later, and understanding the difference is what turns an overwhelming problem into a prioritized program. The single most important variable is shelf life: how long the data must remain confidential. A one-time password that expires in sixty seconds is worthless to an attacker who decrypts it in ten years. A patient's diagnosis, a trade secret, or a national identity number is just as damaging to disclose in 2036 as it is today. HNDL is a threat to data whose value outlives the cryptography protecting it.

The categories most exposed share that property of long confidentiality horizons:

• Health and genomic records — a person's medical history and especially their genome are sensitive for a lifetime and beyond, and are subject to long statutory retention. Health data is a textbook HNDL target because its value does not decay.
• Financial and insurance data — account histories, transaction records, underwriting models, and long-dated contracts remain sensitive for years or decades, and disclosure carries regulatory as well as competitive consequences.
• Legal and privileged material — attorney-client communications, sealed settlements, M&A due diligence, and litigation strategy retain their sensitivity for the life of the matter and often far longer.
• Government and defense information — classified and controlled data is routinely protected for 25 years or more by policy, which places it squarely inside any plausible quantum timeline. This is the community that has moved earliest and most aggressively on migration for exactly that reason.
• Intellectual property and trade secrets — source code, chip designs, pharmaceutical research, manufacturing processes, and strategic plans can define a company's advantage for a generation. Their theft via retrospective decryption is a slow-motion competitive catastrophe.
• Credentials and long-lived keys — passwords that get reused, and especially private keys and root certificates with long validity periods, are uniquely dangerous. A harvested long-term signing key, once recovered, lets an attacker forge identity and unlock everything that key protected.
• Personal identifiers — national ID numbers, biometrics, and dates of birth cannot be rotated the way a password can. Once disclosed, they are compromised permanently, which makes them ideal long-horizon targets.

By contrast, data with a short sensitivity window is comparatively safe from HNDL specifically: ephemeral session tokens, transient telemetry, already-public information, and anything that will be intentionally disclosed before a quantum computer is plausible. This is not a license to ignore that data's other security needs, only a recognition that it is not the priority for post-quantum migration.

The practical exercise, then, is to overlay two questions on your data inventory: how sensitive is this, and for how long must it stay that way? The intersection of "highly sensitive" and "long shelf life" is your HNDL priority queue. Industries built on exactly that kind of data — which is why our work with security-led organizations so often starts here — should treat post-quantum migration as a near-term obligation rather than a future contingency.

The quantum timeline: uncertain, but directional

Any honest discussion of HNDL has to be candid about the timeline, because the timeline is genuinely uncertain and anyone claiming precision is overselling. What breaks RSA-2048 is not any quantum computer but a cryptographically-relevant quantum computer (CRQC) — one with enough high-quality, error-corrected logical qubits, and a low enough error rate sustained long enough, to run Shor's algorithm against real key sizes. Today's devices, measured in physical qubits with meaningful error rates, are not close to that threshold. The gap between a headline qubit count and a CRQC is enormous, and it is bridged mainly by progress in quantum error correction, not by qubit count alone.

So the responsible framing is probabilistic, not deterministic. Expert elicitation studies — most notably the recurring surveys conducted by the Global Risk Institute — gather structured opinion from quantum researchers and consistently find a wide spread of estimates, with a non-trivial probability that a CRQC capable of breaking RSA-2048 could emerge within roughly a decade to fifteen years, and meaningful tails on both the earlier and later sides. The estimates have, if anything, tightened toward "sooner" in recent surveys as error-correction milestones have been demonstrated, but the honest summary remains: no one knows, and the uncertainty is large.

Governments have resolved this uncertainty into planning dates rather than predictions. U.S. national security guidance set an objective of migrating vulnerable systems throughout the 2030s, and NIST has signaled that widely used quantum-vulnerable algorithms should be deprecated over the coming years and disallowed thereafter. These are policy deadlines designed to guarantee that migration completes before a CRQC plausibly arrives, deliberately built with margin because migrating cryptography across a large organization is slow. That last point — that migration itself takes years — is the hinge of the whole risk calculation, which we turn to next.

NIST's finalized post-quantum standards

The reason HNDL has a defense rather than only a warning is that the replacement algorithms now exist as finalized standards. After a multi-year public competition that began in 2016 and drew submissions and cryptanalysis from researchers worldwide, NIST published its first post-quantum cryptography standards in August 2024. These are not drafts or proposals; they are Federal Information Processing Standards, the same category of document that standardized AES.

Three standards form the core of the enterprise toolkit:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), derived from the CRYSTALS-Kyber submission. This is the workhorse for key establishment — the direct replacement for the Diffie-Hellman and RSA key exchanges that Shor's algorithm threatens. Its security rests on the hardness of structured lattice problems, which are not known to be vulnerable to quantum attack. ML-KEM-1024 is the highest-strength parameter set, targeting the top security category, and is the sensible default for long-lived, high-value data.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium. This is the primary post-quantum signature scheme, also lattice-based, and the general-purpose replacement for ECDSA and RSA signatures. ML-DSA-87 is its highest-strength parameter set for applications that demand the greatest assurance.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+. This is a signature scheme whose security rests only on the properties of hash functions rather than lattices, providing an independent mathematical foundation. It produces larger signatures and is slower, but its conservative, well-understood basis makes SLH-DSA valuable where diversity of assumptions matters, such as firmware and long-term code signing.

The deliberate inclusion of both lattice-based schemes and a hash-based scheme is a hedge against the small but real possibility that a future advance weakens one mathematical family. Depending on a single hard problem for all of your post-quantum security would recreate, in a new form, the fragility that HNDL exploits. Standardizing on independent foundations is defense in depth applied to cryptographic assumptions.

Crucially, the current best practice is not to deploy these algorithms in isolation but in a hybrid construction that runs a proven classical algorithm alongside the post-quantum one. A hybrid key exchange combining X25519 with ML-KEM-1024 derives a shared secret from both, so an attacker would have to break both the classical elliptic-curve scheme and the lattice scheme to recover it. This protects against two opposite failure modes at once: a quantum computer that breaks X25519, and an as-yet-undiscovered classical weakness in a relatively young post-quantum algorithm. Hybrid is the responsible default for the transition period, and it is what we deploy throughout the Deflected platform.

The Mosca calculation: doing the risk math

The cleanest way to decide whether HNDL is your problem today or a problem you can defer is a conceptual model articulated by cryptographer Michele Mosca. It compares three durations and produces a simple, uncomfortable inequality.

Define three variables:

• X — the shelf life of your data: how many years this data must remain confidential. For a session token, near zero; for a genome or a state secret, decades.
• Y — your migration time: how many years it will realistically take your organization to inventory its cryptography and migrate to quantum-resistant algorithms across all the systems that handle that data. For a large enterprise, this is typically measured in years, not months.
• Z — time to quantum: how many years until a cryptographically-relevant quantum computer exists that can break the cryptography you use today.

Mosca's observation is that you have a problem the moment X + Y > Z. If the length of time your data must stay secret, plus the length of time it takes you to migrate, exceeds the time until a quantum computer arrives, then some of your data will still be sensitive and still be protected by broken cryptography when that computer becomes available — which means it can be harvested now and decrypted later. The inequality is powerful precisely because it does not require you to know Z exactly; it forces you to reason about all three quantities together.

The Mosca model reframes the timeline debate in a productive way. Skeptics tend to argue about Z — "quantum computers are decades away." But even a generous Z is defeated by a large X and a large Y, and the two variables you actually control are X and Y, not Z. You cannot make quantum computers arrive later, but you can shorten your migration time (reduce Y) and you can identify and de-scope data that does not truly need a long confidentiality horizon (reduce effective X). The whole discipline of post-quantum readiness is, in effect, the project of driving X + Y below any plausible Z. That is what a quantum-safe migration is engineered to do.

The response: inventory, crypto-agility, hybrid migration

Defending against harvest now, decrypt later is not a product you buy and switch on; it is a migration program with a clear structure. It breaks into three disciplines, executed in roughly this order but iterated continuously.

1. Build a cryptographic inventory

You cannot protect what you cannot see, and most organizations have far less visibility into their own cryptography than they assume. A cryptographic inventory — sometimes assembled into a Cryptographic Bill of Materials (CBOM) — catalogs every place cryptography is used across the estate: TLS termination points, VPNs, databases and their encryption-at-rest configuration, code-signing and certificate infrastructure, hardware security modules, application libraries, embedded devices, and third-party services and their key management. For each, you record the algorithms, key sizes, certificate lifetimes, and the sensitivity and shelf life of the data involved.

This inventory is the single highest-leverage step, for two reasons. It surfaces the Shor-vulnerable public-key usage that actually needs to change, separating it from the symmetric cryptography that merely needs larger keys. And it produces the data-shelf-life picture that drives prioritization under the Mosca model, so you migrate the long-lived, high-value systems first rather than treating everything as equally urgent. Federal guidance makes this inventory the mandated first step for exactly these reasons.

2. Establish crypto-agility

The deeper lesson of the post-quantum transition is that this will not be the last cryptographic migration. Algorithms will continue to be deprecated and replaced, and an organization that hard-codes a specific algorithm into thousands of systems will face this pain repeatedly. Crypto-agility is the architectural property of being able to change cryptographic algorithms without re-engineering the systems that depend on them — achieved by abstracting cryptography behind well-defined interfaces, centralizing algorithm and key policy, negotiating algorithms rather than fixing them, and building the ability to roll a new algorithm out and an old one back cleanly.

Crypto-agility is what turns Y — your migration time — from a multi-year ordeal into a manageable, repeatable process. It is the difference between a one-time heroic project and a durable capability. Investing in it now pays back not only for the post-quantum migration but for every cryptographic change that follows.

3. Migrate with hybrid classical + PQC

With visibility and agility in place, the migration itself proceeds by priority. Long-lived, high-value data and the key exchanges protecting it move first. The recommended target for the transition period is a hybrid deployment: pair a battle-tested classical algorithm with a NIST post-quantum algorithm so that security holds unless both are broken. In practice this means:

1. Hybrid key establishment — combine X25519 with ML-KEM-1024 (FIPS 203) so recorded handshakes resist both classical and quantum attack. This is the direct defense against harvested TLS traffic.
2. Post-quantum signatures — adopt ML-DSA-87 (FIPS 204) for general-purpose signing, and SLH-DSA (FIPS 205) where an independent, hash-based assurance basis is warranted, such as firmware and long-lifetime code signing.
3. Strengthen the symmetric layer — standardize on AES-256 for data at rest and in transit so the Grover speedup leaves ample margin, and ensure the keys are wrapped and exchanged using the post-quantum mechanisms above rather than legacy RSA or ECC.
4. Reduce shelf life where you can — shorten certificate and key lifetimes, rotate aggressively, and de-scope data that does not genuinely require a long confidentiality horizon, directly shrinking X in the Mosca inequality.

Hybrid is not a permanent state; it is a bridge. It buys protection during the years when the post-quantum algorithms are still accumulating cryptanalytic scrutiny, without giving up the protection of the classical algorithms that already have decades of it. As confidence in the post-quantum schemes matures, the classical component can be retired on your own schedule — which is only possible if you built crypto-agility in step two.

The strategic point to hold onto is that HNDL rewards the patient attacker and punishes the procrastinating defender, but the reverse is also true. The organization that inventories its cryptography, builds agility, and migrates its long-lived data to hybrid post-quantum protection ahead of the curve removes itself from the harvest. There is nothing left to decrypt later because there is nothing worth harvesting now. That is an achievable posture with standards that already exist — the only variable left is whether you start before or after your most valuable data has been copied.

Frequently asked questions