Harvest Now, Decrypt Later: Why Quantum Threats to Enterprise Encryption Are Already Here

The Threat That Is Already Active

Enterprise security planning has a structural bias toward visible, immediate threats — ransomware payments, active intrusions, credential theft detected in SIEM logs. Harvest now, decrypt later (HNDL) attacks produce none of these signals. There is no breach notification, no forensic artifact, no incident ticket. An adversary running an HNDL campaign against an enterprise may have years of encrypted traffic in their archive with no indication in any security tooling that collection ever occurred.

The intelligence community’s warnings are explicit and consistent. CISA guidance from late 2024 identified HNDL as a present-day threat requiring present-day action. The FBI and NSA have both issued public advisories warning that state-sponsored actors — primarily nation-states with long-horizon strategic intelligence objectives — are already running bulk collection campaigns against encrypted communications, prioritizing high-value targets: financial institutions, defense contractors, critical infrastructure operators, and government agencies. The encrypted data they collect today is worthless to decrypt now but becomes readable the moment a cryptographically relevant quantum computer (CRQC) comes online.

Three research papers published between May 2025 and March 2026 have compressed the threat timeline materially. New quantum circuit architectures have reduced estimated resource requirements to break RSA-2048 from approximately 20 million physical qubits (the estimate as recently as 2023) to potentially fewer than 100,000 under certain architectural approaches. The Global Risk Institute’s 2024 survey of quantum computing experts found that the median estimate for CRQCs capable of breaking modern encryption is 2034, with roughly one-third of experts assigning greater than 30% probability of that capability emerging by 2030.

This compression matters operationally. An organization that planned its PQC migration for 2032 based on 2023 threat timelines may now have a 6-year window instead of 9. For institutions whose data has a long sensitivity horizon — intelligence files, long-term financial contracts, medical records, proprietary research — the effective exposure window began the moment HNDL collection started, not when the quantum computer exists.

What Data Is Actually at Risk

Not all encrypted data faces equal HNDL exposure. The threat is most severe for information that will retain its sensitivity across the quantum timeline — roughly 2026 to 2035. Understanding which data categories face material risk changes how organizations should sequence their cryptographic migration.

High-risk categories (sensitivity persists 5–15 years): Strategic business plans and M&A documentation, long-duration financial contracts and bond instruments, national security and defense-adjacent communications, intelligence and law enforcement records, proprietary R&D data with long commercial lifespans, and personally identifiable information subject to long-retention regulatory requirements (medical records, financial records, biometric data).

Medium-risk categories (sensitivity persists 2–7 years): Competitive pricing and procurement data, HR and employee records, software source code and trade secrets, customer data protected by breach notification laws.

Lower-risk categories (sensitivity is short-lived): Real-time transaction authentication, ephemeral session keys for web browsing, transient API authentication tokens. Note that while the data may be short-lived, the encryption key material used to protect it may protect long-lived infrastructure — the distinction between data sensitivity and key infrastructure sensitivity is critical.

The most overlooked HNDL exposure category is key material itself. An adversary who archives an organization’s TLS certificate private key (exposed via a Heartbleed-style vulnerability, a compromised HSM, or a misconfigured cloud storage bucket) can retroactively decrypt all historical communications that used that certificate — without needing to break RSA directly. This means HNDL risk is not limited to traffic interception; it extends to any historical key exposure event in the organization’s security history.

Where the Industry Has Already Moved

The good news is that the migration tooling now exists and is being deployed at scale. NIST finalized three post-quantum cryptography standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a conservative hash-based backup. These are drop-in replacements for RSA and ECC in the functions they perform — securing TLS handshakes, signing certificates, and authenticating API requests.

Cloudflare reported in April 2026 that more than 65% of human traffic through its network already uses post-quantum TLS. Google and Apple have set 2029 internal deadlines for full PQC migration of their own systems. Apple integrated PQC into iMessage via its PQ3 protocol as early as February 2024. OpenSSL 3.x supports hybrid PQC TLS (combining classical and post-quantum key exchange in a single handshake), making PQC-capable TLS an accessible configuration option for any organization running a modern web stack.

The NSA’s CNSA 2.0 framework sets the global compliance reference point: all new national security systems must use quantum-safe algorithms from January 2027; application-layer migration by 2030; complete infrastructure migration by 2033–2035. France, the UK, Canada, and Germany have issued parallel guidance converging on the same timeline. These mandates create a de-facto international standard that vendor ecosystems are migrating toward — meaning that organizations that delay their cryptographic migration will increasingly encounter interoperability friction with partners, customers, and regulators that have already moved.

What Enterprise Security Leaders Should Do About It

1. Prioritize HNDL Exposure in the Next Risk Register Review

