Harvest Now, Decrypt Later: The Quantum Data Risk Explained

An attacker doesn’t need to break your encryption today to benefit from breaking it years from now. They just need to have a copy of the data waiting when they can.

Back in part 4, we established something important: no quantum computer capable of breaking today’s common encryption exists yet, and serious estimates put that possibility years away. It’s tempting to conclude that means there’s time to wait. Harvest now, decrypt later is the reason that conclusion is wrong.

If you only think about the moment of decryption, waiting seems reasonable. Nothing readable happens until a quantum computer exists, so why not deal with it when one does? Harvest now, decrypt later breaks that logic by moving the moment that actually matters. The theft, the part you could have prevented, already happened, potentially years before the decryption itself.

By the time a capable quantum computer exists, data encrypted with today’s vulnerable methods, and already sitting in an attacker’s storage, becomes exposed all at once, going back potentially years. Waiting doesn’t avoid the exposure. It just delays discovering it happened.

This is the detail that makes the risk practical to reason about rather than just alarming. Stealing and storing data for years only makes sense to an attacker if the data is still worth something years later. A great deal of data isn’t.

This is exactly why data retention matters as much as the encryption method itself when evaluating this risk, and it’s part of why a real inventory, the whole subject of part 1, needs to capture not just what encryption protects something, but how long that something stays sensitive.

The theft isn’t in the future. Only the reading is.

Put parts 5 and 6 together and the shape of the problem becomes clear: banks depend on vendors they don’t fully see into, and some of what those vendors are protecting right now is exactly the kind of long-lived data worth harvesting today. Which raises a very practical question for anyone doing this assessment: what actually counts as a good answer when you ask a vendor about their encryption? “Industry-standard encryption” clearly isn’t one. The next post is about what is.