up:: Quantum Risk Models MOC

HNDL vs Non-HNDL

HNDL is the risk that an adversary records encrypted data today and reads it years later once a quantum computer breaks the key establishment that protected it. Non-HNDL is the risk that the same machine forges signatures, certificates and identities at the moment it exists. The difference that matters operationally is the clock: HNDL exposure accumulates every day that collectible traffic keeps flowing, while Non-HNDL exposure begins on a single future date and is zero until then.

Both are consequences of Shor’s algorithm breaking public-key mathematics, and a complete migration closes both. Sequencing them correctly is what separates a program that protects the right things first from one that spends its early years on the half that is not bleeding yet.

The short version:

• HNDL attacks confidentiality, Non-HNDL attacks trust. One asks whether data encrypted now can be read later. The other asks whether identity, code and certificates can be forged once the math falls.
• HNDL is live today and Non-HNDL is not. Harvesting requires only a collection path and storage, both of which exist. Forgery requires a cryptographically relevant quantum computer, which does not.
• The attacker’s pre-positioning cost is the sharpest distinction. HNDL requires an adversary to have captured your specific ciphertext in advance. Non-HNDL requires nothing in advance, because the public keys targeted are already published by design.
• They replace different algorithms. HNDL closes by moving key establishment to ML-KEM. Non-HNDL closes by moving signing to ML-DSA or SLH-DSA. Completing one leaves the other fully exposed.
• US federal policy stages them a year apart, putting post-quantum key establishment on priority systems by 2030 and post-quantum digital signatures on them in 2031, which is the clock difference written into a schedule.

Picture two failures in the same building. Someone has been quietly photographing documents through the window for years, and those photographs already exist whether or not you ever fit blinds. Separately, a master key that opens every door in the city is going to become manufacturable on some future date, and until that date arrives nobody can open anything. Fitting blinds stops new photographs and does nothing about the old ones. Changing every lock before the master key exists prevents the master-key failure entirely, and the lock change takes years.

What is the difference between HNDL and Non-HNDL?

HNDL is a confidentiality threat whose exposure is accumulating right now, because an adversary can record encrypted traffic today and decrypt it after a quantum computer arrives. Non-HNDL is an integrity and authentication threat whose exposure begins only when that machine exists, because forging a signature requires the machine at the moment of the attack rather than beforehand.

The distinction decides sequencing. An organization that migrates its signatures first has protected against something that cannot happen yet while continuing to leak data that is being collected today. An organization that migrates key establishment first has stopped the accumulating loss and still has to finish the signature work before the machine arrives, which is a longer program than most teams expect.

What is HNDL?

Harvest Now, Decrypt Later is the risk that an adversary captures encrypted material today, stores it, and decrypts it later once a quantum computer can break the public-key cryptography that established the session keys. Collection and exploitation are separated in time, so the attacker never needs to break anything at the moment of capture.

Three conditions have to line up for it to matter. The adversary has to be able to collect the ciphertext, whether by passive network interception, bulk collection, or stolen encrypted backups. The data has to still be sensitive when decryption becomes possible. And the protection has to rest on cryptography that will fall, which in practice means RSA key transport, Diffie-Hellman, ECDH and its ephemeral variants, or X25519.

The primary replacement is ML-KEM, usually reached through a hybrid step.

What is Non-HNDL?

Non-HNDL is the class of quantum attacks that need a working quantum computer at the moment of attack and that target trust rather than secrecy: forged signatures, fraudulent certificates, impersonated identities, and malicious code that verifies as legitimate. Shor’s algorithm computes a private signing key from its matching public key, and public keys are published by design in X.509 certificates, JWT signing keys and code-signing certificates.

Its scope is every system that relies on classical signatures for trust: the whole public TLS certificate ecosystem plus enterprise, government and code-signing PKI, SAML assertions and JWT access tokens, software and firmware supply chains, and transaction signing in financial and government systems.

