Harvest Now, Decrypt Later: The Deadline That Already Passed

There is a comforting version of the quantum threat that goes: no cryptographically relevant quantum computer exists yet, so there is time. For digital signatures, that is roughly true. For confidentiality, it is dangerously wrong, and the reason is a phrase every security team should be able to recite: harvest now, decrypt later.

The threat that does not wait

The attack requires no future technology to begin. An adversary records encrypted traffic today — a VPN session, a TLS connection, an exfiltrated database of ciphertext — and simply stores it. The decryption happens whenever a capable quantum computer becomes available, against the algorithms that protect it now: RSA and elliptic-curve key exchange, both of which a sufficiently large quantum computer would break.

The consequence reorganizes the whole migration timeline. The question is not "when will quantum computers arrive." It is "how long does this data need to stay secret." A session token that expires in an hour is safe; by the time any quantum machine exists, the token is long dead. A medical record, a state secret, an intellectual-property archive, or anything with a ten- or twenty-year confidentiality requirement is a different matter entirely. If it is transmitted under classical encryption today and recorded, its confidentiality clock is already running against a machine that does not need to exist yet.

For those long-lived secrets, the migration deadline is not a future date. It is in the past, because the data being protected now is the data that will be decrypted later.

What the timelines actually encode

This is why the published migration schedules do not wait for the threat to materialize. The NSA's Commercial National Security Algorithm Suite 2.0 sets milestones running through roughly 2030 to 2033 for national-security systems (NIST PQC standardization overview). Those dates are not predictions of when quantum computers arrive; they are deadlines for getting confidential data off vulnerable cryptography before it is too late to matter. A 2033 migration deadline on a secret that must hold until 2045 already implies twelve years of exposure for anything captured in the meantime.

The only sane sequencing

Harvest-now-decrypt-later turns migration from a uniform project into a triage problem, and the triage key is data lifetime:

1. Inventory by confidentiality requirement. Find the data that must stay secret for years, not hours. That is the priority, regardless of how busy the system is.
2. Migrate those channels to hybrid post-quantum key exchange now. Pairing ML-KEM with classical X25519 closes the harvest window without betting everything on young cryptography.
3. Accept that short-lived secrets can wait. Spending the first migration effort on session tokens while archival data sits exposed is the wrong order.

The uncomfortable truth is that for the most sensitive long-lived data, the perfect time to migrate was before it was ever sent. The next best time is now, and the gap between those two is exactly the data an adversary is hoping you leave unprotected.

Sources

• NIST Post-Quantum Cryptography Standardization (overview, incl. CNSA 2.0 timeline): https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization
• NIST CSRC, "Post-Quantum Cryptography FIPS Approved" (2024): https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
• Cloudflare, "State of the post-quantum internet in 2025": https://blog.cloudflare.com/pq-2025/