Harvest Now, Decrypt Later: The Encryption Threat That's Already Here

Quantum computers can't break your encryption yet. That's not stopping anyone from collecting it anyway. Here's what HNDL actually means for your organization, who's behind it, and what a rational response looks like in 2026.

Harvest Now, Decrypt Later: The Encryption Threat That's Already Here

The clock has already started

There's a category of attack in security where the hard part isn't the attack itself, it's the patience. Harvest now, decrypt later (HNDL) falls squarely in that category. The concept is simple enough: intercept and archive encrypted network traffic today, store it indefinitely, and decrypt it once a sufficiently powerful quantum computer exists. No zero-days required, no exploitation, just collection, storage, and patience, all of which are well within the capabilities of any well-funded nation-state or serious criminal organization.

The reason this matters right now is that the harvesting phase is already in progress. The decryption phase is what's coming later. Those are two separate problems on two separate timelines, and conflating them leads organizations to either panic prematurely or dismiss the whole thing as a distant concern. Neither response is particularly useful, because if you're encrypting data today that needs to stay secret for the next five to ten years, the relevant question isn't whether quantum computers exist yet, it's whether the data you're protecting right now will still be safe when they do.

What quantum computers actually threaten

Most of today's public-key cryptography (RSA, ECC, Diffie-Hellman) depends on mathematical problems that are computationally hard for classical computers to solve. Factoring large integers is the foundation of RSA, and a classical machine trying to crack a 2048-bit RSA key would need more time than the age of the universe, which is not hyperbole but simply the math that modern secure communication is built on.

Quantum computers change the equation for specific problems. Shor's algorithm, running on a sufficiently large fault-tolerant quantum computer, can factor large integers in polynomial time, which is not incrementally faster but an entirely different class of solution. When quantum computers reach that capability, RSA-2048 and elliptic curve cryptography become breakable. Symmetric encryption like AES-256 is less threatened, since Grover's algorithm gives quantum computers a quadratic speedup that effectively halves the key strength but can be addressed simply by doubling key sizes. The harder and more urgent problem is asymmetric cryptography: the TLS handshakes protecting your web traffic, your API calls, your VPN tunnels, your email in transit, where everything currently relying on RSA or ECC key exchange is in scope.

Headlines periodically claim that Chinese researchers have already broken RSA, and the reality is considerably more boring than those headlines suggest. The research is real and worth watching, but what's actually been demonstrated is factoring keys far smaller than anything used in production, and the researchers themselves have described it as incremental progress. RSA-2048 is nowhere close to broken, and anyone telling you otherwise is either misinformed or selling something.

Who is actually hoovering up your data

The NSA said publicly in 2021 that adversaries are collecting encrypted data now, waiting for quantum computers to become capable enough to decrypt it. That's the US government's own signals intelligence agency describing an active adversarial strategy in public documentation. The UK's NCSC made a similar observation in its 2023 Annual Review, and a joint factsheet from CISA, NSA, and NIST issued the same year urged critical infrastructure organizations to begin preparing, premised explicitly on the assumption that this collection is ongoing.

The primary suspects are the signals intelligence programs of major nation-states. China's intelligence apparatus has dedicated substantial national resources to quantum computing, and Russia's intelligence services have similar bulk-collection capabilities. And if we're being honest about the Snowden disclosures, the United States almost certainly belongs on that list too. The NSA built a data center in Bluffdale, Utah that opened in 2014 and has been widely reported as purpose-built to archive vast quantities of intercepted communications. Intelligence agencies don't build multi-billion dollar storage facilities on speculation.

Whether any of this collection is happening in a deliberate, HNDL-specific way is impossible to confirm from the outside. What we do have is a pattern that security researchers find difficult to dismiss. State-owned telecoms in both China and Russia have been involved in repeated BGP routing incidents in which internet traffic from major networks found its way through their infrastructure on the way from point A to point B. Each individual incident has a plausible innocent explanation, but the cumulative pattern is harder to wave away. As Justin Sherman of the Atlantic Council's Cyber Statecraft Initiative noted of the 2020 Rostelecom incident, in which traffic from Google, Amazon, Facebook, and over 200 other networks was briefly routed through Russian state infrastructure: "this event could be nothing more than an accident," but the recurring nature of these incidents across both countries "should at the very least raise eyebrows." It is not proof. It is a pattern, and patterns are what intelligence assessments are made of.

When does Q-Day actually arrive

The consensus range among cryptographers and quantum researchers puts a cryptographically relevant quantum computer somewhere between 2030 and 2035. Some estimates extend further out, while a few push earlier. Gartner warned that quantum computing will begin weakening asymmetric cryptography by 2029, with full vulnerability arriving around 2034. The NSA's planning posture tells a similar story: its CNSA 2.0 framework requires all national security systems to complete equipment transitions by December 31, 2030, which is not the timeline of an agency that thinks the threat is comfortably distant.

What's shifted recently is that the estimated qubit requirements for breaking RSA have compressed significantly. Research published between 2025 and early 2026 reduced estimates of the physical qubits needed to break RSA-2048 from around 20 million down to potentially as few as 100,000 under certain architectural approaches. The engineering challenges haven't disappeared (error correction, qubit coherence, and fault tolerance remain hard problems), but the goalposts have moved in a direction that should make complacency uncomfortable.

Google's Willow chip demonstrated in late 2024 that increasing the qubit count in an error-correcting code actually decreases error rates, which was the first time that fundamental requirement for practical quantum computing had been achieved in a real system. Microsoft's topological qubit approach promises inherently lower error rates through a different architectural path. Global investment in quantum computing exceeded $40 billion cumulatively by 2025. The pace of progress is real.

