up:: Quantum Risk Models MOC

Harvest Now, Decrypt Later (HNDL)

Harvest Now, Decrypt Later (HNDL) is the risk that an adversary records your encrypted data today, stores it, and decrypts it years later once a quantum computer can break the cryptography that protected it. The attacker never has to break anything now. They only need to capture the encrypted traffic, keep it, and wait.

The short version:

• HNDL is a confidentiality threat, and it’s the one quantum risk that is already live, even though the quantum computer that finishes it doesn’t exist yet.
• The exposure comes from public-key cryptography used to set up encrypted sessions: RSA, Diffie-Hellman, and ECDH. A future quantum computer running Shor’s Algorithm breaks all of them.
• It only matters for data whose secrecy has to outlast the migration. If a record must stay confidential for 15 years and a capable quantum computer might arrive in 10, harvested traffic protecting it is at risk right now.
• The fix is to replace the vulnerable key-establishment with ML-KEM, usually through a hybrid step, and to prioritize by data lifetime rather than by system.

Think of it as someone photographing your locked safe today and quietly waiting for the year a tool exists to open that exact model. The safe holds fine in the meantime. Then one day it doesn’t, and everything inside spills out, long after you assumed the moment of danger had passed.

Why does HNDL work if the quantum computer is years away?

HNDL exists because collection and exploitation don’t have to happen at the same time. The whole thing runs as a chain:

1. Data is encrypted today. You protect something in transit, at rest, or in an archive.
2. An adversary captures the encrypted form. They record network traffic, copy ciphertext, or steal encrypted backups, and they store it.
3. They can’t read it yet. At capture time, the cryptography still holds against every computer that exists.
4. A future capability shifts the balance. A cryptographically relevant quantum computer running Shor’s Algorithm can eventually break the public-key math that established the session keys.
5. The archived data becomes readable. Once the key-establishment falls, the stored ciphertext opens.
6. Confidentiality fails retroactively. The breach happens in the future, but it was made possible by an exposure in the past.

It means you can do everything right enough today and still lose the data later, purely because you waited too long to change the cryptography. HNDL is as much a data-lifetime governance problem as a cryptography problem.

Historical parallel: Venona

This already happened once, at scale, and it reshaped the Cold War.

Starting in 1943, American codebreakers began quietly intercepting and storing Soviet diplomatic and intelligence cables. The traffic was protected with one-time pads, which are mathematically unbreakable when used correctly, so at the moment of collection the messages were genuinely unreadable. The Soviets treated them as safe forever. Under wartime pressure, though, their pad manufacturers had duplicated pages, and a one-time pad reused even once stops being unbreakable. Beginning around 1946, Meredith Gardner and the team on what became the Venona project exploited that reuse and started reading the backlog. The work continued for decades, and the project didn’t formally close until 1980. Decrypts from the 1940s went on exposing agents, including the physicist Klaus Fuchs, years and years after the cables were sent.

That’s HNDL exactly: ciphertext harvested when nobody could read it, stored, and decrypted much later once a weakness was found and enough effort applied. Everyone whose name sat in that 1943 traffic assumed the moment of exposure had passed. It hadn’t. The only thing that’s changed for the quantum era is the weakness: instead of a pad-reuse mistake, it’s a quantum computer solving the math that public-key cryptography rests on.

Source: NSA, “Venona” historical release; Simon Singh, The Code Book, ch. on Venona.

What has to be true for HNDL to matter?

HNDL doesn’t apply to everything. Three conditions have to line up, and where they don’t, you can deprioritize with a clear conscience.

• The adversary can collect the encrypted material. Passive network interception, bulk collection, stolen encrypted backups, captured message archives. If they can’t reach the ciphertext, HNDL is irrelevant for that dataset.
• The data still matters later. HNDL only bites if the information is still sensitive when decryption becomes possible. Regulated records, health data, trade secrets, legal strategy, M&A activity, credentials with long operational life, and national-security communications all have long confidentiality lifetimes. Ephemeral chatter that stops mattering in a week mostly doesn’t.
• The protection depends on cryptography that will fall. In practice that means public-key confidentiality or key-establishment: RSA key transport, DH, ECDH and its ephemeral variants, and X25519.
• Migration won’t finish before the risk window closes. This is where Mosca’s theorem comes in: when the data’s confidentiality lifetime plus your migration time is greater than the time until a capable quantum computer arrives, HNDL is operationally live for you today.

What does HNDL apply to, and what does it not?

HNDL is specifically a confidentiality problem, the loss of secrecy for data collected now and read later. It’s worth separating cleanly from the other big quantum risk, which is about trust.

	Harvest Now, Decrypt Later	Non-HNDL
