Blog

Harvest Now, Decrypt Later (HNDL): What CISOs Need to Know

Adversaries are collecting encrypted data now to decrypt later. What HNDL means, which data is exposed and how to assess your risk.

Harvest Now, Decrypt Later (HNDL) describes an adversarial strategy in which encrypted data is intercepted and stored today, in the expectation that it can be decrypted in future once a cryptographically relevant quantum computer becomes available. The data does not need to be decrypted now. It simply needs to be captured and retained until the technology to break its encryption exists.

Of all the threats associated with the quantum computing era, HNDL is arguably the one that has captured the most attention. It appears frequently in vendor marketing, government advisories and conference agendas. Despite that visibility, it remains one of the most misunderstood risks in the post-quantum cryptography landscape.

For CISOs and senior security leaders, understanding it matters — not because it demands immediate panic, but because it requires a clear-headed, risk-based assessment of which data in your organisation is genuinely exposed and what the consequences of that exposure would be.

You may also see the same threat described as store now, decrypt later, collect now, decrypt later, or capture now, decrypt later. These are the same concept under different names.

Key points

  • HNDL requires no future capability to begin. Collection happens today with conventional technology.
  • Only data with long-lived confidentiality requirements is genuinely exposed. For most data, the value degrades faster than the threat arrives.
  • Mosca's framework provides a structured way to assess exposure without relying on speculation about quantum timelines.
  • The two failure modes are dismissing it entirely and over-buying in response to it. Both are avoidable with an inventory.

How HNDL works in practice

The mechanics are straightforward, which is part of what makes it concerning. Adversaries with the capability to intercept encrypted network traffic — through compromised infrastructure, supply chain access, or passive monitoring of communications — can collect and store vast quantities of encrypted data at relatively low cost. Storage is cheap, and the data does not need processing immediately.

The adversary's calculation is simple. If the data is still valuable by the time a quantum computer capable of breaking today's public-key cryptography exists, the investment in collection will have paid off. The encrypted data becomes a time-delayed asset, waiting to be unlocked.

This is not hypothetical. National cybersecurity agencies across multiple countries have publicly acknowledged that collection activity is likely already taking place. The question is not whether it is happening, but at what scale and against which targets.

What is actually vulnerable

The viability of HNDL depends on the algorithms protecting the intercepted data, and the distinction matters more than most coverage suggests.

  • Vulnerable: RSA and elliptic curve key exchange. A sufficiently capable quantum computer running Shor's algorithm breaks these outright, exposing the session keys and therefore the data they protected.
  • Not vulnerable in the same way: symmetric encryption. AES-256 retains 128 bits of security against Grover's algorithm, which remains computationally infeasible to attack.

The exposure sits in key exchange rather than bulk encryption. Traffic protected by TLS is at risk because the session key was negotiated using RSA or ECC — not because AES itself is weak. This is why the response is a PKI and key exchange problem before it is an encryption problem.

Which data and systems should organisations prioritise?

The test is simple: does this data still need to be confidential in ten, twenty or thirty years?

NIST and multiple national agencies explicitly warn that HNDL makes long-lived sensitive data particularly exposed. The categories most at risk are:

  • Government secrets and classified information, where sensitivity may persist for decades and formal declassification schedules define the exposure window precisely.
  • Personal health records and patient data, which retain relevance for a patient's lifetime and often beyond.
  • High-value intellectual property and trade secrets, where the competitive advantage may last as long as the product line.
  • Critical infrastructure operational data, including network topology, control system configuration and logs that would assist a future attacker.
  • Long-term contractual and legal information, particularly anything subject to privilege or long-running dispute.
  • Financial data subject to extended regulatory retention requirements.

Prioritising systems rather than data alone

Data classification identifies what matters. The next question is where that data crosses a network, because HNDL targets data in transit rather than data at rest.

In practice that means prioritising:

  • VPN and remote access infrastructure carrying sensitive traffic across untrusted networks.
  • Site-to-site links and inter-datacentre replication, particularly where they traverse third-party carriers.
  • External API integrations exchanging regulated or classified data with partners.
  • Backup and archive replication, which often moves the entire sensitive estate across a network on a schedule.
  • Any traffic transiting jurisdictions where interception capability should be assumed.

Sectors including defence, central government, healthcare, financial services and critical national infrastructure are inherently more exposed, because the data they hold retains sensitivity over extended periods. In these environments HNDL is not a distant concern. It is a material risk that warrants prioritised attention now.

Maintaining perspective

While HNDL is a serious concern for certain organisations and data types, it is equally important to maintain perspective. For many organisations, the confidentiality value of most data decreases rapidly. Marketing plans, operational communications, routine correspondence and transactional data typically lose sensitivity within months or a small number of years. If the value of your data degrades well before a quantum computer is likely to exist, HNDL may be a manageable risk compared with more immediate threats.

This distinction matters because the security landscape is not short of competing priorities. Ransomware, supply chain compromise, insider threat, identity-based attacks and cloud misconfiguration all present clear and present risks demanding investment today. A CISO who redirects significant budget towards a quantum decryption scenario at the expense of these is not necessarily making a risk-informed decision.