Its worst case is PKI collapse, where a compromised root certificate authority key undermines every certificate beneath it at once. The replacements are ML-DSA for general-purpose signing, SLH-DSA for stateless or very long-lived signatures, and FN-DSA where signature size and speed are constrained.

HNDL vs Non-HNDL at a glance

Dimension	HNDL	Non-HNDL
Security property attacked	Confidentiality	Integrity and authentication
Core question	Can data encrypted now be read later?	Can trust or identity be forged once the math breaks?
When exposure begins	Already begun, on any traffic being collected today	On the date a CRQC exists
When the attack executes	After the machine arrives, against material already held	At and after the machine’s arrival, in real time
What the attacker needs in advance	Your specific ciphertext, captured and stored	Nothing. The target public keys are already published
Attacker’s pre-positioning cost	A collection path plus storage, at cold-storage prices	Zero
Cryptography that creates it	RSA key transport, DH, ECDH, X25519	RSA signatures, ECDSA, Ed25519, the certificate ecosystem
Primary NIST replacement	ML-KEM	ML-DSA and SLH-DSA
US federal milestone	Post-quantum key establishment on priority systems, M-26-15 Phase 3, 2028 to 2030	Post-quantum digital signatures on priority systems, M-26-15 Phase 4, 2031
Worst case	Retroactive loss of confidentiality across every archived session	PKI collapse, arbitrary privilege across a whole trust domain
Can migration undo past exposure?	No. Material already harvested stays harvested	Partly. Migration prevents future forgery, and artifacts already signed under classical keys stay vulnerable
What prioritizes it	Data confidentiality lifetime	Blast radius of the signing key
Reaches beyond public-key?	Yes, narrowly. Some legacy symmetric constructions are exposed to Simon’s and the offline Simon’s algorithm	No. It rests on public-key signature math

Source: OMB, M-26-15, “Execution of the Migration to Post-Quantum Cryptography,” June 24, 2026, §3.D, M-26-15 PDF.

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

How do they actually differ?

1. The clock runs in opposite directions. HNDL exposure is a stock that grows: every day of collectible traffic adds to a pile an adversary already holds, and the pile never shrinks. Non-HNDL exposure is a step function sitting at zero until a machine exists, then jumping to its full value at once. A year of delay adds a year of harvested material to the HNDL pile and changes nothing about Non-HNDL, right up until the delay overruns the machine’s arrival.

2. Pre-positioning cost is the cleanest technical separator. For HNDL an adversary must have been in a position to capture your particular traffic, which bounds the exposure to what actually crossed a collectible path. For Non-HNDL there is nothing to pre-position, because the attacker works from public keys that are published deliberately, so exposure is not bounded by whether anyone was watching you.

3. Remediation asymmetry cuts both ways. Migrating key establishment protects future sessions and does nothing for material already recorded, so HNDL has a permanently unrecoverable tail. Migrating signatures prevents forgery outright if it completes before the machine arrives, which makes Non-HNDL fully preventable in a way HNDL is not, though software and firmware already signed under classical keys stay in circulation and keep verifying.

4. They are prioritized on different variables. HNDL is triaged by how long data has to stay secret, which is a governance question about records and retention. Non-HNDL is triaged by blast radius, meaning how many relying parties trust a given signing key. A dataset with a 30-year confidentiality requirement and a root CA key are both top priority, for reasons that share no arithmetic.

5. The inventory scopes differently. HNDL work follows the transport and storage paths where key establishment happens. Non-HNDL work follows signing infrastructure, which routinely sits with different teams: identity platforms owning JWT and SAML signing keys, and release engineering owning code-signing and firmware-signing keys. A CBOM scoped to TLS endpoints captures a meaningful share of the first and very little of the second.

Where do they agree?

1. Same root cause. Both follow from Shor’s algorithm solving the integer-factorization and discrete-logarithm problems that RSA and elliptic-curve cryptography rest on. They are two consequences of one mathematical break rather than two independent threats.

2. Same standards family and the same migration machinery. FIPS 203, FIPS 204 and FIPS 205 came out of one NIST process, and both migrations need the same inventory, the same vendor conversations and the same crypto-agility foundation.

