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

Adversaries are stockpiling encrypted traffic today and betting on quantum computers to open it later. NIST has finalized the replacement algorithms. The question now is whether organizations will migrate before it matters.

There's an uncomfortable truth embedded in the way public-key cryptography works: the security of an encrypted message depends on two things — the algorithm holding it, and the computational power available to attack it. For decades, the second factor was so limited that it barely mattered. RSA-2048 would take longer to crack by brute force than the universe has existed. That math is changing.

Not yet in a dramatic, visible way. No quantum computer capable of breaking production-grade RSA or elliptic curve keys exists today, and credible estimates put the arrival of such a machine somewhere in the 2030–2035 window, though the timeline remains genuinely uncertain. But the threat doesn't require Q-Day to have already arrived. It only requires that adversaries have the foresight to be patient.

That's the core insight behind harvest-now, decrypt-later, and it's why the cryptographic community — and increasingly, government policy — treats this as an active problem rather than a future one.

What Harvest-Now, Decrypt-Later Actually Means

The attack strategy is conceptually straightforward. An adversary — most plausibly a nation-state actor with the resources and long-term interest to justify it — intercepts encrypted network traffic and stores it. They don't need to read it now. They just need to hold onto it until a sufficiently powerful quantum computer is available, then apply Shor's algorithm to recover the private keys and decrypt the historical traffic retroactively.

This works because the ciphertext doesn't expire. A TLS session from 2024 capturing a diplomat's communications, a financial institution's internal data, or intellectual property from a defense contractor will be just as theoretically decryptable in 2032 as it was the day it was captured. The underlying plaintext doesn't change.

What makes HNDL particularly troubling is that it shifts the threat horizon. Normally, organizations think about cryptographic risk in terms of present capability: is this encryption good enough to stop an attack today? But HNDL forces a different question: is this encryption good enough to protect data that needs to remain confidential for the next 10–15 years? For most organizations, the honest answer is no — not with current algorithms.

The data that matters most for HNDL is anything with a long confidentiality requirement: diplomatic communications, classified government records, medical records, financial transactions, intellectual property, or long-term contracts. If that data is being transmitted today with RSA or ECDH-based key exchange, it's a candidate for retroactive decryption. For defenders focused on detecting active intrusions, HNDL is unusual — there may be no detectable intrusion happening at all. Packet capture at a network choke point produces no forensic trail inside the target organization.

Why RSA and ECC Are Vulnerable — and Symmetric Crypto Isn't

RSA's security rests on the difficulty of factoring large numbers. Elliptic curve cryptography (ECC) depends on the discrete logarithm problem. Both problems are computationally hard for classical computers. A machine powerful enough to run Shor's algorithm on sufficiently large qubits could solve either problem in polynomial time — exponentially faster than the best classical approaches.

Symmetric algorithms like AES and SHA-2 face a different quantum threat. Grover's algorithm can search through possible keys quadratically faster than classical brute force, which effectively halves the security strength. AES-256 drops to roughly 128-bit security under Grover's attack — still considered adequate. So AES-256 and SHA-384 remain in NIST's recommended post-quantum suite without replacement.

The actual vulnerability is asymmetric cryptography, specifically the key exchange and digital signature mechanisms that underpin TLS, certificate authorities, SSH, code signing, and practically everything else in a modern PKI infrastructure. If your TLS session uses ECDH for key exchange, the keys protecting that session are vulnerable to a future quantum attack.

NIST's Answer: The Post-Quantum Cryptography Standards

After an eight-year global competition that began in 2016, NIST finalized its first three post-quantum cryptography standards on August 13, 2024 [1]. The algorithms are designed to resist attacks from both classical and quantum computers, and they replace the asymmetric schemes where the quantum vulnerability actually lives.

The three finalized standards are:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber): the primary replacement for RSA and ECDH in key exchange. This is what protects TLS session keys.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium): the primary replacement for RSA and ECDSA signatures. Covers code signing, certificate chains, identity verification.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+): a conservative backup signature scheme, based on hash functions rather than lattice problems, providing structural diversity if lattice-based schemes are later found vulnerable.

NIST expanded the suite further in March 2025, selecting HQC (Hamming Quasi-Cyclic) as an additional key encapsulation mechanism — a code-based alternative to ML-KEM, added specifically to diversify the algorithmic foundation in case lattice math turns out to have an undiscovered weakness [2]. A fourth signature standard, FIPS 206 (FN-DSA, based on FALCON), is still in development.

NIST mathematician Dustin Moody, who heads the PQC standardization project, said plainly at the time of publication: "We encourage system administrators to start integrating them into their systems immediately, because full integration will take time." [3]

NIST Post-Quantum Standards at a Glance

The Migration Timeline — and Why the Deadlines Are Real

NIST's transition roadmap, outlined in NIST Internal Report 8547 (draft released November 2024), sets two federal milestones: quantum-vulnerable algorithms deprecated for federal systems by 2030, and fully disallowed by 2035 [4]. That's not a soft recommendation. OMB guidance has directed federal agencies to align their migration plans to these dates, treating 2035 as a binding target.

For national security systems specifically, NSA's CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is more aggressive. New NSS acquisitions must support quantum-resistant cryptography by 2027, and full transition is expected by 2030 [5]. This deadline extends in practice to federal contractors and organizations handling federal data.