The key is proportionality. HNDL should be assessed alongside other risks, not in isolation, and the response calibrated to the specific data sensitivity and threat profile of your organisation rather than driven by generic urgency messaging. We have written separately on why PQC must not repeat the mistakes of previous hype cycles.

Using Mosca's framework to assess your risk

One of the most useful tools for assessing exposure is Mosca's quantum risk framework, referenced by many national cybersecurity agencies and standards bodies. It balances three variables:

  • X — how long your data or trust assertions need to remain secure.
  • Y — how long migration to quantum-resistant algorithms will take you.
  • Z — the time until a cryptographically relevant quantum computer exists.

If X plus Y exceeds Z, your data is at risk of being compromised before you can protect it. That is precisely the scenario HNDL exploits.

The framework's value is that it shifts attention away from the one variable nobody can control. Estimates for Z vary from under a decade to several decades, and arguing about it is unproductive. X and Y are both things you can measure, and Y in particular is usually far longer than organisations expect — migration across a large estate is a multi-year programme, not a project.

The NIST PQC roadmap provides concrete deadlines to calibrate against: deprecation of RSA and ECC from 2030, with the intention of disallowing them by 2035.

The key questions for boards

Rather than treating HNDL as a blanket emergency, frame it as a structured risk management conversation. Three questions are central.

First, which of your data remains sensitive for 10, 20 or more years? This requires a clear understanding of data classification, retention requirements and the business impact of long-term exposure. For some organisations that insight already exists within information governance frameworks; for others, developing it is a necessary first step.

Second, could that data realistically be harvested by nation-state or highly capable adversaries today? This is a question about your threat model, not your technology stack. Organisations operating in sectors of national importance, handling classified or commercially sensitive information, or maintaining extensive digital supply chains are more likely to be targets of collection activity.

Third, do you have plans to protect those data flows with quantum-resistant controls? This does not necessarily mean implementing new algorithms immediately. It means having visibility of where your most sensitive data flows, understanding which mechanisms protect it, and developing a roadmap for transitioning those protections.

Answering all three depends on having visibility of your cryptographic estate. A cryptographic bill of materials maps where vulnerable algorithms protect sensitive data flows, giving CISOs the evidence base to assess exposure specifically rather than in the abstract. Our guide to building a cryptographic inventory covers where to start.

How should organisations prepare for HNDL?

A proportionate response has five stages. None of them require significant capital spend to begin.

1. Classify by confidentiality lifespan, not by sensitivity label

Existing classification schemes tell you how sensitive data is now. HNDL requires knowing how long it stays sensitive. Add a retention-of-confidentiality dimension to your classification: does this matter in five years, ten, thirty? Most organisations find the genuinely long-lived category is much smaller than expected, which makes the rest of the work tractable.

2. Build the cryptographic inventory

Identify which algorithms, key lengths and protocols protect those flows. This is the foundation for everything that follows, and it is the step organisations most often skip in favour of buying something. Without it you cannot scope the work, price it, or demonstrate progress.

3. Map the data flows

Where does long-lived sensitive data actually cross a network, and what protects it at each hop? Include third-party integrations and anything routed through infrastructure you do not control. This produces the shortlist of connections that matter.

4. Prioritise hybrid key exchange where it is available

Hybrid key exchange combines a classical algorithm with a post-quantum one, so the session remains secure if either holds. It is already supported in TLS 1.3 implementations and major browsers, and it protects against harvesting today without requiring a full migration. For the highest-value flows identified in step three, this is the most direct mitigation available now.

5. Build crypto-agility into procurement

Every system bought or renewed from this point should be able to change algorithm, key length and certificate profile without redesign. Crypto-agility is what makes the eventual migration a configuration exercise rather than a rebuild, and adding it to requirements costs nothing today.

Our guide to five practical steps to PQC readiness covers the wider programme, and what your technology estate means for readiness addresses the systems that cannot be updated in place.

What CISOs should avoid

Two common mistakes.

Treating it as someone else's problem. Even if the date of quantum capability is uncertain, collection of encrypted data happens today with conventional technology. Deferring assessment on the basis that quantum computers do not yet exist misses the point of the threat entirely.

Urgency-driven procurement. The opposite failure. Purchasing quantum-resistant products without first understanding where sensitive data resides, how it moves and which flows are exposed is unlikely to deliver meaningful risk reduction. It repeats the pattern of previous technology cycles, where procurement preceded strategy.

The appropriate response sits between these extremes: a deliberate, risk-informed assessment identifying where HNDL poses a genuine threat, and a proportionate, phased plan to address it.

HNDL in the context of broader PQC readiness

HNDL is only one dimension of the post-quantum challenge. Its counterpart, Trust Now, Forge Later, addresses the future risk to digital signatures rather than data confidentiality, and in many respects poses a more systemic threat. A comprehensive approach should assess both in parallel, alongside the organisational and architectural changes needed for lasting cryptographic agility.

HNDL is, however, a useful starting point for board-level engagement because it is conceptually straightforward and directly linked to data protection — something most senior leaders already understand. Using it as a gateway to the broader conversation helps build the awareness and executive sponsorship a full programme requires. We have set out why post-quantum cryptography is a business transformation rather than an algorithm swap separately.

