Harvest Now, Decrypt Later: Why Every Month of PQC Delay Is an Irreversible Security Decision

Your adversaries are not waiting for Q-Day. They are collecting your encrypted traffic right now — TLS sessions, VPN tunnels, archived communications, financial records — and storing it with the explicit plan to decrypt it once a cryptographically relevant quantum computer exists. This is not a threat model from a research paper. Harvest Now, Decrypt Later (HNDL) is a present, persistent threat, not a future hypothetical.^{[NIST IR 8547, 2024]} The only question your board will eventually ask is whether you treated it that way.

What "Harvest Now, Decrypt Later" Actually Means — And Why It's Already Underway

The HNDL attack model is operationally straightforward, which is precisely what makes it dangerous. An adversary — nation-state actor, advanced persistent threat group, or well-resourced criminal syndicate — intercepts and stores encrypted data in transit or at rest today, at scale, via network interception or server compromise. The ciphertext is useless to them right now. That is irrelevant. They are not trying to read it today.

The decryption event is deferred to the point at which a sufficiently powerful quantum computer can execute Shor's algorithm against the public-key cryptography protecting that data. Shor's algorithm efficiently solves the mathematical problems — integer factorization for RSA, discrete logarithm for ECC — that underpin the overwhelming majority of enterprise encryption deployed today.^{[NIST IR 8547, 2024]} RSA and ECC are not incidentally vulnerable. They are structurally broken by a sufficiently capable quantum adversary.

What makes HNDL uniquely difficult to manage is its forensic invisibility. Passive data collection leaves no trace in your SIEM, generates no alerts, and triggers no incident response workflow. You will not know it happened. The exposure is retroactive and permanent: data harvested today cannot be un-harvested after you complete your PQC migration. The harm precedes the defense.

Which Data in Your Organization Has a Target on Its Back

Not all data carries equal HNDL risk. The operative variable is data sensitivity shelf life — the length of time a given data class must remain confidential to preserve its value to your organization and limit its value to an adversary. A press release has a shelf life of hours. A nation-state's strategic interest in your intellectual property, M&A negotiation records, or long-term infrastructure contracts may span decades.

The categories most acutely exposed to HNDL collection include:

• Long-lived credentials and PKI material: Root CA private keys, code-signing certificates, and HSM-protected key material with multi-year validity windows.
• Financial and transactional records: Subject to regulatory retention requirements of seven to ten years in most jurisdictions, these remain confidential long after the transaction closes.
• Intellectual property and R&D communications: Product roadmaps, patent-pending research, and competitive strategy discussions archived over encrypted channels.
• M&A and legal communications: Pre-announcement deal communications protected by attorney-client privilege carry indefinite sensitivity windows.
• Patient records and clinical data: Subject to HIPAA retention requirements and carrying long-term personal harm potential if disclosed.
• State-adjacent and government-contract data: Particularly in defense, critical infrastructure, and regulated utilities — where adversary interest is highest and tolerance for exposure is lowest.

The practical triage framework: any data class currently protected by RSA or ECC encryption with a confidentiality requirement of five years or more is an HNDL target today, regardless of when your organization completes its quantum-safe migration.

Why Q-Day Uncertainty Is Not a Reason to Wait — It's a Reason to Move Faster

The most common CISO objection to immediate PQC investment is timeline uncertainty: "We don't know when Q-Day is, so we'll revisit this in two years." This reasoning is structurally flawed, and the flaw runs in the direction of urgency, not deferral.

Credible estimates for cryptographically relevant quantum computing span a wide range — roughly three to fifteen years depending on the source and the specific threat threshold — reflecting genuine scientific uncertainty about engineering scale-up, error correction, and qubit fidelity.^{[NIST IR 8547, 2024]} That uncertainty is not a planning reprieve. It is the planning problem.

Enterprise-wide cryptographic transitions — replacing PKI hierarchies, updating VPN configurations, renegotiating vendor and partner cryptographic interfaces, migrating HSMs, and retraining development teams — historically require seven to ten years to complete at scale.^{[NIST NCCoE, 2024]} If Q-Day arrives at the lower bound of current estimates, organizations that began planning in 2026 will not finish in time. If it arrives at the upper bound, organizations that began in 2025 will have completed migration with margin.

Some quantum computing companies have published aggressive internal timelines suggesting cryptographically relevant capability within three to five years. These projections are commercially motivated — published by companies with financial incentives to signal rapid progress — and have not been independently verified by the broader scientific community. They should not be treated as scientific consensus. The prudent planning assumption remains the seven-to-ten-year enterprise migration timeline: if Q-Day arrives at the lower bound of credible estimates, organisations that began planning in 2026 will not have finished migrating in time.

What NIST's 2024 Standards and 2025 Guidance Actually Require of You

NIST finalized its first three post-quantum cryptographic standards in 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a stateless hash-based signature alternative.^{[NIST CSRC, 2024]} These are not draft guidance documents or recommended practices. They are finalized Federal Information Processing Standards — the same designation class as AES and SHA-3 — carrying corresponding compliance weight for federal agencies and heavily regulated industries.

NIST IR 8547 goes further, providing guidance on HNDL risk and identifying data sensitivity shelf life as a key risk-tiering variable.^{[NIST IR 8547, 2024]} This is NIST telling practitioners directly: the threat is live, the standards are ready, and the risk framework for prioritization is now documented.

For national security systems, NSA's CNSA 2.0 advisory is unambiguous: migration planning to quantum-resistant algorithms is not optional and timelines for key system categories are defined.^{[NSA, 2022]} Defense Industrial Base contractors, critical infrastructure operators, and any organization with federal contract obligations should treat CNSA 2.0 as a compliance signal with near-term audit implications, not a long-horizon advisory.

