Quick answer: Harvest now, decrypt later risk is quantifiable with a simple model: if a data asset’s required confidentiality period extends past the point when your migration will actually be complete, plus a margin for quantum threat timeline uncertainty, that asset is exposed. The model needs six inputs: confidentiality period (how long the data must stay secret), migration duration (how long your organization realistically needs to protect this specific asset), threat horizon (the range of credible estimates for when a cryptographically relevant quantum computer arrives), data value (what it’s worth to an adversary), exposure (how likely it is to be harvested today), and compensating controls (anything already reducing risk independent of the algorithm itself). This guide walks through the formula and a worked example.
HNDL risk gets described qualitatively so often, “some of your data might be exposed someday”, that it rarely drives a specific decision. A simple, honest quantitative model, even a rough one, turns it into something that can actually rank one data asset against another and justify a migration sequence.
Key Takeaways
- An asset is genuinely HNDL-exposed when its required confidentiality period extends past your realistic migration completion date, with margin for quantum timeline uncertainty.
- The model needs six inputs: confidentiality period, migration duration, threat horizon, data value, exposure, and compensating controls, not confidentiality period alone.
- Threat horizon should be expressed as a range reflecting genuine expert disagreement, not a single point estimate, since no credible source claims certainty on quantum computing timelines.
- Compensating controls, like data minimization or scheduled deletion, can move an asset out of the exposed category without an algorithm change at all.
The Six Inputs
- Confidentiality period: how many years this specific data asset needs to remain secret, driven by regulatory retention requirements, contractual terms, or the inherent nature of the data (a trade secret’s confidentiality period may be indefinite; a quarterly earnings figure’s may be months).
- Migration duration: your organization’s realistic, evidence-based estimate for when this specific asset’s protecting cryptography will actually be migrated to PQC, based on your actual roadmap, not an aspirational date.
- Threat horizon: the range of credible expert estimates for when a cryptographically relevant quantum computer might exist, expressed as a range (commonly cited estimates span roughly 2030 to 2040-plus, with genuine expert disagreement, not a single confident date), not a point estimate.
- Data value: a relative assessment of what this data would be worth to an adversary capable of decrypting it, high for trade secrets, health records, or long-term strategic communications, low for routine operational data with no lasting sensitivity.
- Exposure: how likely the encrypted data actually is to be harvested today, higher for data traversing public networks or stored in less controlled environments, lower for data that never leaves a tightly controlled internal system.
- Compensating controls: anything already reducing risk independent of the algorithm itself, data minimization, scheduled deletion before the confidentiality period would otherwise expire, or additional access controls that reduce harvest likelihood.
The Basic Exposure Test
At its simplest, an asset is HNDL-exposed if:
Confidentiality period end date > earliest point in the threat horizon range, and the asset’s migration completion date falls after that same earliest threat horizon point.
In plain terms: if data needs to stay secret past the point where a quantum computer might plausibly exist, and your migration won’t have protected it by then, it’s exposed under this model regardless of how far off the later end of the threat horizon range might be. Using the earliest credible date in the range, not the average or the latest, is the conservative, defensible choice for prioritization purposes.
A Worked Example
| Input | Asset A: Patient genomic records | Asset B: Quarterly sales figures |
|---|---|---|
| Confidentiality period | Indefinite (family-relevant genetic data) | ~2 years (competitive sensitivity window) |
| Migration completion (realistic) | 2028 (per current roadmap) | 2028 (same roadmap) |
| Threat horizon (earliest credible) | ~2030 | ~2030 |
| Data value to adversary | High | Low to moderate |
| Exposure (network path) | Moderate (internal systems, some external transmission) | Low (internal only) |
| Compensating controls | None currently | Data deleted after 3 years per policy |
| Result | Exposed: confidentiality period vastly exceeds threat horizon | Not exposed: data deleted before threat horizon, even without migration |
This example illustrates why the six-input model outperforms a confidentiality-period-only assessment: Asset B might initially look concerning given a 2-year confidentiality period against a 2030 threat horizon, but its existing deletion policy, a compensating control, actually resolves the exposure independent of any algorithm change. Asset A, by contrast, has no such control and a confidentiality period that makes migration timing directly consequential.
What We’d Actually Recommend
Run this model against your actual highest-value data categories first, not your entire inventory at once, to validate the approach before scaling it. Use the earliest credible date in your threat horizon range for prioritization purposes, since that’s the conservative assumption that actually protects against being wrong. Treat compensating controls as a genuine, first-class input, not an afterthought, since a control like scheduled deletion can resolve exposure for an asset that would otherwise rank as high priority.
How Encryption Consulting Can Help
Running this model at scale depends on knowing your actual data categories, their current confidentiality lifetimes, and existing compensating controls, exactly what CBOM Secure‘s inventory captures alongside the cryptographic details, following the same twelve-field data model covered in our cryptographic inventory data model guide.
Our PQC Advisory Services apply this HNDL exposure model across your actual data inventory, feeding directly into the six-dimension risk prioritization scoring covered in our PQC inventory prioritization guide.
A Rough Number Beats No Number
HNDL risk resists precise quantification, since it depends on a genuinely uncertain future threat timeline, but that uncertainty is not a reason to skip quantification entirely. A simple six-input model, even with conservative, rough estimates for threat horizon and data value, produces a rankable, defensible signal that a purely qualitative “this data feels sensitive” assessment cannot. Using the earliest credible threat date and treating compensating controls as a genuine input, not an afterthought, is what makes the model useful for actually sequencing a migration rather than just describing a vague risk.
Frequently Asked Questions
What date should be used for the quantum threat horizon in this model?
Use the earliest date in the credible expert range for prioritization purposes, commonly cited estimates span roughly 2030 to 2040 and beyond, since that conservative assumption protects against underestimating the risk rather than overestimating it.
Can a compensating control eliminate HNDL exposure without changing the encryption algorithm?
Yes. A control like scheduled data deletion before the confidentiality period would otherwise expire can resolve exposure entirely, since the data no longer exists by the point it would otherwise be at risk, independent of when the algorithm migration happens.
Why does confidentiality period alone not determine HNDL exposure?
Because exposure also depends on migration timing, data value, exposure likelihood, and existing controls. Two assets with identical confidentiality periods can have very different actual risk depending on these other factors, as the worked example in this guide shows.
Should this model be applied to every data asset in an organization at once?
Start with the highest-value data categories to validate the approach before scaling it across a full inventory, since applying an unrefined model at full scale immediately can produce noisy results that are harder to act on.
How precise does the data value input need to be?
A relative assessment, high, moderate, or low, is sufficient for prioritization purposes. The model is meant to rank assets against each other, not produce a precise dollar figure, so consistent relative scoring matters more than false precision.
