Harvest now, decrypt later means recording encrypted data today in the hope of decrypting it once quantum computers exist. You should worry if your data must stay confidential for many years and travels over links protected by quantum-vulnerable key exchange. Short-lived data matters far less.
The idea
CISA says that once quantum computers are sufficiently powerful they could break many widely used encryption and digital signature algorithms, and that such capability does not yet exist. Recording traffic costs an attacker little today. The bet is that the stored data is still valuable when decryption becomes possible.
A simple test
Ask two questions about each data flow.
- How long must this stay secret? Count years, not days.
- Could someone capture it in transit or from a stolen backup?
If the answer to the first is "a few weeks" (a session token, a one-time code), the exposure is small. If it is "decades" (health records, long-term contracts, state or trade secrets, source code of a long-lived product), the case for earlier action is stronger.
Who is in scope, and who can relax
- Organizations holding records with long confidentiality needs.
- Operators of critical infrastructure, which CISA says must begin preparing now.
- Anyone whose encrypted backups or traffic sit in places a third party could copy.
Teams whose data is low value after a short time. Their priority is still to make cryptography replaceable, but they can sequence it after the long-lived data flows.
What to do first
NIST says the finalized standards can and should be put into use now. For key establishment that is ML-KEM. Practical first steps:
- Inventory where public-key cryptography protects long-lived data.
- Ask vendors and cloud providers for their post-quantum plans. CISA's page suggests working with cloud providers on migration.
- Prefer protocols and libraries where algorithms can be swapped by configuration.
- Treat signatures separately. They matter for authenticity later, while key exchange matters for secrecy of recorded traffic.
A note on certainty
This is a risk model, not a report of observed attacks. The sources above state that the capability does not yet exist and give no date. Treat the threat as plausible and plan in proportion to how long your data must stay secret.
Common mistakes
The first mistake is treating all data the same. A blanket program stalls because the list is too long. Rank by lifetime and sensitivity instead.
The second is forgetting stored data. Encrypted backups, archives and database exports can be copied once and decrypted later, so they belong in the same inventory as network traffic.
The third is confusing the key exchange problem with the signature problem. Recorded traffic is a secrecy issue, solved by moving key establishment to ML-KEM when your stack supports it. Signatures protect authenticity going forward, and their migration timeline is driven by how long signed artifacts, such as firmware and certificates, stay trusted.
Quick check
Is my short-lived session data at risk from this?
Much less so. The concern is data that must stay confidential long after it is recorded.
Sources
- CISA: quantum and post-quantum cryptography
- NIST: first 3 finalized post-quantum encryption standards
Last reviewed: 19 October 2026.
