HNDL Risk Assessment Framework for Enterprise Security Teams

The Harvest Now, Decrypt Later attack is not a theoretical concern for 2033. The interception is happening now. State-level adversaries are collecting encrypted traffic today with the intention of decrypting it retrospectively once a cryptographically relevant quantum computer arrives. The 2033 to 2035 Q-Day window (Mosca, IEEE Security and Privacy, 2018) means data with a long confidentiality requirement that is transmitted today over RSA or ECDH-protected channels has a defined risk horizon.

Standard enterprise risk frameworks are not designed for this. They assess current control effectiveness against current threat capability. HNDL requires something different: assessing a future threat capability against data whose confidentiality value at that future point depends on decisions made today. This article provides a five-component operational framework for conducting that assessment. It is a practitioner tool, not a regulatory requirement. The scoring model is synthesised from risk management methodology and should be labelled as practitioner guidance in any formal documentation.

Why HNDL Requires Its Own Risk Framework

Conventional cryptographic risk assessment asks: "Is this system currently vulnerable?" HNDL risk assessment asks a different question: "Will data captured from this system today be valuable and decryptable when Q-Day arrives?" Those are structurally different questions that require different analytical tools.

The formal framing is the Mosca inequality: if the time to quantum threat is less than the time to migrate plus the time to deploy, the organisation has a problem. Applied to HNDL specifically: if any dataset has a confidentiality requirement that extends beyond Q-Day, and that dataset is transmitted or accessible over classical asymmetric cryptography, the HNDL risk is material today, not at some future assessment date. The ETSI GR QSC 001 framework for quantum-safe cryptography (2016) formalised the HNDL threat model as the primary near-term practical risk from quantum computing, before the hardware exists to realise the threat, the collection infrastructure is already in operation.

The five-component framework below produces three outputs: a prioritised data asset register with HNDL risk scores; a transmission exposure map showing which network segments and third-party connections carry high-risk data; and a migration priority list feeding the organisation's PQC migration roadmap. Each component addresses a distinct dimension of the risk.

Component 1: Data Taxonomy for HNDL Assessment

Begin with a data taxonomy that classifies all data assets by four dimensions: sensitivity category, confidentiality lifetime, transmission method, and current encryption scheme. This extends the organisation's existing data classification programme rather than replacing it. Most data classification schemes address current sensitivity. HNDL assessment additionally requires confidentiality lifetime (how long must this data remain confidential?) and transmission method (how is it transmitted, and what cryptographic scheme protects it?).

Standard data classification tiers (Public / Internal / Confidential / Restricted) do not map cleanly to HNDL risk because they measure current sensitivity, not adversarial value at Q-Day. A practical HNDL taxonomy uses four sensitivity categories that reflect what decrypted data would mean to an adversary in 2033 to 2035:

  • Operationally sensitive: data whose disclosure causes immediate operational harm at decryption time (control system configurations, operational plans, personnel locations in high-risk contexts).
  • Strategically sensitive: data whose disclosure enables long-term adversarial advantage (trade secrets, IP with long commercial value, defence procurement data, research findings).
  • Compliance-bound: data subject to regulatory retention and confidentiality obligations extending beyond Q-Day (financial records with multi-decade legal hold obligations, health records, genomic data).
  • Commercial: data with commercial sensitivity whose value may be diminished but not zero at Q-Day (pricing strategy, contract terms, customer data).

Confidentiality lifetime is the most operationally important dimension. Rough reference points by data type: payment transaction data typically carries a one-to-five year confidentiality lifetime and low HNDL risk unless the transaction is strategically significant. Trade secrets and intellectual property carry indefinite or very long confidentiality lifetimes and high HNDL risk if the adversary model includes state actors or well-resourced competitors. National security and defence data may require confidentiality for decades and carries the highest HNDL risk. Health data confidentiality lifetime is governed by regulation but often runs to long retention for genomic, diagnostic, and long-term care records.

For a sector-by-sector breakdown of which specific data types carry the highest HNDL risk scores, the companion analysis at /insights/which-data-most-at-risk-hndl-today/ provides the adversarial value scoring guidance by industry.

