Harvest now, decrypt later: the quantum threat that is already happening

Most security threats follow a comforting pattern: the attack becomes possible, then you defend against it. Harvest-now-decrypt-later inverts that. The attack is underway before the capability exists, and by the time the capability arrives, the defense window has closed.

The mechanics

The scheme is simple. An adversary records encrypted data today: intercepted traffic, exfiltrated database dumps, stolen backups. They cannot read it now. They store it. When quantum computers capable of running Shor’s algorithm at scale arrive, the RSA and elliptic-curve cryptography protecting that data breaks, and everything harvested becomes readable retroactively.

Nobody can tell you the year that happens; serious estimates span the coming decade and beyond. But the precise year matters less than a simple inequality, sometimes framed as Mosca’s theorem: if the time your data must remain confidential, plus the time your migration will take, exceeds the time until a cryptographically relevant quantum computer exists, you are already late.

Which data is actually at risk

Not everything. Harvest-now-decrypt-later only pays off for data whose value survives the wait. Run your data categories through one question: would disclosure in ten to fifteen years still cause harm?

• Long-lived personal data: health records, biometric data, identity documents. Harmful for a lifetime.
• Financial and legal records: transactions, contracts, disputes. Harmful for decades.
• Intellectual property: designs, formulas, source code for products with long lifecycles.
• Government and defense material: the original driver for national migration timelines like CNSA 2.0.
• Credentials and keys: mostly rotated before it matters, unless they protect archives.

Session tokens and yesterday’s cache do not make the list. Your customer database does.

Why symmetric encryption mostly survives

An important nuance: AES-256 is not meaningfully threatened. Grover’s algorithm halves effective symmetric key strength, and 128 bits of remaining security is still unbreakable. The quantum break lands on public-key cryptography: the RSA and elliptic-curve key exchange that protects data in transit, and the signatures that establish trust.

This is why the priority target for migration is key establishment. If today’s TLS session is recorded and its elliptic-curve key exchange is broken a decade from now, the session contents fall, regardless of how strong the symmetric cipher inside was.

What defending actually requires

1. Know where your public-key cryptography is. Not roughly. Exactly: which services, which libraries, which certificates, which configurations. This is the cryptographic inventory problem, and it is the step most organizations cannot do today.
2. Migrate key exchange first. Hybrid schemes that combine classical and post-quantum key encapsulation protect recorded traffic even if one component later falls, and major protocol implementations already support them.
3. Sequence by data lifetime. The systems protecting decade-scale secrets move first. This turns an overwhelming program into an ordered backlog.
4. Watch the signatures too, on a different clock. Signature forgery requires the quantum computer to exist at attack time, so it is less urgent than key exchange, but code-signing roots and long-lived document signatures deserve early attention because their trust chains take years to rotate.

The uncomfortable summary

If your organization holds data that must remain confidential for a decade or more and it moves across networks protected by classical key exchange, the harvest against it is plausibly already in someone’s storage. The quantum-readiness verdict on your own estate is measurable today, and measuring it is the only step that makes every other step schedulable.