Most security advice is about keeping attackers out. Harvest now, decrypt later is the attack that does not need to get in, does not need to break anything today, and does not care whether you notice. It simply records encrypted traffic or copies encrypted archives, stores them, and waits.
It is also called store now, decrypt later. The premise is uncomfortable and simple: encryption is not a permanent state. It is a bet that the cost of breaking a key stays higher than the value of what the key protects, for as long as that value lasts. Harvest now, decrypt later attacks the second half of that sentence.
Why waiting is a rational strategy
An attacker who captures your encrypted data today and cannot read it has spent almost nothing. Bulk storage is among the cheapest things in computing, the capture itself can be entirely passive, and the target never receives an alert because nothing was broken into. There is no failed login, no ransomware note, no anomaly in the logs.
What makes it worth doing is the asymmetry of time. The attacker only needs the capability to arrive eventually. You need your confidentiality to hold continuously. Those are very different bets, and only one of them has a deadline.
The uncomfortable implication: if data you sent five years ago was captured then, no action you take today can protect it. Harvest now, decrypt later is the one category of breach where the damage is decided in advance and revealed later.
The arithmetic that tells you whether this is your problem
There is a clean way to decide whether any of this applies to your business, usually credited to the cryptographer Michele Mosca. Three numbers:
- X, the secrecy lifetime. How long this data must remain confidential.
- Y, the migration time. How long it takes you to move to cryptography that resists the new attack, across every system, vendor and backup you hold.
- Z, the time until a capable machine exists. Genuinely unknown, and the only one of the three you cannot influence.
If X + Y > Z, you are already late. The point of the formulation is that it does not require you to predict Z. It requires you to notice that X and Y are often much larger than people assume, and that both are entirely within your own records.
| Business data | Realistic secrecy lifetime (X) | Exposed to this? |
|---|---|---|
| Delivery notification, stock alert | Days | No |
| Pricing, quotes, commercial terms | 1 to 3 years | Marginal |
| Signed contracts and NDAs | Term of the agreement, often 10 years or more | Yes |
| Personnel files, payroll, HR records | Employment plus statutory retention, decades | Yes |
| Client records in regulated sectors | Set by regulation, frequently 7 to 30 years | Yes |
| Trade secrets, formulations, source code | Indefinite | Yes, most of all |
Read that table against your own filing and the exercise stops being theoretical. Most businesses hold nothing in the top row and a great deal in the bottom three.
What actually breaks, and what does not
This is where most coverage of the subject becomes unhelpful, because it implies that a quantum computer dissolves encryption in general. It does not. The exposure is specific, and knowing which half you are looking at changes what you should do.
| What you use it for | Typical algorithm | Quantum exposure |
|---|---|---|
| Agreeing a session key, signing | RSA, Diffie–Hellman, elliptic curve | Broken by Shor's algorithm, which solves the underlying maths directly |
| Encrypting the data itself | AES-256 | Weakened by Grover's algorithm to roughly 128 bits of security, which remains far out of reach |
| Integrity, fingerprints, passwords | SHA-256 and similar | Weakened similarly, and similarly still safe at full width |
So the bulk encryption protecting your files is not the weak point. The key exchange is. An attacker who records a session and later recovers the key that was negotiated at the start of it can decrypt everything that followed, no matter how strong the cipher in the middle was.
There is a second detail worth knowing, because it is routinely lost in summaries. Grover's algorithm gives a square root speedup, but it does not parallelise well. Splitting the search across a thousand machines buys roughly a factor of thirty, not a thousand. Symmetric cryptography at full key length is in far better shape than headlines suggest.
How far the attack has actually got
Predictions in this field are cheap and almost always unfalsifiable. Measurements are rarer and considerably more useful, and there is now a public one to point at.
The quantum computing as a service platform Zero Kelvin Simulation Foundry ran Shor's algorithm against real elliptic curves and published exactly what it recovered. Private keys of 3, 4, 5, 6 and 7 bits were recovered from their public keys, using 9 to 21 qubits. The algorithm does what it claims. What it also does is run into a wall that can be stated as a number rather than an opinion:
- Each extra bit of key multiplied the two-qubit gate count by roughly five, from 328 gates at 3 bits to 235,470 at 7. Width grew gently. Depth is what ran away.
- A 3-bit key survived at 99.0 percent two-qubit fidelity. A 4-bit key required better than 99.8 percent. One additional bit moved the requirement from almost any current device to only the very best.
- secp256k1, the 256-bit curve behind Bitcoin and Ethereum, needs on the order of 2,304 logical qubits. No machine in existence is close.
Both halves of that matter. The algorithm is real and it works, which is why the harvesting is rational. The gap to a business-relevant key is enormous and measurable, which is why panic is not. Anyone selling you urgency without a number is selling you something.
What it does not tell you is Z. A measured ceiling on today's hardware is not a forecast about next decade's. That is precisely why the sensible response is driven by X and Y, the two numbers you control, rather than by a prediction nobody can make honestly.
The defence is already standardised and already shipping
The genuinely reassuring part of this story is that the replacement cryptography is not speculative or years away. It exists, it has been through a long public competition, and it is being deployed.
NIST finalised its first post-quantum standards in August 2024: ML-KEM for key encapsulation (FIPS 203), and ML-DSA and SLH-DSA for signatures (FIPS 204 and 205). These are designed to resist the attacks described above while running on ordinary hardware you already own.
More importantly for most businesses, the migration is arriving through software you do not maintain. Major browsers and large cloud providers have moved to hybrid key exchange in TLS, combining a traditional elliptic curve exchange with a post-quantum one so that an attacker must break both. Hybrid is the sensible transitional design: it cannot be weaker than what it replaces.
What a business should actually do
Five steps, in the order that gives the most protection for the least disruption.
- Inventory by secrecy lifetime, not by sensitivity. The question is not how bad a leak would be, it is how long the data must stay secret. Those produce different lists, and the second one is the one this risk follows.
- Find the long-lived data that travels. Data that has never left a controlled system was never available to harvest. Exposure follows transmission and third party copies, so map those first.
- Ask your vendors for a roadmap, and note who cannot answer. Most of your migration will be done by suppliers. A vendor with no position on post-quantum cryptography in 2026 is telling you something about their engineering, whatever the answer eventually is.
- Reduce the number of places long-lived data lives. This is unglamorous, entirely available today, and helps against every threat, not just this one. Every additional copy is another thing to migrate and another thing to be captured.
- Refuse to buy urgency. Treat any product marketed as quantum-proof with the suspicion the phrase deserves, and ask which standardised algorithm it implements. If the answer is not one of the named ones above, you have learned what you needed to know.
Note what is not on that list: replacing your AES encryption, or acting this quarter. The realistic failure mode for most businesses is not moving too slowly on cryptography. It is having no idea where the long-lived data sits when the time comes to move it.
Fewer copies, in one governed place
CEMP Business keeps contracts, client records, files and financial data inside a single system, where the AI agent works on your data in place instead of asking you to copy it somewhere else. That does not make anything post-quantum, but it does make step one answerable.
The honest summary
Harvest now, decrypt later is a real strategy, cheap to execute, and impossible to detect from the target's side. The algorithm that eventually reads the harvest is real, has been run publicly, and currently stops at seven-bit keys against a target that is 256 bits wide.
Both of those facts are true at once, and holding both is the whole skill. The businesses that handle this well will not be the ones that reacted fastest to the headline. They will be the ones that already knew which of their data has to stay secret for thirty years, and where all of it lives.