Harvest Now, Decrypt Later: Understanding the Quantum Threat Already in Motion

What Is Harvest Now, Decrypt Later?

Harvest Now, Decrypt Later (HNDL) — also called “store now, decrypt later” or “retrospective decryption” — is a threat model where adversaries intercept and store encrypted communications today, intending to decrypt them in the future when cryptographically relevant quantum computers (CRQCs) become available.

The concept is straightforward:

Harvest: Intercept encrypted data traversing networks (TLS sessions, VPN tunnels, encrypted emails, file transfers)
Store: Archive the encrypted ciphertext in bulk data storage — cost is minimal for nation-state actors
Wait: Hold the data until quantum computers can break the encryption
Decrypt: Use Shor’s algorithm on a CRQC to recover RSA/ECC private keys, then decrypt all stored traffic

This is not a theoretical future threat. It is an active intelligence collection strategy being executed today by nation-state adversaries.

Why HNDL Is Already Happening

The Economics of HNDL

For a nation-state intelligence agency, HNDL is an extremely attractive strategy:

Factor	Analysis
Collection cost	Low — fiber taps, ISP cooperation, satellite interception already exist
Storage cost	Minimal — bulk storage costs <$10/TB and declining annually
Opportunity cost	Zero — the data is already flowing past collection points
Potential payoff	Massive — decades of diplomatic, military, and economic intelligence
Risk of detection	Very low — passive interception is extremely difficult to detect
Timeline pressure	None — stored ciphertext doesn’t degrade

The cost-benefit calculation overwhelmingly favors collection. An adversary with existing signals intelligence infrastructure pays essentially nothing extra to store quantum-vulnerable ciphertext that may later yield decades of classified communications.

Scale of Collection

Consider the scale of data that flows over networks daily:

Government-to-government communications
Defense contractor technical exchanges
Financial institution inter-bank transfers
Pharmaceutical research collaborations
Energy sector SCADA communications
Diplomatic cable traffic
Intelligence community coordination

A significant fraction of this traffic is protected solely by RSA or ECC key exchange — algorithms that Shor’s algorithm will break. Every intercepted session is a potential future intelligence windfall.

Who Is Conducting HNDL Operations?

While specific intelligence operations are classified, the cybersecurity and intelligence communities broadly acknowledge that sophisticated nation-state actors are actively collecting encrypted traffic for future decryption.

Known Indicators

U.S. Intelligence Community Assessments:

The NSA has explicitly cited HNDL as justification for CNSA 2.0’s urgency
Multiple congressional briefings have referenced active HNDL collection by adversaries
Executive Order 14028 and National Security Memorandum 10 both reference the quantum threat to existing data

Capability Assessment:

Nations with extensive signals intelligence infrastructure (fiber taps, submarine cable access, satellite interception) have the means
Nations investing heavily in quantum computing (China, Russia) have both motive and capability
The Chinese quantum computing program specifically targets cryptanalytic applications

Strategic Logic:

Any nation-state with intelligence collection capability would be strategically negligent not to store quantum-vulnerable ciphertext
The cost is trivial relative to intelligence budgets
The potential return is decades of retroactive intelligence access

Documented Evidence

While specific HNDL programs remain classified, related evidence supports active collection:

Reports of increased fiber optic tapping operations
Growth in nation-state data center capacity beyond apparent civilian needs
Strategic investments in quantum computing with explicit cryptanalytic goals
Public statements from intelligence officials acknowledging the threat

What Data Is at Risk?

Not all encrypted data faces equal HNDL risk. The key factors are:

1. Confidentiality Requirement Duration

Data is at risk if it must remain confidential longer than the time until CRQCs are available:

HNDL Risk Condition:
  Required Confidentiality Period > Time Until CRQC

Example:
  Military plans classified for 50 years (confidentiality = 50 years)
  Optimistic CRQC estimate: 8-12 years
  HNDL Risk: CRITICAL (data exposed decades before declassification)

2. Data Categories at Highest Risk

Data Category	Typical Retention	HNDL Risk Level
State secrets / classified intelligence	25-75 years	Critical
Long-term diplomatic communications	20-50 years	Critical
Trade secrets / intellectual property	10-20+ years	High
Medical records (genomic data)	Patient lifetime	High
Financial records (M&A, strategy)	5-15 years	High
Personal identity information	Individual lifetime	High
Legal privileged communications	Case lifetime + appeals	Moderate-High
Current military operations	1-5 years	Moderate
Business communications (general)	1-3 years	Low
Ephemeral session data	Hours-days	Minimal

3. Network Exposure