Component 2: Transmission and Interception Risk

A dataset with a long confidentiality lifetime is not automatically at HNDL risk. Data that is never transmitted over a network and stored on an air-gapped system cannot be intercepted for HNDL collection. The HNDL threat is a function of both data sensitivity and transmission exposure. Component 2 assesses whether each data asset in the taxonomy is actually exposed to interception.

The transmission risk assessment examines: whether the data traverses public internet or semi-trusted network segments; whether it is transmitted to cloud services or third-party systems where the organisation does not control the network path; and whether historical transmissions may have been captured (data transmitted over the past three to five years over classical TLS is already in adversary collections if it was targeted).

State-level adversaries are the primary HNDL threat actors. The infrastructure required for large-scale, long-term ciphertext collection is beyond the capability of most non-state actors. This does not mean HNDL risk is confined to government and military organisations: any enterprise that transmits data of strategic value to state actors is a potential target. The sectors with the highest realistic HNDL exposure include defence supply chain, critical infrastructure, pharmaceutical research, advanced semiconductor and materials technology, and financial institutions carrying long-lifetime regulatory records. Private enterprises in these sectors should model themselves as credible targets for state-level collection. The NSA/CSS CNSA 2.0 advisory and NIST IR 8547 both implicitly reflect this threat model in their urgency framing.

Component 3: Cryptographic Exposure Assessment

For each data asset in the taxonomy, map the current cryptographic scheme. The assessment identifies: TLS version and key exchange algorithm for data in transit; symmetric cipher and key management for data at rest; and whether the asymmetric schemes used are vulnerable to Shor's algorithm.

Schemes vulnerable to Shor's algorithm cover the large majority of currently deployed asymmetric cryptography: RSA (all key sizes), ECDH (all curves: P-256, P-384, X25519), ECDSA (all curves), and DSA. These account for virtually all deployed TLS 1.2 and TLS 1.3 key exchange and authentication in enterprise environments.

For symmetric encryption, the question is different. AES-256 reduces from 256-bit to 128-bit post-quantum security after Grover's algorithm, adequate, and the NIST IR 8547 recommendation. AES-128 reduces to 64-bit post-quantum security, which falls below the NIST IR 8547 threshold. If the cryptographic inventory finds AES-128 in active use on high-sensitivity data paths, that is an additional remediation item. Flag it in the CBOM. Many enterprises retain AES-128 in legacy contexts where it was deployed before the NIST guidance was current.

The migration targets from NIST IR 8547 are: ML-KEM (FIPS 203) replacing ECDH for key exchange; ML-DSA (FIPS 204) replacing ECDSA and RSA for digital signatures; SLH-DSA (FIPS 205) as a hash-based alternative for long-lived signing; AES-256 as the symmetric cipher standard.

Component 4: HNDL Risk Scoring Model

The scoring model produces a numerical risk score for each data asset. It uses three dimensions scored on a 1-to-5 scale.

Adversarial value score (1-5): How valuable is this data to an adversary at Q-Day? Score 1 for data with negligible value at decryption time (publicly available information, expired temporary session data). Score 5 for data with existential or strategic value (national security communications, long-lived trade secrets with competitive or geopolitical implications, critical infrastructure configurations).

Confidentiality lifetime score (1-5): How long must this data remain confidential? Score 1 for a lifetime under five years. Score 5 for an indefinite confidentiality requirement or one exceeding twenty years.

Transmission exposure score (1-5): How frequently and through how many network segments is this data transmitted? Score 1 for data on air-gapped or fully internal LAN-only systems. Score 5 for data transmitted regularly over public internet to multiple third parties.

The HNDL risk score is calculated as: adversarial value multiplied by the minimum of (confidentiality lifetime score, transmission exposure score). The multiplicative-minimum formulation reflects a structural property of the threat: a dataset with an indefinite confidentiality requirement but zero transmission exposure has a low HNDL risk score, because unexposed data cannot be harvested. Conversely, a dataset with high transmission exposure but very short confidentiality lifetime also scores low, the data will have no value to the adversary by Q-Day even if it is collected today.

