How to Calculate Your Organisation's HNDL Exposure

Harvest-now-decrypt-later exposure is not a qualitative concept. It is a calculable risk with three specific inputs. An organisation that knows its network topology, its data retention requirements, and its current key exchange algorithms can produce a scored HNDL exposure assessment for any system in its estate. That score drives migration priority sequencing more reliably than "system criticality" or "perceived sensitivity" — because a genomic research database with RSA-protected API traffic may be lower business priority than the payroll system but carries orders-of-magnitude higher HNDL exposure.

This article explains the calculation methodology, works through three concrete examples, and shows how the score translates to a migration priority queue. The interactive implementation is at the QSECDEF HNDL risk calculator. Use the manual calculation here for more complex or granular scenarios where pre-set category defaults do not capture your specific system profile.

What an HNDL Exposure Calculation Actually Measures

HNDL exposure measures the risk that ciphertext generated today will be decryptable by an adversary when a cryptographically relevant quantum computer (CRQC) becomes available. The formal framework is the Mosca inequality (Mosca, 2018): if the time until a CRQC exists is less than the migration time plus the remaining confidentiality requirement of data already in the harvest window, the organisation has a current problem, not a future one.

The calculation operationalises this as a product of three factors:

• I — Interception exposure: How likely is it that an adversary is currently capturing ciphertext from this system?
• L — Confidentiality lifetime: How many years must this data remain confidential?
• A — Algorithm vulnerability: Is the key exchange protecting this data vulnerable to Shor's algorithm on a CRQC?

HNDL exposure score = I x L x A. Maximum: 27. Minimum: 0 (only achievable if data is post-quantum protected or has negligible confidentiality lifetime).

This is a risk calculation, not a compliance gap analysis. A compliance gap asks whether you are meeting your regulatory cryptography obligations. An HNDL exposure calculation asks which of your data is at material risk of retrospective decryption. An organisation can be technically compliant with current cryptographic standards and still carry a high HNDL score on specific systems — because compliance requires meeting current standards, and current RSA-2048 remains a current standard, yet RSA-2048 is fully vulnerable to Shor's algorithm on a CRQC.

For the comprehensive HNDL risk framework that underpins this calculation, see the HNDL risk assessment framework.

Factor 1: Interception Exposure

Interception exposure is how accessible a system's encrypted traffic is to an adversary operating today. This is not a binary assessment. Internet-facing systems transmitting data over the public internet have high interception exposure because the traffic traverses infrastructure accessible to state-level network collection operations. Systems on private networks that are externally accessible via VPN, cloud connections, or SaaS integrations have medium exposure: the private network does not protect against a compromised network node, BGP hijacking, or supply chain compromise of a network device. Fully air-gapped or offline systems have low but not zero exposure: data can be exfiltrated through other means, and future network changes can alter exposure retrospectively.

Score assignment:

• Score 3 (high): internet-facing services transmitting data over the public internet; cloud service connections; externally accessible APIs.
• Score 2 (medium): private network but externally accessible via VPN, cloud integration, or SaaS; systems known to be of interest to state-level adversaries regardless of network architecture.
• Score 1 (low): fully air-gapped or offline; physical security controls limiting external access.

State-level adversaries conducting HNDL collection operate against specific target categories: government contractors, defence supply chain, financial market infrastructure, critical national infrastructure, and pharmaceutical and life sciences organisations with long-lived intellectual property. ENISA's Threat Landscape 2024 identifies HNDL as an active threat and confirms that state-sponsored collection activity is targeting organisations in these sectors. For the specific data categories most commonly selected for HNDL collection, see which data is most at risk from HNDL today.

Factor 2: Data Confidentiality Lifetime

Confidentiality lifetime is the number of years from today that the data must remain confidential. This is the most operationally important variable in the calculation, and it is the one most commonly underestimated.