3. Bigger classical keys help neither. Moving RSA-2048 to RSA-4096 buys almost nothing against Shor’s algorithm in either direction, because the algorithm’s advantage is structural rather than a matter of brute-force margin.

4. Both carry an irreversible component. Harvested ciphertext stays harvested, and signed artifacts already in the field keep verifying. Revoking a key after the fact leaves the signatures that already validated exactly as they were.

5. Both are governed by the same deadlines and the same lead-time problem. Migration duration scales with estate size, running 5 to 7 years for a small enterprise, 8 to 12 for a medium one and 12 to 15 for a large one, and neither lane can be compressed into the year before a machine appears.

Source: Robert Campbell, “Enterprise Migration to Post-Quantum Cryptography: Timeline Analysis and Strategic Frameworks,” Computers 2026, 15(1), 9, Table 2, doi.org/10.3390/computers15010009.

When is HNDL the right frame?

HNDL is the correct lens whenever the question is about data whose secrecy has to outlast the migration. Regulated records, health data, biometric identifiers, trade secrets, legal strategy, merger activity, credentials with long operational life, and national-security communications all clear the bar. The reasoning is Mosca’s theorem: when a dataset’s confidentiality lifetime plus the migration time exceeds the time until a capable quantum computer arrives, the exposure is live today.

It is the wrong lens for information that stops mattering quickly. Traffic whose sensitivity expires in days carries little HNDL exposure regardless of how it is encrypted, and treating it as urgent consumes budget that the long-lived material needs.

When is Non-HNDL the right frame?

Non-HNDL is the correct lens whenever the question is about what other parties trust. Root and intermediate certificate authority keys, identity-provider signing keys, code-signing and firmware-signing certificates, and any signature a third party relies on to decide something is genuine all sit here. The prioritizing variable is how much collapses if one key falls.

It is also the correct lens for systems with no confidentiality exposure at all. A sensor network that publishes unencrypted readings but authenticates its firmware updates carries no HNDL risk and substantial Non-HNDL risk, and an inventory built only around harvesting would score it as safe.

Why do people confuse them?

The confusion is largely linguistic. Public coverage compresses both into “quantum computers will break encryption,” and the word encryption colloquially covers both the key exchange that establishes a session and the signature that proves who established it. Because a single algorithm breaks both, and because both are fixed by schemes from the same NIST standardization process, the two read as one problem with one deadline.

The practical cost of the conflation runs in both directions. Teams that hear only the harvesting story treat signature migration as something to do later and discover that PKI has the longest lead time in the estate. Teams that hear only the forgery story conclude the whole subject is a future problem, because no quantum computer exists, and keep leaking collectible traffic in the meantime. Holding both, with their different clocks, is what produces a correctly ordered program.

Which one should be migrated first?

The general answer is key establishment, and the reason is the clock rather than a judgment that confidentiality outranks trust. Harvesting is happening while the decision is being made, so every month of delay is a permanent addition to what an adversary holds. Signature forgery adds nothing during the same month.

That ordering is what US federal policy encodes. OMB M-26-15 Phase 3 targets post-quantum key establishment on priority systems from 2028 to 2030, and Phase 4 targets post-quantum digital signatures on those systems in 2031, a deliberate stagger of a year. The reasoning behind the split, and the caution that a deliberate lane still has to start early because it ends at a cliff rather than a runway, is covered at The Two-Lane Split.

The ordering reverses for specific estates. An organization whose data has short confidentiality lifetimes and whose signing keys are trusted by millions of external parties has more to lose from a trust failure than from harvesting, and the longest-lead-time item in almost every estate is the root certificate authority, which argues for opening that work early even while executing key establishment first.

Common misconceptions

1. “Non-HNDL isn’t urgent because the machine doesn’t exist.” The attack is not urgent and the migration is, because PKI migration takes years and has to complete before the machine arrives. Migration lead time, rather than attack timing, is what makes the work current.

