post quantum crypto intermediate · 14 min read · April 29, 2026

Harvest-Now-Decrypt-Later: The Threat Model That Drives Post-Quantum Migration Timelines

An adversary who captures and stores encrypted traffic in 2026 can decrypt it in 2036 — assuming quantum computers exist by then and the data was encrypted under classical (non-post-quantum) cryptography. This is the harvest-now-decrypt-later threat model, and it is the structural reason post-quantum cryptography migration must precede the actual quantum threat by 5-15 years. This tutorial covers the threat model, who is doing the harvesting, what data is at risk, and how to assess your organization's timeline exposure.

Prerequisites: Tutorial 21: Post-Quantum Cryptography Threat Model, Tutorial 51: Hybrid TLS with Post-Quantum KEMs

A 2026 TLS connection encrypts your data with X25519-based key exchange — the standard pre-PQ classical cryptography. An adversary with packet-level network access can capture that encrypted traffic. They cannot decrypt it now. But if quantum computers capable of running Shor’s algorithm exist in 2036, they can decrypt the captured 2026 traffic at that point — Shor breaks ECDH retroactively, and the captured ciphertext yields its plaintext.

This is the harvest-now-decrypt-later (HNDL) threat model. It is the structural reason post-quantum cryptography migration must start years before quantum computers actually arrive. If your data has a 10-year secrecy lifetime and quantum computers arrive in 2036, you needed PQ encryption by 2026 to protect data that is supposed to remain secret through 2036.

The HNDL model has been called the “Y2Q” problem (year-quantum), echoing Y2K. Tutorial 23 covered code auditing for Y2Q readiness; this tutorial covers the threat model itself — who is doing the harvesting, what data is at risk, and how to assess organizational exposure.

The threat model

Components of the HNDL threat:

Adversary capability: the ability to capture and store encrypted network traffic at scale, indexed for future retrieval.
Storage durability: captured traffic must persist for years until quantum computers arrive.
Quantum capability: the eventual arrival of fault-tolerant quantum computers running Shor’s algorithm at the relevant key size (RSA-2048, ECDH on common curves, etc.).
Data lifetime: the captured data must still be sensitive when decrypted.

All four components are required. A purely transient secret (e.g., a one-time-use authentication token) is not at risk because it has no value after the session. Long-lived secrets (account credentials, financial records, identity documents, intellectual property, classified communications) are.

Who is harvesting

Three categories of adversary have the capability:

1. State signals-intelligence agencies

The NSA, GCHQ, FSB, MSS, Mossad, and similar agencies have decades of experience capturing global network traffic. Documents from the Snowden disclosures (2013) made clear that bulk network capture at intercontinental scale is operational. Storage costs have fallen 10-100× since then; capturing and indexing TLS traffic at scale is well within state-actor budgets.

For state actors, harvesting is essentially free — they’re already doing bulk capture. Storing the captured ciphertext for future quantum decryption is a marginal cost. The HNDL threat from state actors should be assumed by default for any TLS-protected traffic that crosses a network boundary they have access to.

2. Large platform operators

Cloud providers, ISPs, and telecoms have access to traffic flowing through their infrastructure. They typically don’t capture customer encrypted traffic for HNDL purposes — but they have the technical capability if compelled by law or operator decision. The HNDL threat from cloud platforms is more about future regulatory or legal compulsion than about active harvesting today.

3. Targeted adversaries

A sophisticated APT (advanced persistent threat) targeting a specific organization can intercept the organization’s traffic. This is more tactical than strategic — the adversary captures specific traffic of value, not bulk Internet traffic. For targeted high-value organizations, HNDL is a present concern.

For most casual web traffic, the HNDL threat is primarily from state actors. For specific high-value sectors (defense, finance, healthcare, government), the threat broadens to include targeted adversaries.

What data is at risk

The relevant question is how long does the data need to remain secret, compared to when do quantum computers arrive.

Data type	Typical secrecy lifetime	Quantum-vulnerable now?
Financial transactions	Decades	Yes
Medical records	Lifetime + decades	Yes
State diplomatic cables	50-100 years	Yes
Industrial trade secrets	Decades	Yes
Identity documents (SSN, passport)	Lifetime	Yes
Authentication credentials	Days to years	Mostly yes
Session cookies	Hours to days	Mostly no
One-time tokens	Minutes	No

The longer the secrecy lifetime, the higher the HNDL exposure. A medical record encrypted today must remain confidential for decades. If quantum computers arrive in 15 years and the data was encrypted classically, the protection failed retroactively.

For each data type, ask:

How long does this data need to remain confidential?
What is the worst-case quantum-computer arrival date?
If both quantum computers and the secrecy lifetime overlap, is there HNDL risk?

For most organizations, financial records, customer PII, and any long-term archive are the highest-risk categories.

The timeline question

The crux of HNDL: how soon do quantum computers arrive?

The honest answer is: nobody knows precisely. Predictions vary widely:

Optimistic forecasts (vendor roadmaps): 5-10 years to a fault-tolerant machine capable of factoring RSA-2048 (2030-2035).
Mainstream forecasts (BSI, NIST, ETSI): 10-20 years (2035-2045).
Skeptical forecasts (academic researchers): 20+ years; some doubt fault-tolerant scaling is achievable on the assumed timelines.

A planning principle that several governments use: assume the optimistic forecast. Even if mainstream forecasts are right, the migration cost is paid upfront and the security gain is preserved if quantum computers arrive sooner than expected.

The relevant tutorial-21 number: a credible RSA-2048 quantum attack needs ~20 million physical qubits and ~8 hours wall-clock. As of 2026, no machine is closer than ~10,000 physical qubits. Closing the gap is a serious engineering challenge — but not an impossible one over 10-15 years.