The NCCoE's Migration to Post-Quantum Cryptography project provides the most detailed practitioner-facing implementation guidance currently available, including discovery tooling considerations and migration sequencing frameworks.^{[NIST NCCoE, 2024]}

The Cryptographic Inventory Problem — And How to Start Solving It

Most organizations cannot currently answer three questions that are now foundational to quantum risk management: What data do we hold? Where is it encrypted? And how long does it need to remain confidential? This is the cryptographic inventory problem, and it is the single most common practitioner barrier to beginning PQC migration planning.

Solving it does not require a vendor platform decision or a multi-year program initiation. It requires a structured audit of your existing cryptographic surface area across five primary asset classes:

1. PKI infrastructure: Root and intermediate CA certificates, issued leaf certificates, certificate validity windows, and renewal processes. Identify every RSA and ECC key in your hierarchy.
2. HSMs: Hardware security modules protecting key material — note the algorithms, key lengths, and the data classes each HSM protects.
3. VPN and network security configurations: IKE/IPsec tunnel parameters, TLS cipher suite configurations, and remote access gateway settings. Many enterprise VPN deployments remain configured with legacy RSA key exchange.
4. APIs and application-layer cryptography: Internal and external API authentication mechanisms, JWT signing keys, and application-layer encryption libraries. Development teams frequently use cryptographic primitives without visibility from the security architecture function.
5. Archived data and long-term storage: Backup encryption configurations, data-at-rest encryption for long-retention datasets, and any archived communications or records subject to regulatory retention mandates.

Map each asset to its estimated data sensitivity shelf life. This single mapping exercise produces the factual foundation for every subsequent prioritization decision.

Building a Defensible PQC Migration Roadmap Your Board Will Approve

Board approval for PQC migration investment is fundamentally a risk communication challenge, not a technical one. The framing that consistently lands: "We have identified which assets are most exposed to harvest-now-decrypt-later collection, we know which of those have the longest confidentiality requirements, and this roadmap addresses the highest-risk exposures first." That framing requires the cryptographic inventory described above. Without it, you are asking for budget against an abstract future threat. With it, you are presenting a prioritized risk register with documented exposure windows.

The recommended migration approach is crypto-agility combined with hybrid classical-PQC deployment at the highest-priority tiers. Hybrid deployment — running ML-KEM alongside existing ECDH in TLS 1.3 key exchange, for example — provides quantum-resistant protection for new sessions without abandoning classical security assurances during the transition period.^{[NIST NCCoE, 2024]} It also provides operational experience with PQC performance characteristics before full cutover.

A defensible phased approach:

• Phase 1 (0–6 months): Complete cryptographic asset inventory. Establish data sensitivity shelf life mapping. Identify top-tier HNDL exposure assets.
• Phase 2 (6–18 months): Deploy hybrid PQC for highest-priority data flows. Begin PKI modernization planning. Engage HSM vendors on PQC roadmap timelines.
• Phase 3 (18 months+): Systematic migration of remaining RSA/ECC dependencies, sequenced by sensitivity shelf life and operational criticality. Retire legacy cipher suites on a documented timeline.

The 30-day concrete action item: task your security architecture team with identifying every data class currently protected by RSA or ECC encryption that carries a confidentiality requirement of five years or more. Document findings in a risk register with sensitivity windows and current encryption methods mapped side by side. This exercise takes two to four weeks with existing resources. Its output is a board-ready risk artifact, an auditor-defensible due diligence record, and your highest-priority re-encryption target list — before any vendor or tooling commitment is required.

Key Takeaways

• HNDL attacks are active now: adversaries harvest encrypted data today for future quantum decryption, leaving no forensic trace and creating irreversible retroactive exposure.
• Data with a 10-year sensitivity window that is harvested today remains at risk even after your PQC migration is complete — the harm precedes the defense.
• Enterprise cryptographic migrations historically require 7–10 years; Q-Day estimates range from 3 to 15 years, meaning the only safe planning assumption is that migration should have started already.
• NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in 2024 — these are production-ready standards, not draft guidance.
• NIST IR 8547 provides risk-tiering guidance based on data sensitivity shelf life and addresses HNDL as a present threat.
• NSA CNSA 2.0 treats PQC migration planning as a mandate for national security systems — Defense Industrial Base contractors and critical infrastructure operators should treat this as a near-term compliance signal.
• The immediate action is a cryptographic asset inventory mapping RSA/ECC-protected data to sensitivity shelf life — a 2–4 week exercise that produces a board-ready risk artifact and demonstrates regulatory due diligence today.

This article draws on primary documentation from NIST (FIPS 203, FIPS 204, FIPS 205, NIST IR 8547 Initial Public Draft, and the NCCoE Migration to Post-Quantum Cryptography project) and the NSA CNSA 2.0 Cybersecurity Advisory. All claims verified against official sources as of March 2026.

Related Reading

• NCCoE Migration to Post-Quantum Cryptography — NIST's practitioner-facing project hub for PQC migration, including discovery tooling guidance and implementation sequencing resources. pages.nist.gov
• NIST IR 8547 (Initial Public Draft) — Transition to Post-Quantum Cryptography Standards — Algorithm transition context, deprecation timelines for RSA and ECC, and FAQ-style implementation guidance for compliance officers. nvlpubs.nist.gov
• NSA CNSA 2.0 Cybersecurity Advisory — NSA's algorithm migration mandate for national security systems, with defined timelines by system category — essential reading for DIB contractors and critical infrastructure operators. media.defense.gov

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.