Harvest Now, Decrypt Later

What “harvest now, decrypt later” means

Harvest now, decrypt later describes a threat to confidentiality. An adversary records or obtains encrypted communications, files, database exports, or other ciphertext while the current cryptography still prevents practical decryption. The adversary retains that ciphertext and hopes to recover the protected plaintext later, after a cryptographically relevant quantum computer (CRQC) or another cryptanalytic development makes the underlying cryptographic assumption unsafe. The model therefore concerns potential future decryption of data encrypted today; it does not demonstrate that an adversary has intercepted any particular organization’s traffic or that every encrypted record has the same value.13

The uncertainty is material. Current evidence says it is not possible to predict exactly when—or even whether—quantum computers will break present-day encryption. Predictions about when a CRQC may exist vary widely. That uncertainty is not a reason to wait: the transition from algorithm standardization to full integration into information systems has historically taken 10 to 20 years, because vendors must build algorithms into products and services and organizations must procure and integrate those products and services.213

The exposure equation: secrecy lifetime, migration time, and threat timing

A useful planning model compares three time periods. Let x be the time that systems or data must remain secure—its data secrecy lifetime or required security lifetime. Let y be the time required to complete migration to a post-quantum cryptography (PQC) infrastructure. Let z be the time until a CRQC capable of breaking relevant current cryptography becomes available. The model identifies a security gap when the required protection period and migration period together extend beyond the expected threat timing: in shorthand, organizations should begin migration before x + y exceeds the expected z. Because z is uncertain, this is a risk-planning model rather than a prediction.31

The model explains why a future machine can create a present-day decision. If a secret must remain confidential for 20 years and a system takes several years to replace, test, procure, and deploy, ciphertext created during the migration window may still be valuable when the threat materializes. Conversely, information whose sensitivity ends quickly may deserve less immediate attention than information with a long secrecy lifetime. The model is not a claim that all records will be harvested, that all ciphertext will eventually be decrypted, or that all systems must be changed at the same time.31

Migration time is not only an algorithm-selection exercise. Asymmetric cryptographic transitions require coordination among organizations and within ecosystems. Upgraded and non-upgraded agents may need to coexist and communicate during staged migrations, and some devices, software, or infrastructure may be difficult to update. These dependencies can make the practical value of y much larger than the time needed to change a single configuration setting.13

Stored ciphertext risk is different from future signature forgery

Confidentiality and authentication should not be placed on one undifferentiated quantum-risk list. For confidentiality, the HNDL concern is direct: a malicious actor with adequate resources may store sensitive encrypted data now and attempt to decipher it after a CRQC becomes available. The relevant questions are how long the plaintext must remain secret, how it is transmitted or stored, which key-establishment schemes protect it, and how difficult it will be to migrate those schemes.341

Digital signatures have a different primary driver. A signature generally proves origin and supports integrity and, in some contexts, nonrepudiation; it is not simply a container holding plaintext that an adversary can later decrypt. Many signature uses are short-lived, such as authentication during a TLS handshake. Other signatures must remain trustworthy for decades: examples include firmware or software signing, legal documents, certificates embedded in hardware devices, and long-lived root keys supporting short-lived authentication. Those cases can be exposed if a CRQC becomes available during the product or signature’s operational or evidentiary lifetime, especially where signatures cannot be replaced or devices cannot be updated.31

The distinction does not mean authentication can be ignored. A system may remain secure for its authentication event as long as its algorithms and keys are secure when authentication occurs, while long-lived signing and validation infrastructure can create a separate transition requirement. For network protocols, key establishment may therefore need to move on an HNDL-driven schedule, while authentication algorithms may transition on a different schedule based on certificate, root-key, device, and signature lifetimes.1

What data and systems warrant priority

Prioritization should begin with value and time, not with the assumption that all encrypted records are equally exposed. The strongest early candidates are data whose secrecy has a long required lifetime and whose confidentiality depends on public-key key establishment or encryption that may be vulnerable to a future CRQC. Government secrets and medical records are examples of information identified as having long-term sensitivity. Other organizations should apply the same reasoning to their own durable business secrets, personal information, regulated records, strategic research, and information whose compromise would create lasting harm—without assuming that any one category is automatically the highest priority.1

• Long-lived confidential data, especially information that remains valuable for many years.
• Network security protocols, including TLS and virtual private networks, where key-establishment keys protect session confidentiality.
• Email and document encryption, including S/MIME-based exchanges and encrypted files that may be retained.
• Code-signing and software-distribution systems where verification must continue on devices that may remain deployed after a CRQC becomes available.
• Firmware-signing systems and certificates or roots embedded in hardware, smart cards, or other difficult-to-update devices.
• Products, services, and infrastructure that cannot be readily updated, replaced, or coordinated with their communication partners.

Network protocols deserve decomposition rather than a single label. Modern protocols commonly use separate asymmetric keys for key establishment and authentication. Key-establishment keys are often short-lived and protect the symmetric session keys that provide confidentiality; long-term keys are used for authentication. Forward secrecy can limit the effect of compromising a long-term key on earlier sessions, but it does not remove the need to consider HNDL for traffic whose session keys could be recovered through a future attack on the key-establishment scheme. Consequently, the key-establishment and authentication components may have different migration timelines.1