Core question	Can data encrypted now be read later?	Can trust or identity be forged once the math breaks?
Primary impact	Confidentiality loss	Forged signatures, fake certificates, trust collapse
When it bites	The moment matters now (collection is happening today)	Once a quantum computer is actually real
Cryptographic drivers	RSA key transport, DH, ECDH, X25519	RSA signatures, ECDSA, Ed25519, the certificate ecosystem
Primary replacement	ML-KEM	ML-DSA / SLH-DSA

The reason this split matters: the two risks carry different urgency. HNDL is a present-day prioritization problem because the harvesting is happening while you read this. Non-HNDL trust attacks can’t happen until the quantum computer exists, so they follow a different clock. Confusing the two leads teams to either panic about signature forgery that isn’t imminent or shrug off harvesting that is.

One caveat the standard framing misses: HNDL reaches past public-key. Some long-lived data protected by older symmetric constructions is also harvestable, because quantum-assisted attacks like Simon’s and the offline Simon’s algorithm can recover keys from certain legacy cipher designs on a nearer timeline than Shor’s. It’s a narrower exposure, most relevant to legacy IoT, OT, and old network gear, but worth a look if that describes your estate.

Source: Bonnetain et al., “Quantum Attacks Without Superposition Queries: the Offline Simon’s Algorithm,” ASIACRYPT 2019.

Which cryptography creates HNDL exposure?

HNDL is created by the parts of cryptography that protect secrets today but won’t keep protecting them tomorrow. The exposure is almost entirely in public-key key-establishment, not in the bulk encryption itself.

Replace these (they establish the session keys, and Shor’s algorithm breaks them):

• RSA in confidentiality or key-transport roles: legacy key transport, encrypted email workflows, any system that wraps a symmetric key with RSA.
• Diffie-Hellman: older VPN negotiation, legacy transport, aging appliance cryptography.
• ECDH and its ephemeral form ECDHE: modern session establishment, secure messaging, service-to-service transport, APIs, cloud and mobile traffic.
• X25519: modern curve-based transport and messaging key exchange.

The primary replacement for all of them is ML-KEM, usually reached through a hybrid step first.

Keep these (they aren’t the HNDL problem):

• AES and other strong symmetric encryption. Grover’s algorithm only halves symmetric strength, so a 256-bit key stays comfortably safe. AES is part of the mitigation, not the exposure.
• SHA-2 and SHA-3 hashing. Integrity primitives, not confidentiality drivers.
• ECDSA and Ed25519 signatures. These are a real quantum problem, but a trust problem (Non-HNDL), not an HNDL one.

HNDL exposure is measurable today

A 2026 survey of 8,443 real-world Nginx TLS configurations found that 28.9% relied on RSA key exchange with no forward secrecy. For those endpoints, the harvesting risk is already live: any session recorded today can be decrypted retroactively if the server’s long-term RSA key is ever recovered, whether by a classical attacker who exfiltrates the key or a future quantum attacker running Shor’s on it. Moving these to ephemeral key exchange, and then to hybrid PQC, is an immediate action independent of any quantum timeline.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

Where does HNDL exposure live in a real environment?

Harvesting risk concentrates wherever sensitive encrypted data can be collected now and still matters later. The usual zones, roughly in order of how often they get missed:

• Public-facing transport. HTTPS, public APIs, customer portals. A large, visible collection surface, and often ECDHE-based.
• Internal service-to-service traffic. Service mesh, east-west data-center traffic, cloud workload communication. Frequently overlooked, high in volume, and often carrying the most sensitive internal data.
• VPNs and private tunnels. Site-to-site and remote-access VPNs carry long-lived, high-value traffic, and legacy DH groups tend to linger here for years.
• Secure messaging and collaboration. Executive, legal, and investigative communications have long sensitivity horizons and high adversary interest.
• Backups and archives. Encrypted long-term storage has a huge confidentiality lifetime and usually poor cryptographic visibility. Old key-wrapping models persist quietly.
• Key-wrapping and data-access paths. The data itself may be under strong symmetric encryption, while the access path still relies on a vulnerable public-key mechanism. That path is the real exposure.

Finding these is detective work, and it’s the point of a cryptographic bill of materials. The common failure is to inventory certificates but never look at actual key-establishment behavior, or to inventory algorithms but never map data lifetime. Both leave the real HNDL exposure invisible.

Where an endpoint genuinely can’t be upgraded, legacy OT controllers, vendor-locked middleware, old VPN appliances, gateway or proxy-based approaches can establish quantum-resistant keys on the endpoint’s behalf as a compensating control, so a device’s limits don’t cap the whole estate’s posture.

