Harvest now, decrypt later is the practice of copying encrypted data today in the hope of decrypting it once a powerful enough quantum computer exists. It matters only for data that must stay secret for many years. The response is to inventory your cryptography and begin moving to NIST's post-quantum standards.
Why would anyone store data they cannot read?
Storage is cheap and secrets can be long lived. NIST's draft transition report IR 8547 describes the logic: organizations must begin migrating before the time their data needs protection, plus the time migration takes, exceeds the time until a cryptographically relevant quantum computer exists. Even if such machines are a decade away, the report says, migration must begin now to avoid having encrypted data exposed later. It names government secrets and medical records as data with long term sensitivity.
NIST does not claim to know the date. The argument is about planning, not prediction.
Which cryptography is affected?
Public key algorithms, mainly. IR 8547 says RSA, ECDSA, EdDSA and the elliptic curve key establishment schemes are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer. These are the algorithms used for key exchange and signatures in TLS, VPNs, code signing and certificates.
Symmetric encryption and hashing are in better shape. NIST's security categories list AES-128 through AES-256 and SHA-256 and SHA3-384 as reference points for post-quantum strength comparisons, which is why the migration work focuses on key establishment and signatures rather than bulk encryption.
Why do key exchange and signatures differ?
The report draws a line that planners should copy. For encryption and key establishment, harvest now, decrypt later is a real threat: recorded traffic can be attacked later. For authentication, it is not: an authentication system stays secure as long as its algorithms and keys are secure at the moment of authentication. Authentication may continue with quantum-vulnerable algorithms until capable quantum computers appear, at which point those algorithms must be disabled.
So key exchange comes first, and signatures follow on the longer timeline.
What are the new standards?
In August 2024 NIST finalized its first three post-quantum standards. FIPS 203 specifies ML-KEM, a key encapsulation mechanism for establishing shared secret keys over a public channel, in three parameter sets. FIPS 204 specifies ML-DSA and FIPS 205 specifies SLH-DSA, both digital signature schemes. NIST says it evaluated 82 algorithms from 25 countries to get there. The FIPS 203 page also carries a planning note about an erratum to be fixed in a future revision, so check for updates when you implement.
What are the dates?
IR 8547 is an initial public draft, so treat its tables as proposed. It lists 112-bit-strength RSA and ECDSA as deprecated after 2030, and quantum-vulnerable signature algorithms of 128 bits or more as disallowed after 2035. It also cites National Security Memorandum 10, which sets 2035 as the primary target for completing migration across US federal systems. Check the final version before you quote a deadline in a contract.
What does a sensible plan look like?
Constructed example: a medical device maker stores patient telemetry that must remain confidential for 25 years. Data sent over TLS today could be recorded now. Its first action is to find every place that data crosses a network, then test hybrid key exchange, which combines a classical and a post-quantum method, on that one path. Its marketing website, with nothing secret on it, goes later.
How to check or apply this
- Classify data by how long it must stay confidential. Anything beyond ten years is a priority.
- Build a cryptographic inventory: libraries, protocols, certificates, hardware modules and which algorithms each uses.
- Find where long-lived sensitive data crosses networks you do not control.
- Ask each vendor for its post-quantum roadmap and whether hybrid key exchange is supported.
- Make algorithms configurable in your own code so a swap is a setting, not a rewrite.
- Test ML-KEM in a non-production environment and measure the extra handshake size and latency.
- Track the final version of IR 8547 and update your plan.
Quick check
Is harvest now, decrypt later happening today?
NIST treats it as a plausible threat that justifies early migration. It does not give evidence about specific collection, so plan for it where data must stay secret for years.
Do I need to replace AES?
The migration focus is on public key algorithms for key establishment and signatures. NIST's work centers on those rather than on AES.
Sources
- NIST IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards
- NIST, FIPS 203, ML-KEM Standard
- NIST, first three finalized post-quantum encryption standards announcement
Last reviewed: 18 October 2026.
