How harvest now, decrypt later works
An adversary with access to network traffic, through a compromised router, a cable tap, a cloud provider or a supply-chain foothold, copies encrypted sessions and stores them. Storage is cheap. Today the copies are unreadable. Once a cryptographically relevant quantum computer exists, the public-key exchange that protected each session can be broken, the session key recovered, and the stored data read in full. The attack happens now. The damage happens on Q-Day.
Who is at risk
Anyone whose data must stay secret for longer than the time to Q-Day, which is exactly what Mosca's inequality measures. High on the list:
- government, defence and diplomatic communications,
- health, genetic and financial records,
- intellectual property, designs and source code,
- critical infrastructure: grid topology, plant designs, safety-system configurations and long-lived keys.
US agencies have warned about this explicitly. The joint CISA, NSA and NIST factsheet "Quantum-Readiness: Migration to Post-Quantum Cryptography" names the collection of encrypted data for later decryption as a current threat.
What it means for SCADA and industrial control
Industrial networks are attractive targets because their secrets are long-lived and their cryptography changes slowly. Live telemetry ages out quickly, but the engineering traffic that crosses the same conduits, configuration pushes, remote maintenance sessions and key material, stays valuable for decades. A conduit that is still on classical key exchange in 2027 is donating that traffic to whoever is recording it.
The harvest-now-decrypt-later threat is not theoretical. Adversaries are already storing encrypted traffic from grid SCADA networks today, betting they will have a cryptographically relevant quantum computer in 10 years. Every utility that has not started its PQC migration is donating data to that bet.
Shujaatali Badami, pre-cleared press quoteHow to defend against it
Harvest now, decrypt later is a key-exchange problem, so the fix is post-quantum key exchange, and it can be deployed before signatures are migrated:
- Enable hybrid key exchange that pairs a classical algorithm with ML-KEM (FIPS 203), for example the X25519MLKEM768 group now supported in major TLS libraries and browsers.
- Prioritise the links that carry long-lived secrets, not the busiest links.
- Shorten data retention where you can. Data that no longer exists cannot be decrypted later.
- For OT, put post-quantum gateways on conduits between zones rather than waiting for every controller to be replaced. See the ICS and OT migration guide.