Harvest Now, Decrypt Later: Why Your Most Sensitive Data Has a Quantum Timeline

In Brief (TL;DR)

Quantum security isn't just an encryption problem, it's a trust problem. As cryptography underpins identity, authentication, devices, workloads, APIs and data access, organisations need to understand where trust is established across their environment and whether those mechanisms will remain secure in a quantum future.

When executives ask when quantum computing becomes a cybersecurity problem, I think we are asking the wrong question. The question should not simply be: When will a quantum computer exist that can break today's cryptography? The better question is: How long does our most sensitive data need to remain confidential?

That is the issue behind Harvest Now, Decrypt Later. An attacker does not necessarily need to break the encryption today. They can capture encrypted information today and hold onto it until they have the ability to decrypt it later. That changes the risk timeline.

Not all data has the same confidentiality requirement. A marketing plan may lose value quickly. Other information does not.

• Critical infrastructure designs

• Proprietary manufacturing information

• Long-lived credentials
  
• Strategic plans

Some of that data needs to remain confidential for years or even decades. That means the quantum timeline for that information may already have started.

I think organizations need to look at this as: how long must the data remain confidential + how long will migration take, versus when might the cryptographic risk become real? We do not know the exact answer to the last question. But we can measure the first two. That is enough to begin prioritizing.

The part I think is particularly important is connecting quantum risk to reachability. Data does not just sit there by itself. Something can reach it: a human, workload, application, service account, API, AI agent or privileged administrator.

Identity determines who or what can reach the data. Network controls determine whether the path exists. Cryptography protects the session. Data controls determine what happens after access is established.

That is why I increasingly think the modern control model has to bring together Identity + Network + Cryptography + Data.

Instead of starting with, "Where do I have RSA?" start with, "What information would materially hurt us if it became readable ten years from now?" Then work backward: where does it live, how does it move, what applications use it, what identities can reach it, what network paths reach it, what cryptography protects it and which vendors are involved?

• Sensitive-data identification

• Data reachability analysis

• Identity and privilege mapping

• Crypto dependency mapping

• PKI and certificate reviews

• Vendor dependency analysis

• Migration roadmap development

The objective is not to create a giant list of every algorithm in the enterprise. It is to understand which cryptographic weaknesses actually create meaningful business exposure.

Your data has a quantum timeline. The question is whether you understand it.