Harvest Now, Decrypt Later (HNDL): What CISOs Need to Know
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?
Which organisations face the highest HNDL risk?
How should CISOs assess HNDL risk?
What mistakes should CISOs avoid regarding HNDL?
What does HNDL stand for?
Is Harvest Now, Decrypt Later actually happening?
Which encryption is vulnerable to HNDL?
How urgent is HNDL for my organisation?
What can I do about HNDL now, before post-quantum migration?
What data is most at risk from HNDL?
Does HNDL affect data at rest or data in transit?
What is the difference between HNDL and Trust Now, Forge Later?
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


