Long-Lived Data and Quantum Risk: What to Protect First

The harvest-now-decrypt-later threat is not a theoretical construct. State-level adversaries are passively collecting encrypted traffic today under the assumption that a cryptographically relevant quantum computer (CRQC) capable of breaking 2048-bit RSA will be available within the decade. The NSA confirmed this picture in its 2021 Quantum Computing and PQC FAQs: the collection is ongoing, the decryption is deferred, and the only uncertainty is the timeline for when the deferred step becomes executable.

The question that follows from that is practical, not philosophical: which of your organisation's data holdings does the HNDL threat actually reach? Not all data needs migrating at the same urgency. The organisation that treats its entire cryptographic estate as equally at risk will misallocate resources and miss the genuine priority items. The organisation that applies a systematic framework to the question will be able to tell its board which data is exposed, why, and what the migration cost looks like, in time to do something about it.

This article provides that framework. It draws on the Mosca inequality as the formal prioritisation basis and applies it to specific data categories with specific confidentiality lifetimes and migration complexity estimates. For the underlying HNDL exposure analysis by data type, see which data is most at risk from HNDL today.

Why HNDL Forces a Triage Decision Now

The Mosca inequality provides the mathematical grounding. If X is the time remaining before a CRQC capable of breaking current public-key cryptography exists, Y is the time required for an organisation to complete migration of a system or data type to quantum-safe cryptography, and Z is the period during which the data must remain confidential, the organisation is already exposed wherever Y + Z exceeds X.

Current central estimates for CRQC availability cluster around 2033 to 2035 for a device capable of breaking 2048-bit RSA. This is not a guarantee. Technical progress could accelerate or stall. But NIST has not based its deprecation schedule on optimism: NIST IR 8547 (November 2024) sets 2030 as the cutoff for new deployments of RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman in US federal systems, and 2035 as the full-retirement date. Those milestones are the engineering planning horizon for any organisation using NIST-compatible standards, regardless of US jurisdiction.

Plug numbers into the inequality. A CRQC arriving in 2033 means X is currently about 7 years. An organisation with a complex cryptographic estate whose full migration will take 5 years (Y = 5) faces a simple arithmetic problem for any data with a confidentiality requirement extending beyond 2026 (Z greater than roughly 1 year). That encompasses most genuinely sensitive data categories. The only organisation not already inside the Mosca threshold is one with either trivially short-lived data or a trivially fast migration path.

The Two Dimensions: Confidentiality Lifetime and Migration Complexity

Effective prioritisation requires assessing two independent dimensions for every data holding and cryptographic system.

Confidentiality lifetime (Z) is not the same as the data retention period. Retention tells you how long the organisation keeps the data; confidentiality lifetime tells you how long the data needs to remain secret. A patient genomic record might be retained for 8 to 30 years (per the NHS Record Management Code of Practice 2021), but its confidentiality requirement extends for the patient's lifetime and potentially beyond. A corporate M&A document might be retained for 6 years under Companies Act 2006 (s.388, private companies) or 7 years for HMRC tax records (a separate obligation), but the confidentiality of the transaction terms might be commercially sensitive for decades. The Mosca inequality requires the confidentiality lifetime (not the retention period) to be the input for Z.

Migration complexity (Y) varies by orders of magnitude across cryptographic assets. Deploying X25519+ML-KEM-768 hybrid key exchange on a well-maintained TLS termination point takes weeks to months once the CBOM has identified the asset. Replacing an HSM across a distributed key management infrastructure takes 12 to 36 months. Rebuilding a PKI hierarchy with re-signing of long-term certificates takes 18 to 48 months. Migrating embedded proprietary cryptography in operational technology hardware (where there is no over-the-air update path and device replacement cycles are set by vendor roadmaps) takes 3 to 10 years. NIST NCCoE SP 1800-38B provides the reference complexity taxonomy.

These two dimensions create four priority zones. The combination of high confidentiality lifetime and high migration complexity is Priority 1: the organisation is already behind. High confidentiality lifetime with low migration complexity is Priority 2: the data is genuinely at risk, but the migration is achievable quickly. Low confidentiality lifetime with high migration complexity is Priority 3: the migration is slow, so it needs planning now even though the data risk is lower. Low confidentiality lifetime with low migration complexity is Priority 4: act last.

An organisation that only asks "is this data sensitive?" without separately asking "how long must it stay secret and how hard is the migration?" will consistently misprioritise. Those are not the same question.