2. “HNDL only matters if you’re a government.” It matters for any organization holding data with a long confidentiality life on a collectible path, which includes health records, biometric identifiers, trade secrets and legal strategy in ordinary commercial settings.

3. “Migrating to ML-KEM closes our quantum exposure.” It closes the harvesting half and leaves every signing key exposed. The two migrations are separate programs against different algorithms.

4. “We can wait and fix it when a quantum computer appears.” Neither risk permits that. Data already harvested is unrecoverable no matter when the fix lands, and a signature migration started at the machine’s arrival finishes years too late.

5. “HNDL is purely a public-key problem.” Mostly, and narrowly not. Some legacy symmetric constructions are exposed to Simon’s and the offline Simon’s algorithm on a nearer timeline, which is most relevant to legacy IoT, operational technology and old network gear.

6. “Certificate pinning protects against Non-HNDL.” Pinning fixes a relying party to a specific certificate, and that certificate is still signed with quantum-vulnerable mathematics, so the underlying exposure is unchanged.

Questions people ask

Which quantum risk is happening right now? HNDL. Collection requires only a network path and storage, both of which exist today, so encrypted traffic being recorded now is already exposed to a future decryption. Non-HNDL attacks cannot occur until a cryptographically relevant quantum computer exists.

If Non-HNDL can’t happen yet, why does it have a deadline? Because the countermeasure takes years. Replacing signing algorithms means rebuilding certificate hierarchies, updating trust stores across operating systems and browsers, and moving vendor-controlled signing services, and all of it has to finish before the machine arrives.

Do the two need separate migration projects? They share inventory, vendor engagement and crypto-agility work, and they diverge at the algorithm layer, targeting ML-KEM on one side and ML-DSA or SLH-DSA on the other. Most programs run them as staged phases of one effort rather than as two independent projects.

Which one does my industry care about more? Industries holding long-lived confidential records, including healthcare, legal, financial and government, carry heavy HNDL exposure. Industries whose product is trusted by others, including software vendors, certificate authorities, identity providers and device manufacturers, carry heavy Non-HNDL exposure. Many organizations are meaningfully exposed to both.

Can I tell whether my traffic has already been harvested? No. Passive collection leaves no trace at the target, which is a defining property of the threat and the reason it has to be reasoned about by data lifetime rather than detected.

Is one of them a bigger problem than the other? They fail differently rather than at different magnitudes. HNDL causes a bounded, retroactive confidentiality loss across whatever was collected. Non-HNDL causes an unbounded, forward-looking trust failure whose worst case reaches every relying party under a compromised key.

What breaks if I get the order wrong? Migrating signatures first leaves collectible traffic accumulating for the length of the signature program, and that material is unrecoverable. Migrating key establishment first is the standard order and still requires opening the signature work early, since certificate hierarchies have the longest lead time in most estates.

Do the federal deadlines treat them separately? Yes. OMB M-26-15 Phase 3 covers post-quantum key establishment on priority systems from 2028 to 2030, and Phase 4 covers post-quantum digital signatures on those systems in 2031, which puts the clock difference directly into the schedule.

Where does symmetric encryption fit? Largely outside both. AES at 256-bit strength is a sound answer to Grover’s algorithm, and neither HNDL nor Non-HNDL is primarily a symmetric problem. The narrow exception is the legacy symmetric constructions exposed to the offline Simon’s algorithm.

---

The map is free and I keep it that way. When these two clocks have to become one sequenced migration across an actual estate, that’s the work I do at LaMarr Labs.

Go deeper

• Harvest Now, Decrypt Later (HNDL) and Non-HNDL for each risk in full
• The Two-Lane Split for the sequencing framework these two feed
• Shor vs Grover for the algorithms underneath both
• Blast Radius for how Non-HNDL exposure is prioritized
• What Data Is Vulnerable to Harvest Now, Decrypt Later for the HNDL inventory
• PKI Collapse for the Non-HNDL worst case
• Quantum Risk Models MOC for the whole risk picture

Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs.