Harvest Now, Break Later

Expanded Definition

Harvest Now, Break Later describes a long-horizon cryptographic threat model rather than a single exploit. Adversaries capture ciphertext, protocol transcripts, certificates, or other publicly observable cryptographic material today and retain it until better algorithms, larger key sizes, or more capable compute make decryption or forgery feasible. The danger is greatest where confidentiality, authenticity, or non-repudiation must last for years, such as regulated records, state data, intellectual property, or long-lived device identities.

This pattern is often discussed alongside post-quantum migration, but it is not limited to quantum risk. Weak key management, deprecated algorithms, and poor rotation practices can make the same data worth stockpiling even before any cryptanalytic breakthrough. In the language of the NIST Cybersecurity Framework 2.0, the issue sits squarely in governance, protection, and resilience planning because security teams must reason about how long a control remains trustworthy, not only whether it is currently sound. The most common misapplication is treating the threat as purely future-looking, which occurs when organisations ignore present-day collection of sensitive encrypted material that will outlive current cryptographic assumptions.

Examples and Use Cases

Implementing protection against Harvest Now, Break Later rigorously often introduces migration overhead and inventory complexity, requiring organisations to weigh long-term confidentiality against the cost of re-issuing trust anchors, re-encrypting archives, and updating embedded systems.

• Threat actors capture VPN or TLS traffic now, expecting to decrypt older sessions later if a weak cipher suite or key exchange becomes breakable.
• An organisation stores medical, legal, or financial archives for many years, so encrypted backups may remain valuable to attackers long after collection.
• Device certificates and signing keys used in IoT or industrial systems remain deployed for the life of the asset, making future forgery a real concern.
• Software supply chain signatures that protect updates today can become a target if trust in the signing algorithm weakens before the product is retired.
• Publicly accessible metadata, certificates, or transcripts are harvested in bulk because they may later support identity spoofing or message decryption once computational assumptions change.

For teams assessing modern cryptographic transition, guidance from bodies such as NIST CSRC is useful because it frames cryptography as a lifecycle decision, not a one-time deployment choice.

Why It Matters for Security Teams

Security teams need to understand Harvest Now, Break Later because the impact is delayed, cumulative, and easy to underestimate. A system can appear secure at deployment time while silently exposing years of collected material to future compromise. That makes data classification, retention policy, and cryptographic agility inseparable concerns. If sensitive data must remain confidential for a long period, then key length, algorithm choice, certificate lifetime, and rotation cadence all become risk decisions rather than technical defaults.

This matters especially for identity and trust infrastructure. Long-lived credentials, device identities, and signing certificates can become the weakest link when an attacker is able to replay, forge, or decrypt material that was harvested earlier. The operational response is usually not a single patch but a coordinated migration across applications, partners, and archived data. Practitioners also need to account for external dependencies, including identity providers, hardware roots of trust, and third-party services that may retain vulnerable algorithms longer than expected. Organisations typically encounter the consequences only after a decryption capability shift, signature compromise, or crypto migration deadline, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does harvest-now, decrypt-later matter for NHI governance?
• Why does harvest-now, decrypt-later matter for IAM and NHI programmes?
• How do IAM teams prepare for harvest-now, decrypt-later risk?
• Why is harvest now, decrypt later a current risk?