Guardians of the Enterprise — Insights from leading cyber experts.

Listen Now →
Application Security

Harvest Now, Decrypt Later: The Quantum Threat Already Collecting Your Data

5 min read Updated Application Security

Encryption is designed to protect data from unauthorized access. But what happens when attackers do not need to decrypt that data today?

They can simply collect it now and wait. This is the idea behind Harvest Now, Decrypt Later (HNDL). It is a threat model in which attackers capture encrypted data today and store it for future use. As computing advances, particularly with quantum computing, some of today’s cryptographic protections could eventually become vulnerable.

The concern is about the long-term value of the data being encrypted today. Sensitive information such as financial records, customer data, intellectual property, authentication information, government communications, healthcare records, and strategic business information can remain valuable for years. If an attacker stores encrypted traffic containing that information today, future advances could potentially turn that stored data into readable information.

What harvest now, decrypt later actually means

RSA and elliptic curve cryptography, the algorithms that secure most web traffic, VPNs, and API calls today, rely on math problems that are hard for classical computers to solve. A sufficiently powerful quantum computer running Shor’s algorithm could solve those same problems in a fraction of the time, breaking the encryption after the fact.

Harvest Now, Decrypt Later exploits the gap between those two facts. An attacker intercepts and stores encrypted data while it is still unreadable. They can then hold onto it until a cryptographically relevant quantum computer becomes available. At that point, yesterday’s captured traffic becomes today’s plaintext.

The capture happens now. Only the decryption is waiting on hardware.

Where TLS Breaks Down Against Harvest Now, Decrypt Later

Almost all of the traffic at risk here, web sessions, API calls, VPN tunnels, moves over TLS. TLS does two jobs. It runs a key exchange, historically RSA or ECDHE, to agree on a shared secret between client and server, and it uses that secret to encrypt the actual data with a symmetric cipher such as AES.

Harvest now, decrypt later targets the first job. A quantum computer is expected to leave AES intact when a sufficiently long key is used. The real target is the key exchange, RSA or ECDHE, that generates the AES session secret. Breaking that key exchange exposes the session. Recovering the shared secret from a recorded key exchange unlocks the entire session at once. The attacker gets there through the key exchange alone, without touching AES.

Modern TLS already includes forward secrecy through ephemeral Diffie-Hellman key exchange, which limits damage from a stolen private key today. A compromised key does not unlock past sessions, because each session negotiated its own ephemeral secret. That protection does not carry over to a quantum adversary. Shor’s algorithm attacks the same discrete logarithm problem that ECDHE relies on, so forward secrecy as currently implemented protects against key theft.

Hybrid post-quantum TLS is built to close this gap. Pairing ECDHE with ML-KEM in the same handshake means an attacker has to break both mechanisms to recover the session secret. Major browsers, CDNs, and cloud providers have already made this hybrid exchange the default in TLS 1.3 deployments.

The standards timeline security leaders should track

Governments and standards bodies have moved from guidance to enforceable deadlines over the past two years.

  • August 2024: NIST finalized the first three post-quantum cryptography standards: FIPS 203 (ML-KEM, for key exchange), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a hash-based signature scheme).
  • March 2025: NIST selected HQC as a fifth algorithm, adding a structurally different backup for key encapsulation.
  • June 2026: A pair of US executive orders raised the pressure. One mandates an accelerated, government-wide migration to post-quantum cryptography for federal systems, with binding deadlines for high-value assets and compliance requirements pushed down to federal contractors.
  • September 21, 2026: NIST moves all remaining FIPS 140-2 certificates to historical status. Only FIPS 140-3 validated cryptographic modules qualify for new federal procurement going forward.
  • 2030: NIST IR 8547 formally deprecates RSA-2048 and ECC P-256 for new systems, and federal high-value assets are expected to complete migration to post-quantum key establishment. The European Union’s coordinated roadmap sets the same year for critical infrastructure to complete migration for high-risk use cases.
  • 2035: The broader US federal migration target, first set in 2022, and the EU’s deadline for medium-risk use cases both land here.

Federal procurement rules do not bind enterprises directly. The same pressure still reaches them through vendor requirements, cyber insurance questionnaires, and regulatory frameworks that increasingly reference NIST guidance.

Industries at Risk From HNDL

The exposure concentrates wherever data is kept for years and carries regulatory weight or high-value intellectual property.

  • Financial services, insurance, and banking: transaction histories, account data, and underwriting records are retained for years under regulatory mandate, and breach costs compound with every year the data stays sensitive.
  • Healthcare and pharma: patient records and clinical trial data carry decades-long confidentiality requirements, often longer than most encryption algorithms have been expected to hold.
  • Government and large enterprises: classified material, procurement data, and critical infrastructure telemetry are exactly the categories nation-state actors are already documented harvesting.
  • SaaS and technology companies: source code, product roadmaps, and customer PII flowing through APIs represent long-lived intellectual property, even in organizations that see themselves as too small to be a target.
  • AI and LLM applications: prompts, embeddings, and model outputs often carry the same sensitive data as the applications feeding them, over API traffic that is easy to overlook in a cryptographic inventory.