Data faces HNDL risk only if the encrypted ciphertext can be intercepted. Consider:

Internet transit: Highest exposure — traverses potentially hostile infrastructure
Dedicated circuits: Moderate exposure — physical access still possible
Private networks: Lower exposure — requires direct penetration
Air-gapped systems: Minimal transit exposure (but storage media theft is separate risk)

4. Quantum-Vulnerable Algorithm Protection

Data is only at HNDL risk if protected by algorithms vulnerable to quantum attack:

RSA (any key size): Vulnerable — Shor’s algorithm factors large integers
ECDH/ECDSA (any curve): Vulnerable — Shor’s algorithm solves discrete log on elliptic curves
DH (any size): Vulnerable — Shor’s algorithm solves discrete log
AES-256 (without quantum-vulnerable key exchange): Not directly vulnerable
ML-KEM / ML-DSA: Quantum-safe — not subject to HNDL

Critical insight: Even if data-at-rest encryption uses AES-256, the key exchange mechanism used to establish that key is often RSA or ECDH. If the key exchange is intercepted, AES encryption is irrelevant — the adversary recovers the symmetric key via the quantum-vulnerable key exchange.

Calculating Your HNDL Exposure

The Mosca Inequality

Michele Mosca’s inequality provides the foundational framework for HNDL risk calculation:

If X + Y > Z, your data is at risk.

Where:
  X = Time needed to migrate to quantum-safe cryptography
  Y = Time your data must remain confidential  
  Z = Time until a CRQC is available

Interpretation:

If your migration will take 7 years (X=7)
And your data must remain confidential for 20 years (Y=20)
And CRQCs may arrive in 10 years (Z=10)
Then: 7 + 20 = 27 > 10 ✓ — your data is already at risk from HNDL

Practical HNDL Exposure Timeline

2026 (today)                           2035 (estimated CRQC)
    │                                         │
    │◄──── X: Migration time (5-15 yrs) ────►│
    │                                         │
    │◄──────────── Y: Data confidentiality requirement ──────────────►│
    │                                                                  │
    ├── Data already at HNDL risk ────────────┤                        │
    │                                         │                        │
    │ Adversary collects ─►│ Adversary decrypts ─►│ Data exposed ────►│

Organizational HNDL Exposure Assessment

To calculate your organization’s aggregate HNDL exposure:

Step 1: Identify all data flows protected by quantum-vulnerable key exchange

Step 2: For each data flow, determine:

Data sensitivity classification
Required confidentiality duration
Network exposure level (internet, private, air-gapped)
Volume of data traversing this flow

Step 3: Calculate exposure window:

Exposure Window = max(0, Confidentiality_Period - Time_Until_CRQC)

If Exposure_Window > 0: This data flow has HNDL exposure

Step 4: Prioritize based on:

Highest sensitivity × longest exposure window = highest priority
Government/military > financial > healthcare > commercial
Internet-facing > private network > air-gapped

Which Algorithms Are Vulnerable?

Algorithms Broken by Shor’s Algorithm

Shor’s algorithm efficiently solves integer factorization and discrete logarithm problems, breaking:

Algorithm	Attack	Impact
RSA-2048	Factor modulus	Key recovery → decrypt all traffic
RSA-4096	Factor modulus (slower)	Same as RSA-2048, slightly more qubits needed
ECDH P-256	Discrete log on curve	Shared secret recovery → decrypt session
ECDH P-384	Discrete log on curve	Same attack, more qubits
ECDSA (all curves)	Discrete log	Signature forgery (less relevant to HNDL)
DH (all sizes)	Discrete log	Shared secret recovery
DSA	Discrete log	Signature forgery
ElGamal	Discrete log	Plaintext recovery

Important Nuance: Key Exchange vs. Authentication

For HNDL, the critical vulnerability is in the key exchange mechanism:

If an adversary captures a TLS session using RSA key exchange, they can recover the session key once they have a CRQC
If a session uses ECDHE for key exchange (providing forward secrecy), the adversary must break the ECDHE computation — still vulnerable to Shor’s algorithm
Authentication signatures (server certificate verification) are less relevant to HNDL because they don’t protect confidentiality

Forward secrecy does NOT protect against HNDL: Many assume ephemeral key exchange (ECDHE) protects against HNDL. It doesn’t — Shor’s algorithm can solve ECDHE just as it solves static ECDH. Forward secrecy protects against classical key compromise, not quantum attack.

Algorithms NOT Vulnerable to HNDL

