What Is Harvest-Now, Decrypt-Later?
Harvest-now, decrypt-later (HNDL) is a cryptographic attack strategy in which an adversary intercepts and archives encrypted communications today without immediately decrypting them, intending to decrypt the stored ciphertext in the future when a sufficiently powerful quantum computer becomes available. The attack exploits the gap between when sensitive data is transmitted and when capable hardware exists to break the key exchange that protected it. Unlike many attack vectors, HNDL requires no active exploitation at the time of collection the adversary is simply a passive observer archiving traffic for future use.
The attack is directed specifically at public-key key exchange mechanisms: RSA key transport, ECDH, and ECDSA-protected session establishment. These operations establish the symmetric session keys used to encrypt the actual data. If an adversary can recover the session key from a captured key exchange using Shor's algorithm on a future quantum computer all data encrypted in that session becomes readable retroactively. HNDL is not a future threat contingent on quantum hardware existing today; the collection phase is happening now.
How HNDL Attacks Are Conducted
An HNDL attack requires two capabilities: the ability to intercept encrypted traffic in transit and storage capacity sufficient to retain large volumes of ciphertext for an extended period. Adversaries with access to major network transit points internet exchange points, submarine cable landing stations, or major peering infrastructure can capture substantial volumes of traffic passively. The captured data includes the TLS handshake records containing the key exchange, and the encrypted session payload. Both components are retained together.
The decryption phase occurs later. When a cryptographically relevant quantum computer becomes available, the adversary processes the archived key exchange records through Shor's algorithm to recover the session keys. With the session keys recovered, the encrypted payloads decrypt straightforwardly using classical computation. The time between collection and decryption may be years or decades. An adversary conducting HNDL today does not need quantum hardware now; they need it before the confidentiality of the collected data expires.
Why Classical Key Exchange Is Vulnerable
The vulnerability is in asymmetric key exchange: specifically RSA key transport, ECDH, and Diffie-Hellman. These mechanisms use public-key mathematics to allow two parties to establish a shared secret over an insecure channel without having previously exchanged a key. The security of this process rests on mathematical problems integer factorization and discrete logarithm that are hard for classical computers but solvable in polynomial time by a quantum computer running Shor's algorithm.
Perfect Forward Secrecy (PFS), implemented using ephemeral ECDH key exchanges in TLS 1.3, mitigates the risk that a long-term private key compromise retrospectively decrypts past sessions. However, PFS does not protect against HNDL. An adversary who captures the full TLS handshake including the ephemeral key exchange can recover the ephemeral session key using Shor's algorithm, breaking PFS retroactively. The critical gap is that PFS was designed assuming classical adversaries, not quantum ones with the ability to solve the discrete logarithm problem.
Who Conducts HNDL Collection
HNDL collection programs require sustained investment in signals intelligence infrastructure, significant data storage capacity, and long-term operational planning. These requirements place systematic HNDL programs within the reach of nation-state adversaries with advanced signals intelligence capabilities. Countries with documented interest in long-term intelligence collection against government, military, commercial, and academic targets are the most relevant threat actors for HNDL programs targeting high-value data.
NSA and CISA guidance acknowledges nation-state adversaries as the primary HNDL threat. The CISA PQC initiative explicitly lists HNDL as a current risk that should drive migration timelines. Organizations whose sensitive communications are of geopolitical, commercial, or strategic interest to nation-state actors should treat HNDL collection as an ongoing operational reality rather than a theoretical future concern.
“Adversaries are already storing encrypted data today to decrypt it once quantum computing becomes available. The threat of 'Harvest Now, Decrypt Later' attacks means that data encrypted today could be compromised in the future.”
What Data Is Most at Risk
HNDL risk is proportional to data sensitivity and required confidentiality lifetime. The most exposed data is information that must remain confidential for a decade or more. Classified government and defense communications that must remain secret for decades face substantial HNDL exposure if transmitted using classical key exchange today. Healthcare patient records subject to long retention requirements, financial transaction archives with multi-decade auditability requirements, and intellectual property with long competitive value all belong in this high-risk category.
Short-lived session data routine web page loads, streaming media sessions, API calls returning non-sensitive data has minimal HNDL risk because the data's confidentiality value expires long before quantum hardware capable of decryption is likely to exist. HNDL risk assessment centers on identifying which communications in an organization's traffic profile have long-lived sensitivity requirements, not on applying uniform urgency to all encrypted traffic.
Healthcare: Long Retention Requirements Create High Exposure
Healthcare organizations maintain patient records subject to long statutory retention requirements. In the United States, HIPAA requires medical records to be retained for a minimum of six years, and state laws often mandate longer periods. Long-lived patient records diagnostic histories, treatment records, genomic data, mental health records transmitted or stored today using classical encryption may be vulnerable to HNDL decryption well within their required retention period. Genomic data in particular carries essentially permanent sensitivity, as an individual's genome does not change.
Healthcare organizations communicating sensitive patient data over networks protected by classical TLS between facilities, between providers and payers, or between providers and patients using telehealth are generating HNDL-exposed traffic today. The prioritization guidance from NIST SP 1800-38 explicitly calls out long-lived sensitive data including health records as high-priority migration targets. Healthcare IT teams should treat network traffic carrying long-retention patient data as the first category requiring hybrid post-quantum key exchange deployment.
Government and Defense Communications
Government and defense communications are the highest-priority HNDL target for nation-state adversaries. Diplomatic communications, intelligence assessments, defense procurement discussions, strategic planning, and operational command traffic may carry classification requirements of decades or more. NSA CNSA 2.0 reflects this urgency: National Security Systems are required to adopt CNSA 2.0 post-quantum algorithms with specific timelines, and the 2033 deadline for exclusive use of CNSA 2.0 algorithms was set with HNDL risk in mind.
Federal civilian agencies subject to OMB M-23-02 also face HNDL exposure for sensitive but unclassified communications law enforcement records, personally identifiable information, sensitive financial data, and other protected categories that must remain confidential for extended periods. The federal priority on PQC migration is driven by recognition that adversaries are conducting HNDL collection against federal systems today.
Financial Records and Transaction Archives
Financial institutions maintain transaction records, trading data, and client account information subject to regulatory retention requirements that commonly span seven to ten years or longer. Account information and transaction histories that flow between institutions over encrypted channels interbank settlements, cross-border payments, securities clearing represent high-value targets for adversaries with commercial or geopolitical interests in financial intelligence.
Financial institutions in the European Union operating under DORA (Regulation 2022/2554) must manage ICT risks including cryptographic resilience as part of their digital operational resilience programs. DORA's requirements for proactive risk management and continuity of critical ICT services create a regulatory framework within which PQC migration for high-sensitivity financial data is an expected element of comprehensive ICT risk management. Financial institutions should prioritize systems handling data with long retention requirements or systemic importance.
Confidentiality Lifetime: The Critical Variable
The key variable in HNDL risk assessment is not the current availability of quantum hardware it is the required confidentiality lifetime of the data being protected. If data must remain confidential for five years and capable quantum hardware is unlikely to arrive within five years, HNDL risk is lower. If data must remain confidential for twenty years, the risk calculus changes entirely: the data is being captured now and the question is whether capable hardware will exist within that twenty-year window.
Cryptographers and national security agencies assess that cryptographically relevant quantum computers capable of running Shor's algorithm at scale against production key sizes are not available today but are the subject of active development programs. The appropriate response to uncertainty about timing is to reduce confidentiality lifetime exposure by migrating to post-quantum key exchange now, so that data captured after migration cannot be retroactively decrypted regardless of when quantum hardware arrives.
Why Waiting Is Not a Safe Strategy
A common objection to early PQC migration is that capable quantum computers do not yet exist at scale and may not for years. This reasoning treats HNDL risk as a future problem rather than a current one. The error is treating the decryption phase as the relevant risk moment rather than the collection phase. Data with a twenty-year confidentiality requirement that is captured today under classical encryption faces HNDL exposure for its entire confidentiality window. Waiting does not reduce the risk already incurred on data generated before migration occurs.
Additionally, cryptographic migrations are not quick. Building a complete cryptographic inventory, testing post-quantum algorithms in staging environments, updating TLS configurations and certificate infrastructure, coordinating with software vendors, and rolling out changes across large distributed systems takes sustained engineering effort over multiple years. NIST, NSA, and CISA all recommend beginning migration now precisely because the migration timeline is long and HNDL collection may already be accumulating.
How PQC Migration Reduces HNDL Exposure
Migrating to ML-KEM for key establishment closes the HNDL vulnerability for future communications. Once a TLS connection uses ML-KEM (or hybrid ML-KEM plus ECDH) for key exchange, capturing and archiving the TLS handshake no longer provides a path to session key recovery using Shor's algorithm. The session key derived from ML-KEM encapsulation is secure against quantum attacks, so archived HNDL-collected ciphertext from post-migration sessions cannot be decrypted using future quantum hardware.
Crucially, HNDL exposure is reduced from the migration date forward it does not retroactively protect data collected before migration. This is why earlier migration reduces more total risk: every additional day that high-sensitivity communications use classical key exchange is another day of HNDL exposure accumulation. Organizations should prioritize migrating the highest-sensitivity network traffic systems generating long-lived sensitive data first, accepting that lower-sensitivity traffic can follow on a longer timeline.
The Role of Hybrid Cryptography in HNDL Defense
Hybrid key establishment combining ML-KEM with ECDH in a single TLS handshake provides immediate HNDL protection without requiring a full migration of all dependent systems simultaneously. The IETF draft-ietf-tls-hybrid-design specification defines how hybrid key exchange is integrated into TLS 1.3. Major browsers, TLS libraries, and cloud providers have been adding hybrid TLS support as ML-KEM has been standardized.
From an HNDL defense perspective, hybrid deployment is immediately effective: the hybrid session key derived from both ECDH and ML-KEM requires breaking both algorithms simultaneously for HNDL decryption to succeed. An adversary who archives hybrid TLS handshakes today cannot use quantum hardware to recover the session key using Shor's algorithm alone they also need to break ML-KEM, which is not vulnerable to Shor's algorithm. This makes hybrid deployment an effective interim measure that provides strong HNDL protection before full PQC migration is complete.
Regulatory Context: NSA, OMB, CISA, and DORA
The regulatory treatment of HNDL has moved from general risk acknowledgment to specific requirements. NSA CNSA 2.0 sets timelines for National Security Systems that implicitly account for HNDL risk: systems must complete migration to CNSA 2.0 algorithms before 2033, with some high-priority categories having earlier requirements. OMB M-23-02 requires federal agencies to inventory and plan migration of systems generating long-lived sensitive data a requirement whose primary risk driver is HNDL.
For non-federal organizations, CISA's PQC initiative and joint guidance with NSA and NIST recommend that all organizations begin assessing and addressing HNDL exposure now. EU DORA requirements for financial entities to manage ICT risks include cryptographic resilience considerations relevant to HNDL. ETSI TR 103 619 provides European organizations with guidance on migration strategies that address both current and HNDL-related cryptographic risks in a phased approach.
Common Misconceptions About HNDL
Several misconceptions prevent organizations from correctly assessing HNDL risk. The most common is that HNDL is irrelevant because quantum computers capable of breaking current encryption do not exist. This confuses the collection phase with the decryption phase: HNDL collection does not require quantum hardware it requires passive network access and storage. The quantum hardware is only needed for the future decryption phase, which occurs after the data has already been archived.
A second misconception is that Perfect Forward Secrecy protects against HNDL. PFS protects against long-term private key compromise by using ephemeral keys for each session. However, an adversary who captures the full TLS handshake including the ephemeral key exchange has all the material needed to recover the ephemeral key using Shor's algorithm, breaking PFS retroactively. PFS was designed against classical adversaries; it does not defend against quantum-enabled retroactive key recovery.
Action Steps for Organizations
Addressing HNDL risk requires three priority actions. First, identify which organizational systems generate or transmit data with long required confidentiality lifetimes. These systems wherever classical key exchange is used to protect long-lived sensitive data are the highest HNDL priorities. Second, deploy hybrid ML-KEM alongside ECDH in TLS for these highest-priority systems. Hybrid deployment is immediately achievable using current TLS library support and provides strong HNDL protection from the deployment date forward.
Third, initiate a comprehensive cryptographic inventory (CBOM) covering all systems to identify remaining HNDL exposure beyond the initial priority tier. The CBOM provides the foundation for a staged migration program that extends post-quantum protection progressively across lower-priority systems over time. Organizations subject to NSA CNSA 2.0 requirements should align their HNDL mitigation timeline with CNSA 2.0 milestones. All other organizations should consult the CISA joint guidance on quantum-readiness for a structured approach to HNDL risk reduction.
References
- [1]NISTNIST FIPS 203(2024)Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- [2]NISTNIST FIPS 204(2024)Module-Lattice-Based Digital Signature Standard (ML-DSA)
- [3]
- [4]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [5]NSANSA PQC FAQ(2022)Quantum Computing and Post-Quantum Cryptography FAQ
- [6]OMBOMB M-23-02(2022)Memorandum on Migrating to Post-Quantum Cryptography
- [7]CISACISA PQC Initiative(2022)Post-Quantum Cryptography Initiative
- [8]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [9]IETFIETF draft-ietf-tls-hybrid-design(2024)Hybrid key exchange in TLS 1.3
- [10]EUEU DORA (Regulation 2022/2554)(2022)Digital Operational Resilience Act
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.
ML-DSA Explained
ML-DSA (NIST FIPS 204) is the primary post-quantum digital signature algorithm, replacing ECDSA and RSA signatures in PKI, code signing, and authentication. This guide explains how it works, its parameter sets, and migration from ECDSA.