Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Why does harvest now, decrypt later make quantum…
Threats, Abuse & Incident Response

Why does harvest now, decrypt later make quantum migration a current risk even before quantum computers exist?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 25, 2026 Domain: Threats, Abuse & Incident Response

Because encrypted data can be captured today and stored until future quantum capabilities make decryption feasible. The risk is highest for information that must stay confidential for years, such as health records, financial data, communications, and trade secrets. In those cases, delay is not neutral. It extends the window in which an attacker can preserve data for later compromise.

Why harvest now, decrypt later changes the threat model

Harvest now, decrypt later is not a future-only problem because it creates an immediate exposure window. If an attacker can copy ciphertext today, they can preserve that data for later use when cryptanalytic capability improves. The practical question is not whether today’s encryption is weak now, but whether the protected data must remain confidential long enough for later decryption to matter.

The risk therefore depends on data lifespan. Short-lived data may expire before quantum risk becomes relevant, but long-retention records, archives, regulated communications, and high-value secrets can remain useful to an adversary for years. That makes the compromise time horizon part of the security decision, not an afterthought.

Even without a quantum computer, the attack already succeeds in one important sense: confidentiality is delayed, not destroyed. Once an organisation cannot assume that ciphertext remains safe for the full life of the data, encryption strategy, retention policy, and data classification all start to intersect.

Which data becomes exposed first

The highest-priority targets are not every encrypted file, but the ones whose value survives for a long time. Health records, financial records, legal communications, source code, private keys, and strategic business data can all remain sensitive long after collection. If the expected confidentiality period exceeds the likely time to quantum decryption for the chosen algorithm, the data is already at risk today.

That is why quantum migration is often a data-lifecycle problem before it is a pure cryptography problem. Organisations need to know which datasets are worth stealing now because the information will still be profitable later. The longer the retention and the broader the distribution of copies, the more attractive harvest now, decrypt later becomes.

This also changes prioritisation. Systems that hold transient operational data are not equal to systems that store archives, backups, or compliance records. The same cipher can be acceptable for one data class and risky for another simply because the confidentiality horizon is different.

Why migration has to start before quantum decryption exists

Migration is a current risk because cryptographic change takes time. Inventories must be built, dependencies mapped, algorithms replaced, certificates and keying material refreshed, and interoperability tested. Those changes cannot be rushed after a practical quantum breakthrough because the exposed data may already have been copied years earlier.

There is also a trust problem in waiting. Once an organisation believes the threat is “not real yet,” it tends to defer hardening until the migration becomes emergency work. That delay increases the amount of data accumulated under algorithms that may later become breakable.

Current guidance increasingly treats migration as a planning and exposure-management exercise, not a single cutover event. The core issue is to reduce the amount of information that remains decryptable in the future, while maintaining business continuity during the transition.

Risk and Threat Considerations

Harvest now, decrypt later creates a long-tail confidentiality risk: captured ciphertext can sit quietly for years and become readable once cryptanalytic capability improves. The danger is greatest where retention is long, duplication is widespread, and the contents retain strategic, legal, or personal value over time.

Failure mechanism: An attacker exfiltrates encrypted data now, stores it at low cost, and waits until future cryptographic capabilities or key compromise make retrospective decryption feasible.

Impact: Sensitive information can be exposed long after the original compromise, undermining confidentiality, regulatory expectations, client trust, and the security assumptions behind archival and backup retention.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-57 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-57Key ManagementQuantum migration hinges on key lifecycle and cryptoperiod planning for long-lived protected data.
Recommendation — Assess cryptoperiods and replace crypto before stored ciphertext outlives the protection it depends on.
NIST CSF 2.0PR.DS-02 — Data in transit is protectedThe question concerns whether protected data remains confidential over time as crypto ages.
GV.RM-01 — Risk management strategy is established and maintainedQuantum exposure is a strategic, time-horizon risk that needs explicit treatment in risk planning.
Recommendation — Review data protection controls against the full retention horizon of sensitive ciphertext. Add quantum decryption exposure to the organisation’s risk strategy and prioritisation.
ISO/IEC 27001:2022A.5.12 — Classification of informationHarvest now, decrypt later risk depends on which information must stay confidential for years.
A.8.24 — Use of cryptographyThe topic directly concerns whether current cryptography remains adequate for future confidentiality.
Recommendation — Classify long-retention information by confidentiality horizon before choosing migration timing. Reassess cryptographic controls against the data’s required confidentiality lifetime.

Practitioner Guidance

What to prioritise: Start with data whose confidentiality must outlast the expected life of the encryption, not with the easiest systems to update. That means long-retention archives, regulated records, high-value intellectual property, and any content whose disclosure would still matter years from now.

What to verify: Confirm which algorithms, certificate lifetimes, and key sizes protect the data today, then compare them with the retention period and replacement timeline. If you cannot show that the protection outlives the data, treat migration as urgent rather than optional.

Practitioner takeaway: The real decision is whether the data can safely survive the whole period between capture and decryption, because harvest now, decrypt later turns time itself into part of the attack surface.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 25, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org