Algorithm	Why It’s Safe	Notes
AES-256 (symmetric)	No efficient quantum attack beyond Grover	Provides 128-bit post-quantum security
SHA-384+	Collision/preimage resistance maintained	Grover provides only quadratic speedup
ML-KEM (all levels)	Lattice-based, not broken by Shor	Quantum-safe key encapsulation
ML-DSA (all levels)	Lattice-based	Quantum-safe signatures
SLH-DSA	Hash-based only	Conservative quantum safety
XMSS/LMS	Hash-based only	Stateful but quantum-safe

Defensive Measures Against HNDL

1. Immediate: Deploy Hybrid Key Exchange

The fastest defense against HNDL is deploying hybrid key exchange that combines classical and post-quantum algorithms:

Hybrid Key Exchange (TLS 1.3):
  Combined shared secret = KDF(X25519_shared || ML-KEM-768_shared)
  
  - Even if ML-KEM has an undiscovered weakness: X25519 still protects (today)
  - Even when CRQCs break X25519: ML-KEM still protects (future)
  - Both must be broken simultaneously to compromise the session

Implementation status in 2026:

Chrome/Chromium: Enabled by default
Firefox: Enabled by default
Cloudflare: Available for all customers
AWS: Available across major services
OpenSSL 3.x: Supported via oqs-provider
Most CDN/cloud providers: Hybrid TLS available

2. Encrypt Sensitive Data at Rest with Quantum-Safe Keys

For data that must remain confidential long-term:

Encrypt archives and backups with AES-256 keys derived from quantum-safe key exchange
Re-encrypt existing archives if original key exchange was quantum-vulnerable
Implement key encapsulation using ML-KEM for long-term key storage

3. Reduce Network Exposure

Minimize the data that traverses potentially hostile networks:

Move sensitive communications to dedicated, controlled circuits where possible
Implement zero-trust architectures reducing reliance on network-level encryption alone
Use application-layer encryption with quantum-safe algorithms for highest-sensitivity data

4. Deploy CBOM for Visibility

You cannot defend against HNDL without knowing which data flows use quantum-vulnerable cryptography.

QCecuring CBOM provides:

Automated discovery of all quantum-vulnerable key exchange across your infrastructure
HNDL risk scoring identifying which data flows face the highest retroactive decryption risk
Network protocol analysis showing exactly which TLS sessions use quantum-vulnerable cipher suites
Prioritized remediation guidance focusing resources on highest-exposure data flows

Organizations deploying QCecuring CBOM immediately gain visibility into their HNDL exposure — the essential first step in any defensive strategy.

5. Implement PQC for High-Value Communications

Prioritize quantum-safe protection for:

Executive communications containing strategic decisions
Mergers and acquisitions discussions
Government-classified or defense-related communications
Research and development intellectual property
Long-term customer data with extended confidentiality requirements

6. Reduce Data Retention Periods

Where possible, reduce the volume of data at HNDL risk by:

Minimizing data retention to regulatory minimums
Implementing aggressive data lifecycle management
Destroying encrypted data and keys when retention periods expire
Avoiding unnecessary data duplication across systems

The CRQC Timeline: When Will HNDL Pay Off?

Current Estimates

The timeline for cryptographically relevant quantum computers remains uncertain, with estimates ranging widely:

Source	Estimate	Basis
NSA/CNSA 2.0 timeline	Implicit 2030s	Deadline structure suggests NSA expects threat within decade
Global Risk Institute	2030-2035 (significant probability)	Annual expert surveys
IBM	2030s (utility scale)	Quantum computing roadmap
Google	2030-2035	Quantum supremacy trajectory
Chinese quantum programs	Unknown	Significant investment suggests confidence
Conservative academic estimates	2035-2045	Based on qubit scaling challenges

Why Uncertainty Doesn’t Reduce HNDL Risk

The exact CRQC timeline doesn’t change the HNDL threat for data with long confidentiality requirements:

If CRQCs arrive in 2035 and your data must stay secret until 2060, you have a 25-year exposure
If CRQCs arrive in 2045 and your data must stay secret until 2060, you still have a 15-year exposure
Even optimistic CRQC timelines create exposure for long-lived secrets

The only question is: Will your data still need to be secret when CRQCs arrive? If yes, HNDL is your problem today.

Breakthrough Risk

Timeline estimates assume gradual progress. A quantum computing breakthrough could accelerate timelines dramatically:

Novel error correction codes could reduce qubit requirements
New physical qubit implementations could scale faster
Theoretical advances could reduce circuit depth
Nation-state programs may achieve breakthroughs before public disclosure

Planning based on median estimates means accepting significant risk of earlier-than-expected quantum capability.

HNDL in Practice: Real-World Scenarios

Scenario 1: Government Diplomatic Communications