Building a migration plan that starts now

A post-quantum migration is a multi-year program. The organizations that will be least disrupted are the ones treating it as infrastructure work today.

  1. Build a cryptographic inventory – Find every place RSA, ECC, and Diffie-Hellman protect data in transit or at rest, across internet-facing apps, APIs, VPNs, internal services, and third-party integrations. Nearly every migration roadmap, across every jurisdiction, gates the rest of the plan on this step.
  2. Prioritize by data shelf life – A legacy internal tool with a two-year data lifespan is low priority. A customer-facing API carrying health or financial records that must stay confidential for a decade come first.
  3. Design for crypto agility – Separate application logic from the cryptographic provider. Algorithms can then be swapped through a central policy engine instead of a ground-up rewrite.
  4. Adopt hybrid key exchange where it is available – Pairing a classical algorithm with ML-KEM in TLS means the connection stays protected even if one of the two is broken later. Major browsers, CDNs, and cloud providers are already shipping hybrid post-quantum TLS as a default option.
  5. Put the question to every vendor in the stack – Every WAAP, CDN, VPN, and cloud provider protecting your traffic should have a published post-quantum roadmap. A vendor with no answer is a gap in your own migration plan, whether or not it shows up in your inventory.

How AppTrana Helps You Get Ahead of Harvest Now, Decrypt Later

AppTrana now supports X25519MLKEM768, a hybrid post-quantum TLS key exchange standardized by NIST under FIPS 203 and the IETF under RFC 10024. It pairs the established X25519 algorithm with ML-KEM-768, so recovering the session secret requires breaking both.

This is what neutralizes harvest now, decrypt later at the source. The attack works by capturing today’s key exchange and waiting for a quantum computer to break it later. With ML-KEM in the mix, a quantum computer breaking X25519 alone is not enough to unlock that captured traffic. Data intercepted today stays unreadable even after the hardware arrives.

When a connecting client supports it, AppTrana negotiates this hybrid exchange automatically at the edge, with no disruption to clients that don’t support it yet. Where your origin’s TLS stack also supports it, AppTrana extends the same protection end to end.

For a full walkthrough of how the negotiation works, rollout options, and what to check on your origin, see our detailed guide on AppTrana’s hybrid post-quantum TLS support.

Start your free trial today to see how AppTrana’s hybrid post-quantum TLS support works.

Indusface
Indusface

Indusface secures the web, API, and AI applications of thousands of organizations across 95 countries. Backed by leading institutional investors, Indusface is recognized by Gartner, Forrester, and IDC for its innovation in application security and meets globally accepted security and compliance standards, including ISO 27001, SOC 2, PCI DSS, and GDPR. Its globally distributed cloud infrastructure spans Asia, the Middle East, Europe, and North America, enabling low-latency protection and regional data residency for enterprises worldwide.

Frequently Asked Questions

Harvest now, decrypt later (HNDL) is a threat model where an attacker intercepts and stores encrypted data today, without being able to read it, and holds onto it until a future capability, most likely a quantum computer, can break the encryption protecting it.

No. The capture step works with today’s technology. Only the decryption step depends on future hardware.

No. Recording encrypted traffic to decrypt later is a decades-old intelligence practice that predates quantum computing. A cryptographic flaw, a stolen key, or a leap in classical computing power could achieve the same result. Quantum computing matters because it is the first credible, dated horizon for breaking RSA and ECC at scale, which is why it has driven the current urgency and the NIST timelines.

It targets the key exchange. Most web and API traffic uses TLS, which negotiates a shared secret using RSA or ECDHE and then encrypts data with a cipher like AES. AES is not considered practically breakable by a quantum computer. The RSA or ECDHE key exchange that produces the AES secret is. Recovering that secret from recorded traffic exposes the entire session.

It protects against a stolen key today, since each session negotiates its own ephemeral secret. It does not protect against a quantum adversary, because Shor’s algorithm attacks the same discrete logarithm problem that ECDHE relies on, independent of whether the key was ever stolen.

Data that needs to stay confidential for years is most exposed, since its confidentiality window is more likely to overlap with the arrival of quantum-capable hardware. This includes financial records, healthcare and patient data, government and defense information, source code, and other long-lived intellectual property.

There is no single deadline. NIST’s FIPS 203, 204, and 205 standards were finalized in 2024, federal migration deadlines land in 2030 and 2035, and the EU’s coordinated roadmap follows a similar timeline. Enterprises outside those mandates typically feel the pressure earlier, through vendor requirements, cyber insurance questionnaires, and regulatory frameworks that reference NIST guidance.

Build a cryptographic inventory of where RSA, ECC, and Diffie-Hellman protect data across apps, APIs, VPNs, and third-party integrations, then prioritize the migration by how long that data needs to stay confidential.

Machine speed. Human certainty. No false positives.

Protect your web apps, APIs, and AI systems from day one. 5-minute onboarding. No tuning. No code changes.

Start Free Trial Explore AppTrana No credit card required.