Why does HNDL matter to the business?

Stripped of the cryptography, HNDL is a plain governance failure waiting to happen: the organization stored or transmitted sensitive data under protection with a known expiration horizon, an adversary preserved that data, and confidentiality is lost later because migration started too late. The consequences read like any breach, except the exposure was foreseeable and the window to prevent it was open for years:

• Future exposure of currently protected regulated data.
• Retroactive breach of legal, medical, financial, or strategic records.
• No honest way to promise long-term confidentiality for sensitive datasets.
• Higher cost of a rushed, late migration, and emergency archive re-encryption on top of it.
• Regulatory, contractual, and reputational fallout when a future compromise reveals that a known transition window was ignored.

The decision-useful questions for a leader are short: How long must this data stay secret? How easily can an adversary collect the encrypted form now? How long will migrating its cryptography take? And which systems create the biggest future breach if we wait? The honesty of those four answers is worth more than any tool.

There’s also a myth worth killing: that only nation-states can afford to harvest. Cloud cold storage now costs a fraction of a cent per gigabyte per month, so recording and warehousing large volumes of encrypted traffic sits well within reach of ordinary commercial actors. The barrier to harvesting is low and falling.

What replaces the vulnerable cryptography?

You don’t “replace HNDL.” You replace the mechanisms that create the exposure, in a sensible order.

• Swap the vulnerable key-establishment for ML-KEM. This is the single most important standard for HNDL, because HNDL is fundamentally about quantum-vulnerable public-key confidentiality.
• Keep strong symmetric encryption like AES-256 for the data plane. It’s doing fine.
• Move through hybrid rather than all at once. Most environments can’t jump straight from ECDHE or X25519 to ML-KEM-only transport. Running classical and post-quantum key-establishment together, and deriving the shared secret from both, keeps you safe even if one side has a flaw. In TLS, that’s hybrid key exchange (X25519 with ML-KEM).
• Build for crypto-agility so the next change is a configuration update, not a rebuild. The Isogeny family’s collapse in 2022 is the reminder that “post-quantum” doesn’t mean “proven safe forever.”
• Re-encrypt or rewrap long-lived stored data where the wrapping or access path depends on vulnerable public-key mechanisms. Archives are where confidentiality lifetime is longest and visibility is worst.

How urgent is my exposure?

Not every HNDL exposure is equally pressing, and a defensible first pass doesn’t need a full quantitative model. A five-dimension read, each scored 1 (low) to 5 (high), sorts a migration queue quickly:

• Confidentiality lifetime. 1 = short-lived; 5 = must stay secret for many years.
• Collection likelihood. 1 = hard to reach; 5 = easy to capture at scale.
• Cryptographic exposure. 1 = already PQC-mitigated or not in a vulnerable key path; 5 = directly relies on a DH / ECDH / RSA confidentiality path.
• Migration difficulty. 1 = easy to change; 5 = hard vendor, protocol, or legacy dependency.
• Business blast radius. 1 = local, low impact; 5 = enterprise-wide, regulated, customer-facing, crown-jewel data.

Add the five, and a rough triage falls out: 20–25 is an immediate priority, 15–19 is early-roadmap, 10–14 is medium, and 5–9 is monitor-and-revisit. The scoring is deliberately coarse. Its job is to force the two questions vendors skip, how long the data must stay secret and how reachable it is, to the front of the conversation, ahead of the algorithm details.

The clock underneath all of this is Mosca’s theorem, which turns an abstract industry timeline into your own deadline. The exposure types tell you what kind of risk, blast radius tells you how bad, and Mosca tells you when. Together, that’s a prioritized queue, which is where Doing the Work picks up.

Common misconceptions

• “HNDL means everything is already broken.” No. It means some data collected now may become readable later. The urgency is about which data, not about a break today.
• “If we use modern TLS, we’re safe.” Not necessarily. Modern classical TLS usually still relies on ECDHE or X25519, both quantum-vulnerable to harvesting.
• “HNDL is the same as certificate forgery.” Different risk. Forgery is a Non-HNDL trust problem, on a later clock.
• “Strong symmetric encryption solves HNDL.” Not if the session keys or the wrapping path depend on quantum-vulnerable public-key mechanisms.
• “Only governments care about HNDL.” Any organization with long-lived sensitive data should, and cheap storage means any motivated actor can harvest.
• “HNDL is just a theoretical future issue.” That’s the exact wrong framing. The collection is happening now, which makes it a present-day prioritization problem for long-lifetime data.

---

Everything here is the map, given freely. When your team needs the version built and quantified for your own environment, defensible to your own regulator, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.