A foreign intelligence service intercepts encrypted diplomatic cables between embassies using TLS 1.2 with RSA-2048 key exchange.

Data value: Diplomatic positions, negotiation strategies, intelligence assessments
Confidentiality requirement: 30-50 years (standard classification periods)
HNDL exposure: When CRQCs arrive, decades of diplomatic intelligence becomes accessible
Defensive measure: Immediate migration to hybrid TLS with ML-KEM for diplomatic communications

Scenario 2: Pharmaceutical Research

A nation-state interested in economic espionage intercepts encrypted research data transfers between pharmaceutical company sites using ECDH P-256.

Data value: Drug compound data, clinical trial results, patent-pending research
Confidentiality requirement: 15-20 years (patent protection period + competitive advantage)
HNDL exposure: Competitors could access research data years before patent expiration
Defensive measure: Quantum-safe encryption for research data in transit and at rest

Scenario 3: Financial Institution Long-Term Records

Encrypted financial transaction records and customer data are intercepted from a major bank’s inter-site WAN connections.

Data value: Customer financial data, trading strategies, M&A communications
Confidentiality requirement: 7-25 years (regulatory retention + competitive sensitivity)
HNDL exposure: Customer data exposure, competitive intelligence compromise
Defensive measure: CBOM assessment to identify all quantum-vulnerable financial data flows, prioritized PQC deployment

Scenario 4: Healthcare Genomic Data

Patient genomic data encrypted with RSA-based key exchange during transfer to cloud analytics platforms.

Data value: Complete human genome sequences — permanently sensitive
Confidentiality requirement: Patient lifetime (effectively indefinite)
HNDL exposure: Permanent privacy loss — genomic data cannot be changed if exposed
Defensive measure: Immediate quantum-safe protection for genomic data transfers

CBOM: The Essential Tool for HNDL Defense

Why CBOM Is Non-Negotiable for HNDL Mitigation

Without a complete Cryptographic Bill of Materials, you cannot:

Identify which data flows are vulnerable — you don’t know which connections use RSA/ECDH key exchange
Prioritize remediation — you can’t assess which data flows carry the most sensitive information
Measure progress — you can’t track which flows have been migrated to quantum-safe
Verify completeness — you can’t confirm that no quantum-vulnerable key exchange remains

CBOM-Driven HNDL Defense Workflow

Step 1: Deploy QCecuring CBOM
    → Automated discovery of all cryptographic protocols and key exchange methods

Step 2: Identify quantum-vulnerable key exchange
    → Filter CBOM for RSA, ECDH, DH key exchange in network protocols

Step 3: Map data sensitivity to vulnerable flows
    → Enrich CBOM with data classification from business context

Step 4: Calculate HNDL exposure scores
    → Combine algorithm vulnerability + data sensitivity + retention period + network exposure

Step 5: Prioritize and remediate
    → Deploy hybrid/PQC key exchange starting with highest-scoring data flows

Step 6: Monitor continuously
    → Ensure no regression to quantum-vulnerable key exchange

What to Look For in Your CBOM

When analyzing your CBOM for HNDL risk, focus on:

TLS cipher suites: Any suite using RSA or ECDH for key exchange
VPN configurations: IPsec/IKE using DH or ECDH key agreement
S/MIME and email encryption: Key transport mechanisms
API communications: Backend-to-backend encrypted channels
Database encryption: Key derivation and exchange for TDE or application-layer encryption
Cloud connectivity: VPN tunnels to cloud providers
Partner integrations: Encrypted data exchange with third parties

Key Takeaways

HNDL is an active threat, not a future concern — adversaries are collecting encrypted data today
The economics overwhelmingly favor collection — nation-states pay essentially nothing to store potential future intelligence
Forward secrecy does NOT protect against HNDL — ephemeral ECDHE is just as vulnerable to Shor’s algorithm
Data with long confidentiality requirements is most at risk — government secrets, IP, genomic data, long-term financial records
The CRQC timeline is uncertain but irrelevant for long-lived data — if data must stay secret for 25+ years, it’s at risk regardless of exactly when CRQCs arrive
CBOM is the essential first step — you cannot defend against HNDL without knowing which data flows use quantum-vulnerable key exchange
QCecuring CBOM identifies HNDL-exposed data flows — automated discovery, risk scoring, and prioritized remediation guidance
Hybrid key exchange is the immediate defense — deploy ML-KEM hybrid today to protect new communications from HNDL
Don’t wait for certainty — the cost of early protection is far less than the cost of retroactive exposure
Every day of delay increases stored ciphertext — adversaries are collecting right now; earlier migration means less data at risk