The planning framework cryptographers use here is Mosca's inequality: if your data needs to remain confidential for X years, and your migration will take Y years, you need to start now if X plus Y exceeds your estimate of time to a capable quantum computer. For healthcare records with 20-year retention requirements, or financial records sitting under 5-7 year regulatory retention rules within a plausible 2030 Q-Day window, the arithmetic is uncomfortable.

Does your company actually need to worry

The honest answer is that it depends on your data, not your size. The HNDL threat is not really about transaction processing or ephemeral communications. It's about data with a long confidentiality shelf life, and the question worth asking is how long your most sensitive data needs to remain secret.

Intellectual property with competitive value that lasts more than five years is clearly in scope. So are M&A plans, product roadmaps, source code, and proprietary algorithms. Healthcare records carry lifetime confidentiality obligations, and genomic data never expires. Financial records under MiFID II (five-year retention) or Dodd-Frank (five to seven years) sit squarely within the plausible decryption window. Government contractor data and anything touching CUI is essentially the intended target. Authentication credentials and session logs matter if your users' accounts have long-term value to an attacker.

A Series A SaaS startup processing payments and storing nothing sensitive long-term is probably not a priority HNDL target. A healthtech company with a genomic database is a completely different calculation. A compliance software vendor holding five years of sensitive client audit data is worth thinking carefully about.

NIST finished its work in 2024. Most enterprises haven't started theirs.

In August 2024, NIST finalized three post-quantum cryptography standards after an eight-year international competition: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). NIST's guidance is unambiguous about what to do with them: start now.

The infrastructure layer is already moving at scale. Cloudflare has been deploying hybrid post-quantum key agreement since 2022, and as of late 2025 over half of human-initiated traffic on its network uses post-quantum key exchange. Google has integrated PQC across Chrome and its internal services. Apple introduced post-quantum rekeying in iMessage through its PQ3 protocol. Akamai began rolling out hybrid ML-KEM as the default for customer connections in early 2026. AWS offers hybrid post-quantum TLS on its load balancers, and Google Cloud launched quantum-safe key encapsulation in Cloud KMS preview in October 2025.

What's lagging is enterprise adoption, and more specifically the foundational work that makes migration possible at all: cryptographic inventory. Most organizations genuinely don't know where RSA and ECC are used across their systems. You can't migrate what you haven't catalogued, and that inventory work is harder than it sounds in complex environments with years of accumulated technical debt.

What a rational response looks like in 2026

The migration timeline for most organizations runs two to five years. Starting in 2026 is not too late, but it's not early either, and here's what a grounded approach looks like without the vendor theater.

  • Start with inventory. Before migrating anything, you need to know what you're migrating from, which means identifying every place your systems use RSA, ECC, or Diffie-Hellman: TLS configurations, certificate authorities, code signing, API authentication, token signing (JWT, SAML), HSMs, VPNs. This is genuinely hard in complex environments and consistently takes longer than anyone budgets for it.
  • Prioritize by data longevity rather than technical complexity. TLS handshakes protecting long-lived sensitive data matter more than ephemeral session tokens. A healthcare application encrypting genomic records deserves earlier attention than a marketing analytics dashboard, regardless of which migration is technically easier.
  • Deploy hybrid key exchange on new TLS implementations now. The hybrid approach (combining classical ECDH with ML-KEM) means an attacker must break both algorithms simultaneously, and it's deployable today without waiting for certificate infrastructure to catch up. It provides meaningful HNDL protection for traffic going forward and is not a substitute for full migration, but it closes the collection window on future communications while you work through the harder problems.
  • Build crypto-agility into anything new you're writing. Systems built today with hardcoded RSA-2048 will require full code rewrites to migrate. Systems built with algorithm-agile design (where cryptographic choices live in configuration rather than logic) can migrate by updating parameters. If you're writing new systems in 2026, embedding classical algorithms in ways that require a full rebuild in three years is an avoidable mistake.
  • Understand clearly that PQC migration doesn't retroactively protect data that's already been harvested. If your traffic was intercepted before you deployed post-quantum key exchange, that ciphertext is already sitting in someone's archive. Migration protects future traffic. For historical data with long confidentiality requirements, the exposure window is already open, which is an argument for data minimization and understanding what you actually hold, not an argument against migrating.

What you should actually do about this

Is post-quantum encryption ready for use today? For key exchange, yes. ML-KEM is standardized, production-deployed at hyperscale, and available in hybrid mode through most major cloud providers and CDNs. There's no good reason not to use it for new projects. Post-quantum certificates are a different story, since the first PQC certificates likely won't arrive until later in 2026 and broad browser trust probably doesn't land until 2027.

Should you update? If you hold long-retention sensitive data, operate in healthcare or financial services, or have federal contracts, the inventory work should be underway now. If you're a small SaaS without sensitive long-retention data, the immediate risk is low, but the infrastructure work will eventually become mandatory as providers default to PQC and compliance regimes catch up. Getting the inventory done now costs far less than doing it under time pressure in 2029.

What actually worries me more than the quantum computer itself is the migration. TLS 1.2 adoption took years after TLS 1.3 was available. SHA-1 deprecation dragged on long past the point where everyone knew it should happen, and PQC will touch far more systems than either of those transitions, including embedded firmware, IoT devices, industrial controls, and legacy software with no upgrade path. Meanwhile, the collection is ongoing and the timeline to Q-Day keeps compressing in one direction, which means every day of delay is another day of traffic entering someone's archive.