The Q-Day planning threshold: data with a confidentiality requirement extending beyond 2033 is in the HNDL exposure zone. That is approximately seven years from 2026. The 2033 date derives from the conservative end of the 2033-2035 planning range in NIST IR 8547 (November 2024) and NSA CNSA 2.0 (September 2022). Using the conservative endpoint is appropriate when the consequences of a wrong estimate are data disclosure rather than unnecessary migration cost.

Confidentiality lifetime varies significantly by data category. Reference points by sector:

• Transaction and payment data: 1-5 years; PCI DSS v4.0 sets a 12-month minimum retention period for cardholder data. [ASSUMED: Kelly must verify the exact PCI DSS v4.0 provision before citing the 1-year minimum.]
• Customer personal data under GDPR: GDPR Article 5(1)(e) sets the storage limitation principle — personal data must be kept no longer than necessary for the purposes for which it is processed. GDPR does not specify a maximum number of years. Specific retention periods are set by sector (e.g. NHS Records Management Code, MiFID II 5-year FCA retention) rather than by GDPR itself.
• Financial regulatory records under MiFID II: 5-7 years (MiFID II Article 25 record-keeping period).
• Legal privilege and litigation hold data: case-dependent, typically 10-30 years.
• Trade secrets and intellectual property: indefinite confidentiality requirement.
• Genomic and long-term health data: 20 to 100+ years depending on regulatory retention obligations and therapeutic research relevance.
• National security and intelligence data: decades.

Score assignment:

• Score 1 (low): confidentiality lifetime under 5 years.
• Score 2 (medium): 5-10 years. This is the most common zone of ambiguity: many organisations underestimate how long operational and commercial data actually needs to remain confidential. Legal advice should be sought on data retention obligations for regulated sectors before assigning lifetime scores.
• Score 3 (high): more than 10 years.

For the specific data categories where long confidentiality lifetimes create the highest HNDL priority exposure, see long-lived data and quantum protection priority.

Factor 3: Algorithm Vulnerability

Algorithm vulnerability assesses whether the key exchange protecting a given system is vulnerable to Shor's algorithm on a CRQC. The classification is straightforward because the affected algorithms are well-defined.

RSA (all key sizes), ECDH (all curve sizes), ECDSA (all curve sizes), classical Diffie-Hellman (all group sizes), and DSA: all are directly broken by Shor's algorithm. NIST IR 8547 (November 2024) formally deprecates all of these. The "all key sizes" point matters: RSA-4096 is not quantum-safe. It requires approximately eight times more quantum resources to break than RSA-2048, but that overhead is within the capacity of any machine large enough to attack RSA-2048 in the first place.

AES-256 (symmetric) is not vulnerable to Shor's algorithm. Grover's algorithm provides a quadratic speedup against symmetric ciphers, which halves the effective bit security: AES-256 delivers approximately 128 bits of quantum security. NIST considers this adequate. The key point for TLS: Shor's algorithm attacks the key exchange mechanism that establishes the AES session key. Hybrid or full PQC key exchange addresses the vulnerability. Replacing AES-256 is not required.

Score assignment:

• Score 3 (high): RSA, ECDH, ECDSA, DH key exchange in use.
• Score 1 (low): hybrid key exchange (X25519+ML-KEM-768 or equivalent) in use. Hybrid provides HNDL protection for all new sessions from deployment. Previously captured sessions remain at risk.
• Score 0 (none): full ML-KEM or AES-256-only symmetric protection; no asymmetric key exchange using classical algorithms.

Calculating Your HNDL Score: The Formula and Worked Examples

HNDL exposure score = I (interception) x L (confidentiality lifetime) x A (algorithm vulnerability). Score range: 0-27.

Interpretation bands:

• 1-6 (low): Limited confidentiality lifetime or already protected. Include in migration plan; not an immediate priority.
• 7-12 (medium): Meaningful exposure. Deploy hybrid key exchange within 12 months.
• 13-18 (high): Significant exposure. Hybrid key exchange should already be deployed. Treat as an immediate action item.
• 19-27 (critical): Data of strategic value protected by classical asymmetric cryptography with long confidentiality requirements. Deploy hybrid immediately. Escalate to board.

Example 1: Healthcare genomic database with external API.

I = 3 (internet-facing API) x L = 3 (genomic data, 50+ year retention requirement) x A = 3 (RSA-2048 key exchange) = 27. Critical. Action: deploy hybrid key exchange on the API immediately. This is the highest-priority system in the estate regardless of its operational business criticality.

Now model the impact of hybrid deployment: I = 3 x L = 3 x A = 1 (hybrid TLS deployed) = 9. Medium. Hybrid deployment alone moves this system from critical to medium-priority. That reduction from 27 to 9 is the return on the most deployable near-term action in the migration programme.

Example 2: Internal financial reporting system, VPN-accessible.

I = 2 (private VPN, externally accessible) x L = 2 (MiFID II 7-year financial record retention) x A = 3 (TLS 1.3 with RSA handshake) = 12. Medium-high. Action: deploy hybrid key exchange; schedule full migration in the next major system update cycle. The 7-year confidentiality window falls into the Q-Day planning zone, but the medium interception exposure reduces the urgency relative to Example 1.

Example 3: Customer-facing e-commerce checkout, daily transaction data.

I = 3 (internet-facing) x L = 1 (payment transaction data, PCI DSS 1-year minimum retention) x A = 3 (RSA-2048) = 9. Medium. Hybrid deployment is recommended but not emergency. The short confidentiality lifetime is the key mitigating factor. This system processes high transaction volumes over the public internet under a classically vulnerable key exchange, but the data itself expires before Q-Day probability becomes material.

The multiplicative model reveals the interaction correctly. A score of 9 appears for systems with very different risk profiles: a hybrid-deployed genomic API (3 x 3 x 1) and a high-volume short-lived payment system (3 x 1 x 3) have the same score but for entirely different reasons. The worked-example breakdown makes those reasons visible, which is why the calculation should be documented per system, not just as an aggregate score.

Using the HNDL Risk Calculator

The QSECDEF HNDL risk calculator implements the I x L x A scoring model interactively. Input: data category, estimated confidentiality lifetime, system network exposure, and current key exchange algorithm. Output: HNDL exposure score, risk band, and recommended immediate actions. Where the calculator's pre-set category defaults do not match a specific system's profile precisely, the manual calculation in this article provides the more granular assessment. [ASSUMED: verify with the development team that the calculator's scoring model matches the I x L x A methodology described here before publication; if the calculator uses a different approach, update this section to reflect the actual calculator methodology.]

Turning HNDL Scores into a Migration Priority Queue

The HNDL exposure score is the primary sequencing input for migration priority. It overrides operational importance. The payroll system may be business-critical; if it has a score of 4, it does not jump the queue ahead of a score-22 research database. NIST NCCoE SP 1800-38B explicitly prioritises migration by data sensitivity and confidentiality lifetime, not by system operational importance alone.

For organisations with more than 50 scored systems, segment the migration queue into four tiers:

• Tier A (score 19-27): Migrate immediately. These are the systems where HNDL collection is already in progress on data that will matter when Q-Day arrives.
• Tier B (score 13-18): Migrate within 12 months. High exposure; hybrid deployment is the interim action while full migration is planned.
• Tier C (score 7-12): Migrate within the NIST IR 8547 Phase 1 window, by 2030.
• Tier D (score 1-6): Migrate in the full migration completion phase, by 2035.

This tiering maps directly to NIST IR 8547's risk-based migration phases. Tier A and B systems are the Phase 1 priority: they carry HNDL exposure that the 2033 Q-Day conservative estimate makes immediate. Tier C systems are Phase 2; Tier D systems are Phase 3. The tiers are not fixed — deploy hybrid key exchange on Tier A systems first, and their algorithm vulnerability score drops from 3 to 1, potentially moving them from Tier A to Tier C. The score is dynamic as migration progresses, which is its value as a tracking instrument.