Priority 1: Act Now

These data categories have confidentiality requirements that extend well beyond the Q-Day probability window, combined with migration complexity that means years of lead time are required.

Personal genomic and health data. Under GDPR Article 9, genetic and biometric data are special category data requiring a higher standard of protection. NHS retention requirements under the Code of Practice 2021 range from 8 to 30 years depending on record type; genetic data is effectively lifelong in its confidentiality requirement. Any organisation holding health genomic data under RSA or ECDH key management has a priority exposure that no other category exceeds on the Z dimension.

Long-term financial contracts. Derivatives with 20- to 30-year tenors, structured products, and counterparty position data all require confidentiality throughout the contract period. An interest rate swap entered today matures in the early 2050s; the counterparty identity and terms remain commercially sensitive throughout. MiFID II Article 16 requires retention of transaction records for at least 7 years; the confidentiality requirement for the underlying terms extends far beyond the retention period. [ASSUMED: MiFID II 7-year figure applies to the specific transaction categories described; verify Article 16 scope against the RTS on record-keeping before citing in regulated-entity compliance documentation.]

Legal filings with long-term effect. Patent applications, M&A documentation, long-duration contracts, court documents under seal, and corporate IP filings have confidentiality periods that track the duration of the legal effect, which for a patent granted today can be until 2046.

PKI root certificate infrastructure. Root CA private keys are typically valid for 20 to 25 years. A root CA whose private key is protected with RSA-4096 and whose key material is archived under RSA key wrapping has a quantum vulnerability that, if exploited after a CRQC exists, would undermine the validity of every certificate in its trust chain. PKI root migration requires the highest priority classification because the migration complexity (hierarchy rebuild, relying party update cycles, browser and OS trust store updates) is among the most complex in any organisation's cryptographic estate.

Priority 2: Act Soon (Quick Wins on High-Risk Data)

These data types have long confidentiality requirements, but the cryptographic migration path is operationally straightforward. Priority 2 items are the quick wins: they address genuine HNDL exposure without requiring hardware replacement or multi-year programmes.

TLS-protected data flows carrying sensitive long-lived data fall here where the application data has a long confidentiality requirement but the transport layer sits on modern, maintained infrastructure. Deploying X25519+ML-KEM-768 hybrid key exchange (per IETF draft-ietf-tls-hybrid-design, using ML-KEM as specified in NIST FIPS 203) on those endpoints is an operational change achievable in weeks to months. It provides immediate HNDL protection for future traffic without requiring changes to the application or data layer.

Encrypted email carrying long-lived sensitive communications (legal privilege correspondence, healthcare communications, sensitive financial advisory) is another Priority 2 candidate. S/MIME and PGP implementations can be migrated at the client level. For organisations using enterprise email encryption gateways, the migration is a gateway configuration change, not an infrastructure rebuild.

Cloud storage of sensitive archives is a third Priority 2 category. Re-encryption of cloud-stored data under ML-KEM-wrapped keys is operationally achievable on most major cloud platforms in 2026 without hardware replacement. The key management layer (specifically replacing RSA or ECDH key wrapping with ML-KEM-wrapped AES keys) is the migration target.

Priority 3 and 4: Plan Early, Execute Later

Priority 3 covers data with low confidentiality lifetime but high migration complexity. Operational technology and SCADA system telemetry is the canonical example. Manufacturing process data, energy grid sensor readings, and traffic management data typically have operational relevance measured in hours to days; the HNDL risk for the data itself is low. But the migration complexity for OT systems can be 5 to 10 years: embedded cryptography in PLCs, long hardware replacement cycles, vendor roadmap dependencies, and operational downtime constraints. The IEC 62443-3-2:2020 security risk assessment framework provides the reference methodology for OT cryptographic risk classification. The practical implication: even though the data risk is low, OT migration planning must start now because the implementation lead time is long.

Priority 4 covers consumer-facing web application session data and internal development and test environments. Short session lifetimes, high infrastructure deployment agility, and low data confidentiality requirements place these at the bottom of the priority stack. Migrate them, but direct resources toward Priority 1 and 2 first.

What AES-256 Does and Does Not Protect

A section on what does not need priority migration is as important as the sections on what does. AES-256 symmetric encryption for data at rest is not a Priority 1 migration item, and overclaiming quantum vulnerability damages the credibility of the entire migration case.

