Skip to content

Post-Quantum Cryptography • 3 min read

Harvest Now, Decrypt Later: The Quantum Threat That Already Applies Today

Why encrypted data captured today can be a liability years from now, how to judge whether your data is at risk, and which mitigations actually reduce exposure.

By CryptoAgile Labs Editorial Team • Published October 2026 • Last updated October 10, 2026

"Harvest now, decrypt later" (HNDL), sometimes called "store now, decrypt later," describes an attack that needs no quantum computer today. An adversary records encrypted traffic or steals encrypted archives now and waits. When a cryptographically relevant quantum computer (CRQC) eventually exists, the stored ciphertext is decrypted. The attack is passive, cheap relative to its potential value, and invisible to the victim.

How the attack works

Most encrypted traffic on the internet follows the same pattern. A public-key algorithm (RSA or elliptic-curve Diffie-Hellman) establishes a short-lived session key, and a symmetric cipher such as AES encrypts the actual data. Shor's algorithm on a large quantum computer would break the public-key step. An attacker who has recorded the handshake and the encrypted stream could recover the session key and then decrypt everything in that session.

Note what does not break: AES-256 itself. Grover's algorithm only halves its effective strength, which leaves 128 bits of security. The weak link is how the key was agreed, not the cipher that uses it.

Who is actually at risk

The risk is a function of three factors:

  • Confidentiality lifetime. How many years must this data stay secret? Marketing copy has a lifetime of days. Medical records, genomic data, intelligence, legal archives, source code and long-term contracts can have lifetimes of decades.
  • Interception feasibility. Can an adversary capture the traffic? Anything crossing the public internet, undersea cables, or shared networks is capturable by a well-resourced actor.
  • Adversary motivation. State actors and organized groups have the storage and patience; opportunistic criminals mostly do not.

A rough rule used by planners is Mosca's inequality: if the time your data must stay secret plus the time your migration will take is greater than the time until a CRQC exists, you already have a problem. Because nobody knows the third number precisely, the prudent approach is to shorten the first two.

What is uncertain

Estimates for when a CRQC might exist vary widely, and research on how many physical qubits are needed keeps changing as algorithms improve. No such machine exists today. This uncertainty is exactly why planners use data lifetime rather than predictions: you do not need to know the date to know that 20-year secrets sent over today's classical key exchange are a bet you may not want to make.

Mitigations that work

Hybrid key exchange. Combine a classical algorithm with ML-KEM so an attacker must break both. This is the most effective step for data in transit and is already supported by major browsers, CDNs and TLS libraries. See Hybrid TLS with X25519 and ML-KEM-768.

Move to ML-KEM in more places. VPNs, SSH, internal mTLS and service meshes carry sensitive traffic too, and are often forgotten.

Reduce what is worth stealing. Data minimization and shorter retention directly shrink HNDL exposure. Data you deleted cannot be decrypted later.

Protect archives at rest with symmetric keys. If an archive is encrypted with AES-256 under a key that never travels over a classically protected channel, it is not exposed in the same way. The exposure appears when the key itself was wrapped with RSA or sent via classical key exchange.

Strengthen key wrapping. Review how data encryption keys are wrapped by KMS or HSM products and ask vendors about post-quantum support.

What does not help

  • Longer RSA keys. RSA-4096 only raises the cost for a classical attacker; it falls to the same quantum algorithm.
  • Obscurity or private protocols that still rely on classical key exchange.
  • Waiting for certainty about quantum timelines.

A short action list

  1. Identify data with a confidentiality lifetime over ten years.
  2. List the channels that carry it, in transit and in backups (see Building a Cryptographic Inventory).
  3. Enable hybrid key exchange on external endpoints first.
  4. Ask each vendor in the path for a dated PQC roadmap.
  5. Reduce retention for data that no longer needs to exist.

Signatures are a separate matter: they threaten authenticity going forward, not the secrecy of data already captured. That is why key exchange is the urgent migration and signatures follow, as discussed in Post-Quantum Digital Signatures.

Sources and further reading

This article is for educational purposes and is not professional security, legal or compliance advice. Spotted an error or an out-of-date detail? Email us a correction. See our editorial policy.