Inventory is a prerequisite to prioritization. An organization needs to know where public-key encryption, key encapsulation, key exchange, digital signatures, certificates, roots, firmware verification, and embedded cryptographic implementations are used. It also needs the relevant data-retention and secrecy requirements, system replacement dates, update constraints, and dependencies on external parties. Without that information, a migration schedule risks overlooking a long-lived encrypted archive or an in-field verifier that cannot accept a new signature algorithm.13

Mitigations and migration approaches

The central mitigation is to migrate systems that protect long-lived confidentiality to quantum-resistant cryptography before the exposure window becomes unacceptable. NIST released three principal PQC standards in August 2024: FIPS 203 for ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 for ML-DSA, a module-lattice-based digital signature algorithm; and FIPS 205 for SLH-DSA, a stateless hash-based digital signature algorithm. These standards address key establishment and digital signatures, respectively. Their existence provides standardized targets for planning, but it does not by itself complete an organization’s deployment.

For confidentiality, teams should identify traditional RSA-style and Diffie–Hellman-style key exchanges, encryption interfaces, certificates, protocol negotiation, stored ciphertext, and the systems that consume resulting keys. They should then test and stage quantum-resistant key-establishment mechanisms in the actual protocol and operational environments. For authentication, teams should separately examine signature generation and verification, certificate chains, root keys, firmware, legal or archival documents, and the ability of deployed devices to receive new verification logic or trust anchors.31

Hybrid schemes may be useful during transition when compatibility and confidence requirements call for both a traditional and a post-quantum component. A hybrid confidentiality construction is intended to protect against both immediate weaknesses in the post-quantum component and future quantum compromise of the traditional component, provided at least one component remains secure under the stated construction and assumptions. Hybrid deployment still has engineering costs: component keys and ciphertexts can affect interoperability, sizes, processing, coordination, and implementation safety. It should therefore be evaluated and tested rather than treated as an automatic guarantee.

Crypto agility is a practical enabler. Systems should be designed or improved so that cryptographic algorithms, parameters, certificates, and supporting components can be replaced and adapted without rebuilding the entire application or device. Migration plans should include staged coexistence, interoperability testing, key and certificate lifecycle procedures, rollback considerations, performance measurements, and supplier coordination. Particular care is needed for hardware and firmware that cannot be updated after manufacture, because a cryptographic choice embedded there may determine the security of the product for its full operational lifetime.31

Finally, migration decisions must account for uncertainty in both directions. A CRQC may be years or decades away, and its exact arrival cannot be predicted. At the same time, many post-quantum algorithms are relatively new compared with RSA and finite-field or elliptic-curve Diffie–Hellman, so the security community has had less time to study some algorithms and parameterizations. Organizations should use standards, testing, implementation review, and risk-based sequencing rather than claiming certainty about either the future threat date or the absolute security of a newly deployed implementation.21

A practical decision framework

A defensible HNDL program can proceed in the following order. First, map cryptographic use: distinguish confidentiality, key establishment, signatures, certificates, and roots. Second, attach a secrecy or validation lifetime to the protected data, software, device, or document. Third, estimate migration time from discovery through procurement, integration, testing, deployment, and partner coordination. Fourth, rank cases where the required lifetime plus migration time creates the greatest concern relative to uncertain threat timing. Fifth, select a staged mitigation—standardized PQC, a suitable hybrid design where justified, or another documented control—and validate it in the operating environment.31

1. Inventory cryptographic assets, algorithms, keys, certificates, protocols, applications, devices, and data stores.
2. Classify each use as confidentiality, authentication, signing, or a combination, and record external dependencies.
3. Record how long the data must remain secret or how long a signature, root, firmware image, certificate, or device must remain trustworthy.
4. Estimate migration time, including systems that cannot be updated and partners that must interoperate.
5. Prioritize HNDL-sensitive confidentiality first where long-lived data depends on vulnerable key establishment or encryption; separately prioritize long-lived signature and verification use cases.
6. Pilot, test, and stage the selected PQC or hybrid approach, then maintain the ability to replace algorithms and parameters as experience and standards evolve.

This framework produces a reasoned sequence rather than a universal deadline. It also preserves an important limitation: a risk ranking describes potential exposure and migration urgency; it is not evidence that an adversary has already collected an organization’s data. The objective is to reduce the amount of sensitive information that could remain valuable and vulnerable during the period before a suitable migration is complete.31

Conclusion

Harvest now, decrypt later turns a future quantum capability into a present confidentiality-planning issue. The key test is whether information must remain secret for longer than the organization can migrate the systems protecting it, under an uncertain threat timeline. Prioritize long-lived sensitive data and vulnerable key-establishment paths, while analyzing signatures separately for future forgery and long-lived validation concerns. Use standards-based, tested, and replaceable cryptographic designs—including hybrid approaches where justified—and treat migration as a staged systems, infrastructure, and ecosystem effort rather than a one-time algorithm swap.31