Harvest now, decrypt later: why your data is already at risk

Harvest now, decrypt later is the one quantum threat that is already running: an attacker copies your encrypted traffic or files today, stores them, and decrypts them once a quantum computer can break RSA or elliptic-curve keys. If your organization handles data that must stay secret for ten years or more, such as health records, pensions, identity data, legal files or trade secrets, the exposure started when that data first crossed a network under classical encryption. The fix is known and much of it is cheap. The hard part is finding where it applies.

What does harvest now, decrypt later mean?

It means data stolen today but read years from now. The theft and the decryption are separated in time, so the attacker can wait for the technology to arrive.

NIST’s explainer on post-quantum cryptography puts it plainly: adversaries may “capture encrypted data and hold onto it, in the hopes that a quantum computer will break the encryption down the road.” The OpenSSH project uses the older name, “store now, decrypt later,” and describes the same move: collect encrypted SSH sessions now and decrypt them once a quantum computer is available.

The reason this works is technical and specific. Most encrypted connections (TLS for websites and APIs, SSH, many VPNs) use public-key cryptography once, at the start, to agree on a symmetric session key. Everything after that is encrypted with AES or a similar cipher. If someone records the whole exchange, including that first handshake, and later breaks the public-key part with Shor’s algorithm, they recover the session key and can read everything that followed. AES itself was never broken. The key was simply handed over in a form a quantum computer can open.

Is anyone doing this today?

No government or company has publicly attributed a specific harvest now, decrypt later campaign, and it would be dishonest to claim otherwise. What exists is a consistent warning from the agencies that would know.

In August 2023, CISA, the NSA and NIST published a joint factsheet saying threat actors “could be targeting data today that would still require protection in the future,” naming “harvest now, decrypt later” directly. Google’s security team wrote in March 2026 that “the threat to encryption is relevant today with store-now-decrypt-later attacks.” Collecting traffic is cheap for an intelligence service with access to undersea cables, internet exchanges or a compromised router, and storage keeps getting cheaper.

So security teams treat it the way they treat many state-level threats: as something you cannot rule out and cannot detect after the fact. A recording made from a network tap leaves no trace on your systems.

Which data is at risk?

Data is at risk when it has to stay confidential for longer than it will take a quantum computer to arrive, and when it was protected by public-key cryptography at some point an attacker could observe. Short-lived data is not worth harvesting.

Michele Mosca, a quantum computing researcher at the University of Waterloo, framed this in a 2015 paper as three questions. How long must the data stay secure (call it x, the shelf life)? How long will it take you to migrate to quantum-safe tools (y)? How long until a quantum computer can break today’s cryptography (z)? If x plus y is greater than z, you have a problem, and in part it is already here.

Nobody knows z. The Global Risk Institute’s Quantum Threat Timeline Report, published in March 2026 from a survey of 26 experts, puts the chance of a cryptographically relevant quantum computer at 28 to 49% within 10 years and 51 to 70% within 15. We look at the estimates in detail in When is Q-Day?. For planning, the useful move is to fill in x and y for your own data and see how much room is left.

The shelf-life column is illustrative. Your legal team and your data owners set the real numbers. The other variable, migration time (y), is where most organizations are too optimistic: in large companies, replacing cryptography across applications, vendors and embedded devices often takes years, and NIST notes that past transitions have taken “10 to 20 years.”

What does harvest now, decrypt later not threaten?

It does not threaten data whose protection never depended on public-key cryptography an attacker could record, and it does not make signatures forgeable after the fact. Being clear about this keeps budgets pointed at the right systems.

A backup encrypted with an AES-256 key that was generated inside a hardware security module and never left it is not exposed by this attack. NIST considers AES-256 safe against known quantum attacks. A disk encrypted with a key derived from a password is a different question (password strength), not a quantum one.

Signatures work differently. To forge a signature, the attacker needs the quantum computer at the moment of the attack. Recording a signed software update in 2026 gives them nothing they could not get in 2032 anyway. That is why Google describes signatures as a “future threat” while encryption is a present one. Signatures still need to migrate before a quantum computer exists, because certificate chains and firmware roots of trust take years to replace, but they are not part of the harvest problem.

Why are blockchains a special case?

Public blockchains publish their data to everyone, so there is nothing to intercept: the harvest has already happened. A Federal Reserve staff paper from September 2025 (FEDS 2025-093), written by Jillian Mascelli and Megan Rodden, uses Bitcoin to show the consequence.

The authors argue that blockchain networks can adopt post-quantum signatures to protect future transactions, but the privacy of transactions already recorded stays exposed, because anyone can keep a copy of the ledger and analyze it with a quantum computer later. They also note that few mitigations exist for that past data. For banks and fintechs in Latin America experimenting with tokenization or distributed ledgers, the lesson is to keep anything confidential off a public chain unless you are comfortable with it being readable in the 2030s.

How do you reduce the exposure?

Protect the key exchange first, on the connections that carry long-lived data, because that is the only step that stops the harvest from working. Order matters more than speed here.

1. Map the long-lived data flows. List where health, identity, financial, legal and intellectual-property data moves between systems, sites, clouds and partners. This is part of a cryptographic inventory, covered in our guide to building a CBOM.
2. Turn on hybrid key exchange where it is already available. Current browsers, OpenSSH 10 and recent TLS libraries support hybrid ML-KEM with X25519. Cloudflare reported in October 2025 that most human traffic to its network was already protected this way. Check that your own servers, load balancers and reverse proxies negotiate it, not only the CDN edge.
3. Fix the links you control end to end. Site-to-site VPNs, database replication, backup transfers, internal service meshes and connections between data centers are often easier to upgrade than internet-facing systems because you own both ends.
4. Go after vendors and partners. Ask SaaS providers, payment networks, core-banking vendors and cloud providers when they will support post-quantum key exchange, and put the answer in the contract.
5. Re-wrap stored data where keys depend on RSA. Archives or messages encrypted with RSA-wrapped keys (some PGP and S/MIME setups, some key-escrow schemes) should be re-encrypted under keys protected by post-quantum or symmetric-only methods.
6. Reduce what you keep. Data you delete cannot be decrypted later. Retention policies are a cheap quantum control.

What should you ask your vendors?

Ask three direct questions: which of your products already negotiate hybrid ML-KEM key exchange by default, which will by a stated date, and what we need to change on our side to use it. Vague answers about being “quantum-ready” without versions and dates are a signal to escalate.

The sectors with the longest-lived data carry the most exposure. Healthcare and pharma organizations hold records that stay sensitive for decades, insurers hold life and pension contracts that span careers, and governments hold identity data for entire populations.

If you are not sure which of your systems pass the Mosca test, a quantum readiness assessment ranks them by data shelf life and migration difficulty in a few weeks. That tells you whether harvest now, decrypt later is a footnote for your company or the reason to start a post-quantum migration this year.