Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry, ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry, KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry, TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry, AESAESAdvanced Encryption StandardThe Advanced Encryption Standard, a symmetric block cipher standardized by NIST that encrypts data using shared secret keys of 128, 192, or 256 bits.Read the full entry, CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry are defined in the glossary.
Read this first
Harvest-now-decrypt-later (HNDL) means an adversary records your encrypted traffic today and stores it until a quantum computer can break the key exchange that protected it. The decryption is in the future; the exposure is now. Any secret whose value outlives the time-to-quantum is already at risk. The fix is not to wait for Q-day: it is to migrate key exchange to a post-quantum standard before then.
The headline worry about quantum computing is that Shor's algorithm breaks RSA and elliptic-curve cryptography, the asymmetric algorithms behind almost every TLS handshake, VPN tunnel, and signed software update. The intuitive response is: no such machine exists yet, so there is time. Harvest-now-decrypt-later is the argument for why that intuition is wrong.
The threat model
An adversary who can observe your network (a nation-state at an internet exchange, a cloud tenant on a shared fabric, anyone with a tap) does not need to break your encryption in real time. They record the ciphertext and the key-establishment messages and archive them. Storage is cheap; patience is free. When a cryptographically-relevant quantum computer arrives, they replay the archive and recover the session keys retroactively. Everything you sent under those keys is then readable.
This works specifically against the asymmetric key exchange, not the symmetric bulk cipher. AES-256 is not meaningfully threatened by quantum computers; the problem is that the AES session key was itself established using RSA or (EC)DH, which Shor's algorithm breaks. Recover the key exchange and you recover the session key and thus the plaintext.
The maths of the exposure window
Whether a given secret is at risk is a simple inequality, usually attributed to Michele Mosca. Let X be how many years your data must stay confidential, Y the years it takes you to migrate to post-quantum cryptography, and Z the years until a quantum computer can break today's algorithms. If X + Y > Z, you have a problem: your data is still sensitive at the moment it becomes decryptable.
- X, shelf life. Health records, state secrets, biometric identifiers, and long-term contracts stay sensitive for decades. Session cookies do not.
- Y, migration time. For a real organization this is years, not weeks: you have to find every use of vulnerable crypto, plan the change, and roll it out without breaking production.
- Z, time to quantum. Nobody knows Z precisely, which is exactly the point: you must plan against a range, and the policy deadlines (CNSA 2.0's 2033, the US federal timeline) encode the conservative end of that range.
"We'll migrate when quantum computers are real" is already too late
By the time Z is known, the harvesting has been happening for years and Y still has not started. The whole force of the HNDL argument is that the decision to migrate must be made while Z is still uncertain, because the data being recorded today is decrypted on the adversary's schedule, not yours.
What this means in practice
HNDL reorders the migration priority list. Signatures (code signing, document signing, certificates) are not exposed to harvesting in the same way, because a forged signature is only useful after the quantum computer exists; you cannot forge retroactively. Key exchange is different: the damage is being set up right now. That is why the first concrete step almost everyone takes is moving TLS to hybrid key exchange, which wraps a post-quantum KEM (ML-KEM) around the classical exchange so recorded traffic is protected even though the endpoints are unchanged elsewhere.
Working out which of your secrets are already exposed
The hard part of HNDL is not understanding it: it is knowing which of your systems are exposed and in what order to fix them. We build the cryptographic inventory that tells you where vulnerable key exchange actually lives, translate it into a migration roadmap sequenced by data shelf life, and train your teams (education) so the reasoning above becomes part of how they design systems. Start with the inventory: nothing you have not located gets protected.