Is “Harvest Now, Decrypt Later” risk overstated?

A practical view of quantum risk and where security leaders should focus first

“Harvest Now, Decrypt Later” (HNDL) has become shorthand for one of the most discussed risks associated with quantum computing: An adversary captures encrypted information today, stores it and waits for a sufficiently capable quantum computer to break the cryptography protecting it.

The risk is real. But the shorthand can lead organisations to ask the wrong question.

Not every encrypted dataset has the same exposure. Not every cryptographic algorithm requires the same urgency. And replacing quantum-vulnerable algorithms without understanding how data, keys and trust mechanisms interact may not address the most significant risks first.

For CISOs and other executives, a more useful question is:

What could an adversary capture today that would give them a viable attack path tomorrow?

That changes post-quantum cryptography (PQC) from an algorithm replacement exercise into a risk-based security programme.

HNDL is about more than encrypted data

The classic HNDL scenario is easiest to illustrate through public-key cryptography. An attacker captures encrypted traffic or key material protected by RSA or elliptic-curve cryptography (ECC). In the future, a sufficiently capable quantum computer breaks that protection, potentially exposing historic data or keys.

That scenario matters. But it does not reflect the full complexity of enterprise encryption.

Modern environments combine transport layer security (TLS), certificates, identities, key management services (KMS), hardware security modules (HSMs), data encryption keys (DEKs), key encryption keys (KEKs), backups, signing mechanisms, replication services and cloud control planes.

The risk therefore does not sit neatly within one algorithm. It can emerge from how these components interact.

Consider data protected with AES-256. If an attacker captures only the encrypted data, without obtaining the keys or other material needed to recover them, the practical quantum exposure is significantly different from a scenario in which the attacker also captures RSA- or ECC-protected key material.

The important question is not simply how the data is encrypted. It is also how the keys needed to decrypt it are exchanged, wrapped, returned, recovered and authenticated.

That distinction should influence where organisations invest first.

So, is HNDL overstated?

Sometimes, but not because the underlying threat should be dismissed.

The problem is applying HNDL too broadly.

A statement such as “encrypted data captured today will become readable when quantum computers arrive” removes important context. An adversary needs a viable route from what they capture today to what they want to compromise later.

For long-life sensitive information, that exposure could include the encrypted data itself – whether in transit or at rest – as well as vulnerable key-exchange traffic, wrapped keys, recovery packages or trust mechanisms protected by cryptography that quantum computing could eventually break.

This suggests a more precise way to think about the problem:

HNDL risk is highest when long-life sensitive information intersects with a key, trust or recovery path that an adversary can capture today and exploit later.

For security leaders facing competing investment priorities, that distinction matters. A broad inventory may tell you where cryptography exists. It does not necessarily tell you where your greatest future exposure sits.

Think “Harvest Now, Exploit Later”

There is another limitation to the HNDL shorthand: “decrypt” can make the problem sound exclusively about confidentiality.

The potential attack surface is wider.

An adversary could collect material today that might eventually help recover keys, impersonate trusted services, undermine trust chains or exploit recovery processes.

A broader framing is therefore Harvest Now, Exploit Later (HNEL).

The material worth considering includes:

• Key material: Wrapped DEKs, KMS unwrap traffic, key import and export packages and HSM recovery artefacts
• Identity and network evidence: TLS session captures, service certificates, signed tokens and related trust material
• Recovery material: Backup recovery packages, escrow files and signed key-management artefacts
• Trust mechanisms: Cryptographic material that could later enable impersonation or compromise

This framing matters because quantum readiness is not only a cryptography problem. It is also a question of identity, key management, operational resilience and the security architecture connecting them.

Five questions to prioritise quantum risk

Organisations do not need to replace every cryptographic mechanism at once. They need enough visibility to make informed decisions about what to address first.

For CISOs and security leaders, five questions can help establish that priority:

1. Which information must remain sensitive for the longest?

Start with data lifetime and business impact. Information that loses its sensitivity quickly does not carry the same HNDL exposure as information that must remain confidential for decades.

2. Where does RSA or ECC protect sensitive data, keys or trust?

Look beyond certificates and TLS to PKI, service identities, key wrapping, signing, recovery processes and HSM administration.

3. Where do plaintext encryption keys travel?

If applications receive plaintext DEKs from a KMS or HSM over TLS, examine whether that return path creates future exposure.

4. Which key and recovery packages depend on quantum-vulnerable cryptography?

Wrapped keys, imported key material, recovery packages and escrow arrangements can be as important as the encrypted datasets themselves.

5. What would an adversary actually need to capture today?

This is the question that connects cryptographic discovery to security risk. Map credible attack paths rather than stopping at an inventory of algorithms.

Migration takes time. Prioritisation should start now

PQC migration will touch more than cryptographic libraries. For many organisations, it will affect PKI, cloud services, certificates, APIs, KMS integrations, HSMs, identity systems, third-party products, applications, backups and operational processes

That makes waiting for a sufficiently capable quantum computer the wrong trigger for action. Organisations need time to discover dependencies, assess exposure, set priorities and manage migration without introducing unnecessary operational risk.

The objective is not to change everything immediately.

It is to understand which assets and attack paths create meaningful future exposure and begin reducing that exposure in a controlled way.

Start with the attack path, not the algorithm list.

That principle can help security leaders turn a broad and sometimes abstract quantum threat into a practical set of decisions about data, keys, trust and investment.

How CGI can help

Understanding HNDL and HNEL exposure starts with identifying which long-life data, key processes and trust mechanisms could be captured now and exploited later.

As an NCSC-assured PQC consultancy for discovery and migration planning, we help organisations:

• Identify HNDL- and HNEL-sensitive data and credible attack paths
• Assess exposure across applications, cloud environments, PKI, KMS, HSMs and third parties
• Prioritise action based on data lifetime, security exposure and business impact
• Translate findings into a practical PQC migration plan

We deliver these activities through PQC Essentials, our standardised approach to PQC discovery, risk assessment and migration planning.

To learn more:

Read the PQC Essentials brochure