NIST and CNSA timelines

The US government has issued explicit migration deadlines:

NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), issued 2022 and updated 2024-2025: federal systems handling classified data must transition to PQ algorithms by 2030-2033, depending on system category.
NIST PQC standardization: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SPHINCS+ (FIPS 205), Falcon (FIPS 206) — all standardized by 2025.
OMB memoranda for federal agencies: agencies must complete cryptographic inventories by 2025 and begin migrations.
EU Cybersecurity Act and ETSI guidance: similar timelines, less specific deadlines.

The implicit logic: if migration must be complete by 2030-2035 and quantum computers might arrive by 2035, the migration starts now. The 5-10 year migration timeline accounts for the typical pace of cryptographic migrations (slow, especially in legacy and embedded systems).

How to assess your organization’s exposure

A practical risk assessment:

Step 1: Inventory data lifetimes

For each category of data your organization handles:

What is the maximum acceptable disclosure time? A patient’s medical record from 2026 disclosed in 2046 is a privacy harm; a session cookie disclosed in 2046 is meaningless.
What encryption protects this data in transit and at rest? TLS, VPN, disk encryption, etc.
Is the encryption pure-classical or hybrid PQ?

Step 2: Estimate adversary capabilities

Is your data of interest to state actors? If yes, assume HNDL is in active operation.
Is your data of interest to targeted APTs? Less certain but plausible for specific sectors.
Is your data covered by future regulatory or legal compulsion? Possible for cloud-provider-hosted data.

Step 3: Apply migration priority

If high-lifetime data is protected by classical-only encryption and your adversary model includes state actors:

TLS: migrate to hybrid TLS now (tutorial 51). Most major libraries and platforms support it.
Stored encryption: migrate to PQ-protected key wrapping for long-term archives.
Authentication: plan for PQ certificates and signatures (2026-2030 migration window).
Specific sensitive workloads: consider over-the-top PQ encryption layered above classical TLS.

Step 4: Track the migration

Maintain an inventory of cryptographic dependencies (helped by tools like the tutorial 23 Y2Q audit).
Test PQ-capable libraries and platforms now.
Plan for incremental rollout with hybrid signatures and key exchange before full PQ-only.

What to do today

A practical 2026 checklist:

Enable hybrid TLS where supported. Browsers and CDNs already do; ensure your server side supports it. (Tutorial 51 details.)
Audit codebases for cryptographic primitives. Run the tutorial 23 PQ audit on your repos; produce a Cryptographic Bill of Materials (CBOM).
Prioritize migration of long-lifetime data. Medical records, financial archives, government communications first; transient session traffic can wait.
Track NIST and library updates. Major TLS libraries get PQ updates regularly; staying current matters.
Plan for PQ certificates. This is the next migration after key exchange. Begin architectural planning even though deployment is 1-3 years out.

For organizations already on the migration path, the 2026 status is encouraging: hybrid TLS is real, library support is mature, the standards are settled. The hard work of migration ahead is operational (legacy systems, embedded devices, workflow updates), not cryptographic.

Common misconceptions

“HNDL is hypothetical.” State signals-intelligence capabilities are well-documented; bulk traffic capture happens. The HNDL threat is the technical extrapolation that captured traffic remains decryptable when quantum computers arrive. The fixed assumption is that quantum computers will eventually arrive; given that, HNDL is operationally real.

“Quantum computers are decades away, so HNDL doesn’t matter.” Even if “decades” is right, organizations with 30+ year secrecy needs (medical records, state secrets, long-term contracts) are exposed. Migration timelines must be set by the secrecy lifetime, not by the quantum-arrival forecast alone.

“Hybrid TLS solves HNDL.” Hybrid TLS solves the key exchange part of HNDL. Authentication (certificates, signatures) is still classical in 2026, so an adversary who breaks ECDSA can in principle replay or impersonate. Full HNDL protection requires the PQ-certificate migration too.

“Only governments need to worry.” False. Long-secrecy commercial data (financial archives, customer PII, IP) is at risk from state-actor harvesting and from sophisticated commercial adversaries. The HNDL threat is broad, not narrow.

“You can wait and migrate quickly when quantum computers arrive.” The history of cryptographic migrations is they take 5-10 years even with strong incentives. Migrations cannot be rushed if hardware, software, certificates, and standards all need to update. The deadline is years before the threat materializes, which is why 2024-2026 was the right time to start.

Decision rule

Your organization’s HNDL exposure depends on three factors:

Data secrecy lifetime. Data confidential for over 10 years, plan migration urgently. Data confidential for under 1 year, lower priority.
Adversary model. State-actor in scope, plan now. Only commercial adversaries, somewhat slower.
Migration cost. Greenfield system: easy. Long-running production system with lots of legacy: harder, allow more time.

For organizations with high-secrecy-lifetime data and state-actor adversary models (defense, intelligence, finance, healthcare): full migration to PQ should be in progress, with hybrid TLS already deployed and PQ certificates planned. For organizations with shorter-lifetime data and weaker adversary models (general SaaS, e-commerce): hybrid TLS as available, less urgency on full PQ migration.

Where this goes next

This concludes the four-tutorial post-quantum-crypto deepening (49-52). The PQC track now has 7 tutorials covering the threat model, the algorithm primitives (ML-KEM, ML-DSA, Falcon, SPHINCS+), the deployment context (hybrid TLS), the operational threat model (HNDL), and the audit tooling. Future tutorials may cover specific deployment flows (PQ certificate authorities, hardware-security-module support, quantum-resistant blockchain), but the foundational coverage is now complete.