The risk register is where HNDL becomes actionable. Most enterprise risk registers assess threats by their current exploitability — ransomware gets a high likelihood score because it is exploiting systems right now. HNDL requires a different framing: the collection phase is already happening; the exploit phase is delayed by the quantum timeline. A risk register entry for HNDL should reflect the probability of cryptographic compromise against long-lived sensitive data, not the probability of real-time decryption capability.

Concretely: if your organization processes M&A documentation, long-term contract archives, or regulated personal data with 10-year retention requirements, those data categories should carry an HNDL exposure rating in the current risk register — not a deferred risk for review in 2030. The loss event (adversary gaining access to your strategic documents) may occur in 2033; the exposure window (adversary capturing the encrypted data) is open right now.

2. Deploy Hybrid PQC TLS at the Perimeter First

The lowest-friction, highest-impact migration step is enabling hybrid post-quantum TLS at the network perimeter — web application firewalls, API gateways, load balancers, and CDN endpoints. Hybrid PQC TLS combines the classical ECDH key exchange with ML-KEM in a single handshake. If the PQC component is broken (a theoretical concern in the early years of any new standard), the classical component still provides protection. If the classical component is eventually broken by quantum computers, the PQC component already provides protection.

Cloudflare, AWS CloudFront, Azure Front Door, and Google Cloud Load Balancing all support hybrid PQC TLS configurations as of 2026. For organizations using these platforms, enabling PQC TLS is a configuration change, not an engineering project. For organizations running their own TLS termination on OpenSSL 3.x or BoringSSL, hybrid PQC TLS is available as a cipher suite configuration. This step immediately protects all new encrypted traffic at the perimeter from HNDL collection — the most common and highest-volume attack surface.

3. Begin the Cryptographic Asset Inventory Now — It Takes Longer Than You Think

The cryptographic migration is not primarily a technology problem; it is a discovery problem. Before any algorithm can be replaced, every location where that algorithm is used must be identified: TLS certificates, PKI certificate chains, SSH keys, code signing keys, HSM-stored private keys, encrypted data at rest, API authentication tokens, and cryptographic dependencies in application code.

Large enterprises typically discover 40–60% more cryptographic dependencies than initially estimated when they begin formal inventory processes. The inventory phase alone takes 6–18 months for mid-size organizations and longer for large enterprises with complex legacy estates. Organizations that begin the inventory in 2026 have a credible path to completing perimeter and application-layer migrations before 2030. Organizations that begin in 2028 will be compressing a multi-year process into a 2-year window under regulatory pressure — the same pattern that produced chaotic GDPR compliance sprints in 2017–2018.

4. Update Vendor and Procurement Requirements for Cryptographic Agility

Every new technology contract signed from 2026 onward should require “cryptographic agility” — the vendor’s ability to migrate the product’s cryptographic algorithms without requiring a full product replacement. The practical requirement: ask vendors to document their PQC migration roadmap, confirm that ML-KEM and ML-DSA support will be available in their product by 2028, and specify that cryptographic algorithm upgrades will be delivered within the existing maintenance contract at no additional licensing cost.

HSMs are the most critical procurement category. An HSM purchased today will typically remain in operation for 5–10 years. An HSM that does not support PQC firmware upgrades is a migration bottleneck that will require accelerated hardware replacement at the worst possible time — mid-migration, under regulatory pressure, with shortened procurement cycles. Require PQC roadmap documentation from Thales, Entrust, Utimaco, and other HSM vendors before any new hardware is purchased or contracted.

The Race Against the Clock

The HNDL threat reframes the PQC migration urgency: this is not a future problem to solve before a deadline, it is a present data exposure problem that compounds daily. Every day that long-lived sensitive data transits over classical RSA or ECC encryption is another day’s worth of collection for an adversary with quantum ambitions.

The migration path is clear — NIST standards are final, hybrid TLS is deployable today, the inventory process is well-understood, and major infrastructure vendors are ahead of the curve. What most enterprises lack is not tooling but urgency. The 65% of Cloudflare traffic already protected by PQC TLS represents organizations that treated this as present risk, not future planning. The remaining 35% — and the broader enterprise market beyond Cloudflare — is the HNDL attack surface.

Frequently Asked Questions

Sources & Further Reading

• Post-Quantum Cryptography in 2026: The Enterprise Guide — Gray Group International
• NIST IR 8547: Migration to Post-Quantum Cryptography Standards — NIST CSRC
• Why 2026 Matters for Quantum Security — The Quantum Insider
• The $15 Billion Post-Quantum Migration: NSA Deadlines Are Set — PR Newswire
• Cloudflare Post-Quantum Roadmap: 65% of Traffic Now PQC-Protected — Cloudflare Blog
• Harvest Now, Decrypt Later: The Quantum Threat Your Risk Register Isn’t Tracking — Horizen Labs
• Harvest Now, Decrypt Later — Palo Alto Networks Cyberpedia