Score interpretation: 1 to 4 = low HNDL risk (monitor and include in migration planning); 5 to 9 = moderate (begin migration planning, assess whether hybrid TLS can be deployed on this data path); 10 to 16 = high (expedite migration, consider immediate mitigations in parallel); 17 to 25 = critical (immediate action, assess data minimisation, re-encryption, and transmission restriction alongside migration).

The scoring model connects directly to the PQC migration roadmap. Data assets with critical and high HNDL risk scores identify the TLS sessions that carry them, the KMS infrastructure that protects them, and the storage systems that hold them, these are the first migration queue items.

Component 5: Mitigation Options by Risk Score

Mitigation options exist on a spectrum from immediate to long-term. For high and critical scoring data assets, five options are available in order of feasibility and lead time.

Data minimisation: Stop collecting or transmitting the data if it is not operationally essential. This is the highest-impact mitigation and rarely feasible for core operational data. For legacy data that is retained beyond its operational need, it is worth reviewing.

Transmission restriction: Reduce transmission frequency and scope. Move to point-to-point channels with tighter access controls. This reduces the transmission exposure score for the next assessment cycle.

Symmetric re-encryption at rest: Re-encrypt stored data with AES-256 under freshly generated keys. This eliminates retrospective decryption risk for stored copies, an adversary who has collected old ciphertext encrypted under AES-128 can be denied that exposure by re-encrypting under AES-256. This does not address in-transit HNDL.

Hybrid TLS migration: Deploy hybrid key exchange using X25519+ML-KEM on TLS sessions carrying high-risk data. This is the highest-impact immediately actionable mitigation for in-transit exposure. In practice, enabling hybrid TLS at a load balancer, CDN, or service mesh control plane requires only configuration changes in many environments, no endpoint changes. An organisation can reduce HNDL risk on its external-facing high-risk data paths within weeks. Cloudflare, AWS, nginx, and OpenSSL had production or near-production support for hybrid TLS as of 2025; verify current support for X25519MLKEM768 (the standardised NIST form, not the pre-standardisation X25519Kyber768 label) before deploying. [ASSUMED, verify production deployment status for X25519MLKEM768 specifically before publication.]

Full ML-KEM migration: Replace all asymmetric key exchange on high-risk data paths with FIPS 203 ML-KEM. This is the full migration goal, not an immediate mitigation. The hybrid deployment in option 4 provides protection while the full migration is under way.

Operationalising the Framework: Three Outputs

The assessment produces three outputs that feed directly into an organisation's PQC migration programme.

First: a prioritised data asset register with HNDL risk scores. This is the working document for migration sequencing. Critical and high-scoring assets are the first migration queue items; moderate-scoring assets are the second wave; low-scoring assets enter standard migration planning cycles without urgency escalation.

Second: a transmission exposure map showing which network segments, cloud connections, and third-party data exchange paths carry high-risk data. This map identifies where hybrid TLS deployment will have the most impact and which third-party service provider relationships require a PQC roadmap assessment.

Third: a migration priority list feeding the PQC migration programme. The connection from HNDL risk score to migration action is direct: if a data asset scores 17 to 25, the TLS sessions and key management systems that carry it move to the top of the migration queue regardless of system complexity.

The framework does not require a mature data classification programme as a prerequisite. A first pass can be built in a workshop format: structured questionnaires to security and business stakeholders, asking which data categories they handle, how long that data must remain confidential, and whether it is transmitted externally. A workshop of three to four hours typically produces a first-pass risk register sufficient to identify critical and high-risk assets and begin migration prioritisation. Refinement comes in subsequent assessment cycles as the CBOM matures.

For organisations subject to NIST IR 8547 transition requirements, PCI DSS, DORA, NIS2, or NCSC guidance, the HNDL assessment framework is the data-layer input to the broader PQC migration programme. Compliance frameworks establish obligations and timelines. They do not answer the operational question "which data do we protect first?" at the asset level. This framework answers that question.

Sources