Why do the timelines matter so much if a cryptographically relevant quantum computer might not appear until 2030–2035? Because migration isn't instant. The last time cryptographic standards shifted at this scale, NIST has noted it took roughly a decade. Certificate authorities need updating. Hardware security modules need firmware. TLS libraries need updating in every application that links against them. Embedded devices — industrial controllers, medical equipment, network hardware — may not support algorithm updates at all and require replacement. The migration surface is enormous.

For organizations managing vulnerability management programs, this is a different kind of problem than a typical CVE patch cycle. There's no CVSS score and no defined exploit. But the exposure window is determined not by attacker capability today, but by the sensitivity and longevity of the data being protected.

How Organizations Are Actually Approaching This

The practical challenge isn't selecting the right algorithm. That decision has largely been made by NIST. The harder problem is figuring out where your organization currently uses quantum-vulnerable cryptography and building a rational migration sequence.

A cryptographic inventory is the necessary starting point — a systematic catalog of every protocol, certificate, hardware module, and application that uses asymmetric cryptography. This sounds more tractable than it is. In large organizations, cryptographic dependencies are embedded in layers of middleware, legacy appliances, cloud services, and third-party software that may not expose their crypto stack to easy auditing. Discovering all of it takes time and tooling.

From that inventory, migration priority follows logically from data sensitivity and longevity. Long-lived, high-value data protected by asymmetric key exchange — the stuff that would genuinely matter if decrypted in 2032 — should be prioritized first. Systems processing diplomatic, financial, health, or national security data have a shorter fuse. Systems storing session data or low-sensitivity logs can be addressed later in the queue.

Most implementation guidance recommends a hybrid approach during the transition period: combining classical algorithms (ECDH, RSA) with post-quantum algorithms (ML-KEM) in a single key exchange. The logic is straightforward — a hybrid is secure against a classical attacker even if the PQC algorithm turns out to have a flaw, and it's secure against a quantum attacker even if the classical algorithm is eventually broken. Google, Cloudflare, and several browser vendors began piloting hybrid post-quantum TLS key exchange in 2024, using X25519 + ML-KEM combinations in production traffic. Organizations that sit behind CDNs with this capability may already have partial protection for their TLS connections without any action on their part.

Hardware security modules (HSMs) and PKI root infrastructure typically require the most lead time. Certificate authorities need to migrate their root and intermediate hierarchies. HSMs need firmware updates that may not be available for older models, requiring hardware replacement. These dependencies tend to sit at the top of migration roadmaps precisely because everything downstream depends on them. Identity and authentication systems are in the same category — once certificates use post-quantum signatures, the verification chain needs to support them end-to-end.

The Things This Article Can't Tell You

The timing of Q-Day is genuinely uncertain. Estimates of 2030–2035 from cryptography researchers reflect current understanding of quantum hardware progress, but quantum computing has repeatedly surprised both optimists and skeptics. Some researchers think the window is longer; others think nation-state programs may be further along than publicly visible commercial development suggests. There's no consensus number that should be treated as authoritative.

Whether large-scale HNDL collection is actually happening at the volume some threat briefings imply is also uncertain. The collection infrastructure would need to be enormous to capture meaningful volumes of targeted traffic. Nation-states with the motive, budget, and signals intelligence reach to attempt this — specifically adversaries like Russia and China — plausibly have some version of this capability. But the specific scale, targeting, and current status of any such programs aren't publicly documented with the kind of evidence that would turn this into a confirmed fact rather than a well-founded concern.

What can be said with confidence is that the cryptographic standards to protect against this threat now exist, governments are setting firm migration deadlines, and the migration itself is complex enough that organizations which start late will face a compression problem when the window closes.

Defender Takeaway

Post-quantum migration is a program, not a patch. The right mental model is closer to a PKI overhaul than a software update cycle. That framing helps with prioritization: start with cryptographic discovery, move to risk-ranked migration planning, pilot hybrid schemes in low-risk systems, and work backward from the hardest dependencies — HSMs, CA hierarchies, embedded devices.

For most commercial organizations, the 2030 deprecation deadline in NIST IR 8547 is the practical planning horizon, not 2035. That's roughly three to four years from now, which sounds comfortable until you account for the typical pace of enterprise cryptographic change. Organizations that handle federal data, work as defense contractors, or operate in regulated sectors should already be conducting cryptographic inventories and engaging vendors about PQC roadmaps.

One aspect that gets overlooked: updating protocols is only part of the problem. Zero trust architecture implementations that depend heavily on certificate-based identity verification will need to account for the certificate authority migration. Any component that validates signatures needs to be capable of validating post-quantum signatures once the transition happens — otherwise the chain breaks. Crypto agility, the ability to swap algorithms without rewriting applications, is the architectural property that makes this manageable rather than catastrophic.

The algorithms are ready. The standards exist. The timeline is set. What remains is the organizational work — and that's the part that tends to take longer than anyone initially estimates.

Sources & References

1. NIST CSRC — Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography (August 13, 2024)
2. NIST CSRC — Post-Quantum Cryptography Standardization Project (includes HQC selection, March 2025)
3. HPCwire — NIST Releases First 3 Finalized Post-Quantum Encryption Standards (August 13, 2024) — covers Dustin Moody statement
4. quantum.gov — NIST Releases Draft Report on Transition to Post-Quantum Cryptography Standards (November 12, 2024; covers NIST IR 8547)
5. The Quantum Insider — Quantum Security Deadlines: Government and Industry Migration Timelines (covers NSA CNSA 2.0 and federal contractor scope)