Grover's algorithm provides a quadratic speedup against symmetric key search, reducing AES-256 effective security from 256 bits to approximately 128 bits under a CRQC. A 128-bit security margin is considered computationally secure for any foreseeable adversary, including a quantum one. NIST SP 800-57 Part 1 Rev. 5 confirms AES-256 as appropriate for long-term security at the post-quantum security level. Data encrypted at rest under AES-256-GCM or AES-256-CBC does not require re-encryption from a quantum threat perspective.

The quantum vulnerability in at-rest data is in the key management layer, not the AES ciphertext. If the AES key is wrapped under RSA or ECDH key exchange (as is standard in most enterprise key management systems) an HNDL adversary who captured the key exchange event can recover the AES key and therefore decrypt the stored data, even though the AES layer itself is quantum-safe. Priority for at-rest data is the key wrapping and key transport mechanisms, not the AES encryption itself.

Hash functions above SHA-256 also survive the quantum threat with adequate margin. Grover's algorithm reduces SHA-256 preimage resistance from 256 bits to 128 bits (computationally secure). SHA-384 and SHA-512 provide further margin. If any active system still uses SHA-1 or MD5, treat that as a pre-existing classical vulnerability to remediate urgently, not because of quantum but because those hash functions have had known classical weaknesses for years.

Building Your CBOM as the Priority Map

The priority framework described above is only operationally useful when there is a cryptographic bill of materials (CBOM) to apply it to. A CBOM is a structured inventory of every cryptographic asset in the organisation (algorithm, key size, protocol, certificate, library) mapped to the systems and data it protects, with a confidentiality lifetime estimate and a migration complexity rating for each entry. It is the instrument that converts the two-dimension priority matrix from a conceptual tool into a ranked project list.

NIST NCCoE SP 1800-38B provides the reference methodology and effort templates. ETSI TR 103 619 addresses migration considerations from the European standards perspective. Discovery tooling for CBOM construction has matured substantially: the Open Quantum Safe project provides open-source tools for cryptographic library identification; commercial code scanning tools identify algorithm usage in software; network traffic analysis identifies TLS cipher suites across the estate. The technical challenge is not the inventory concept but the organisational scope; large enterprises have cryptographic assets across hundreds of applications, multiple cloud accounts, OT environments, and supply chain connections.

The practical approach: scope the CBOM to Priority 1 and Priority 2 data types first. Full enterprise coverage is the eventual target; Priority 1 and 2 data first is the operationally sound starting point. Starting a complete enterprise CBOM on everything simultaneously typically stalls before it delivers any output. Starting with the highest-risk data types produces a ranked action list within months, not years. For the full methodological framework, see the HNDL risk assessment framework.

Regulatory Drivers by Data Category

Regulatory frameworks reinforce the priority structure derived from the Mosca inequality, they do not replace it. The regulatory argument is supporting evidence for the migration case; the risk analysis is the primary argument.

GDPR Article 5(1)(e) requires personal data not to be kept longer than necessary, but Article 9 special category data (health, biometric, genetic) has longer legitimate retention under medical and public interest exceptions. Any long-retained personal data under RSA or ECDH key management is Priority 1 territory. The "appropriate technical measures" obligation in GDPR Article 32, interpreted against the "state of the art" standard, is moving as NIST FIPS 203/204/205 become the published baseline for post-quantum cryptography. [INFERRED: supervisory authorities have not issued formal guidance confirming FIPS 203/204/205 as the Article 32 state-of-the-art threshold; this is a logical inference from the GDPR's dynamic standard and the standards' publication status.]

DORA (Regulation (EU) 2022/2554) requires EU financial entities to implement cryptographic controls sufficient to address ICT risks under Article 9. For financial data with long confidentiality requirements (counterparty identity on long-tenor derivatives, positions and terms under multi-year structured products) the HNDL risk is a DORA ICT risk item that belongs in the Article 6 ICT risk management framework.

For organisations supplying US national security system customers, CNSA 2.0 (NSA Commercial National Security Algorithm Suite 2.0) mandates ML-KEM-1024 and ML-DSA-87 for NSS data. This is the highest-tier benchmark: ML-KEM-1024 (the largest ML-KEM parameter set) rather than the enterprise standard of ML-KEM-768. The CNSA 2.0 parameter set requirements apply to national security contexts; they are not the general recommendation for organisations outside that scope, where ML-KEM-768 is the current standard recommendation.

The regulatory frameworks provide the compliance case. The Mosca inequality and the confidentiality lifetime analysis provide the risk case. Both point to the same priority order.