How Unsung can help

We work with CISOs and security leaders to assess HNDL exposure as part of broader post-quantum readiness planning. We help organisations identify where long-lived sensitive data resides, map how it flows through business systems, assess the realism of collection threats, and determine where quantum-resistant controls should be prioritised.

We approach this as a risk conversation rather than a technology conversation. Our vendor-neutral position means we are not incentivised to create urgency or recommend products. The focus is a clear, proportionate understanding of your exposure and a practical roadmap for addressing it — one that sits alongside your existing security priorities rather than displacing them.

Our PKI consultancy team helps translate HNDL risk assessments into phased migration plans. A PKI health check or cryptographic bill of materials is usually the right place to start, because both produce the evidence base every subsequent decision depends on.

Talk to our team to discuss your exposure.

Frequently Asked Questions

What is a harvest now, decrypt later attack?

Harvest now, decrypt later (HNDL) is an adversarial strategy in which encrypted data is intercepted and stored today, in the expectation that it can be decrypted in the future once a cryptographically relevant quantum computer becomes available. Adversaries collect encrypted network traffic at low cost, storing it until quantum computers can break current public-key encryption.

Which organisations face the highest HNDL risk?

Organisations in defense, government, healthcare, finance, and critical infrastructure face elevated exposure because their data sensitivity persists for decades. This includes classified information, patient records, intellectual property, and regulatory data that must remain confidential for extended periods.

How should CISOs assess HNDL risk?

CISOs should use Mosca's quantum risk framework, which balances three factors: timeline to quantum computing capability, system migration duration, and how long data must remain secure. This structured approach helps organisations identify genuine exposure rather than relying on vendor timelines.

What mistakes should CISOs avoid regarding HNDL?

CISOs should avoid two errors: dismissing HNDL as a future problem and making panic-driven technology purchases without understanding their data landscape first. Instead, organisations should conduct deliberate risk assessments identifying sensitive data flows and developing phased migration plans aligned with existing security priorities.

What does HNDL stand for?

HNDL stands for Harvest Now, Decrypt Later. It describes the practice of intercepting and storing encrypted data today in order to decrypt it in future, once quantum computing makes current public-key cryptography breakable. The same threat is sometimes called store now, decrypt later or collect now, decrypt later.

Is Harvest Now, Decrypt Later actually happening?

National cybersecurity agencies in several countries have publicly stated that collection activity is likely already under way. Intercepting and storing encrypted traffic requires no special future capability — it can be done today with conventional technology and cheap storage. What remains unknown is the scale and which targets are prioritised.

Which encryption is vulnerable to HNDL?

The exposure is in key exchange rather than bulk encryption. RSA and elliptic curve cryptography, used to negotiate session keys, would be broken by a sufficiently capable quantum computer running Shor's algorithm. Symmetric encryption such as AES-256 is far less affected, retaining 128 bits of security against Grover's algorithm, which remains infeasible to attack.

How urgent is HNDL for my organisation?

It depends entirely on how long your data needs to stay confidential. Mosca's framework gives the test: if the time your data must remain secure, plus the time your migration will take, exceeds the time until quantum computers become cryptographically relevant, you are exposed. For organisations whose data loses value within a few years, HNDL is a lower priority than immediate threats such as ransomware.

What can I do about HNDL now, before post-quantum migration?

Three things, none of which require significant spend. Classify data by how long it must remain confidential. Build a cryptographic inventory so you know which algorithms protect which flows. Enable hybrid key exchange, which combines classical and post-quantum algorithms, on your highest-value connections where the option already exists in TLS 1.3.

What data is most at risk from HNDL?

Anything with a long confidentiality requirement: classified government information, health records, intellectual property, critical infrastructure operational data, long-running legal matters and financial records subject to extended retention. The common factor is that the data still matters in ten to thirty years.

Does HNDL affect data at rest or data in transit?

Primarily data in transit, because that is what an adversary can intercept passively. Data at rest is at risk where it is exfiltrated or where backups and replication traffic cross a network. Prioritising VPN, site-to-site links, external API integrations and backup replication is usually the right starting point.

What is the difference between HNDL and Trust Now, Forge Later?

HNDL threatens confidentiality: encrypted data captured today, decrypted later. Trust Now, Forge Later threatens authenticity: signatures and certificates trusted today could be forged once the underlying algorithms are broken, allowing an adversary to impersonate a trusted identity retrospectively. Both need assessing, and the second is arguably the more systemic of the two.

Want to explore this topic further?

This blog is part of a series drawn from our strategic whitepaper, Post-Quantum Cryptography: A Strategic Whitepaper for the C-Suite. It provides vendor-neutral, business-focused guidance on navigating the quantum era — covering the threats already in play, lessons from previous hype cycles, and practical steps your organisation can take today. Download your copy here: https://2f4v3l.share-eu1.hsforms.com/20qJjHSynQkuJKhI_xq9Msg

Author
Unsung Limited
September 11, 2026
-
10 minute read