Mental model
In the previous lesson you saw that Shor’s algorithm breaks asymmetric cryptography completely, but that requires a “large enough, stable quantum computer” (a CRQC, cryptographically relevant quantum computer), and no such machine exists today. That can lead to the conclusion “then there is no need to hurry”. The HNDL threat refutes exactly that conclusion.
The mechanism has two steps. Step one, today: an attacker (an intelligence service, a state actor, a competitor) captures and stores traffic flowing encrypted today (a TLS session, an email). They cannot decrypt it, because today’s asymmetric cryptography (key exchange protected by RSA or ECC) is still secure. But storage is cheap; they just wait. Step two, in the future: once a CRQC exists, the attacker takes out the stored encrypted data, breaks the public keys of that time with Shor, and decrypts the traffic captured in the past.
The critical consequence of this threat: the data that must be protected today is not just what is sent today, but what is sent today and will still be valuable in the future. When a CRQC will arrive is uncertain (a probability range, like the Global Risk Institute estimates you saw in the previous lesson), but how long data must stay secret is usually known: a mortgage contract, a medical record or a state secret must stay secret for years or even decades. The intersection of the two is the core of Mosca’s inequality, which you will formalize in the next lesson (mosca-inequality).
Which data is really at risk
HNDL is not equally urgent for all data. For short-lived data that loses its value within minutes or hours (a stock order, a one-time session token), the HNDL risk is low: whenever a CRQC arrives (a probability range, not a single date, as in the previous lesson), that data will long since be worthless. But for long-lived data (personal health records, national security secrets, long-term financial contracts, trade secrets), the risk is real and starts now, because this data can be captured and stored today and still do damage in the future. In the next lesson (mosca-inequality) you will answer “how much at risk” with a formula that formally compares these two variables (how long the data must stay secret, the time left until a CRQC). What matters here is the distinction itself: if the period is short it is not urgent, if it is long it is urgent; the line between “urgent” and “remote possibility” depends on the nature of the data.
The joint CISA/NSA/NIST advisory (source 1) starts with a cryptographic inventory precisely because of this distinction: without knowing which data must stay secret for how long, you cannot decide which system should migrate first. That is the root justification for the discovery and inventory work in M12.
Who is actually “harvesting”
To understand HNDL as a concrete operational reality rather than an abstract threat model, ask: what does an attacker need to store traffic today? Answer: just a passive listening point (at the level of an internet service provider, on a submarine cable, on a data centre link) and storage capacity, both cheap and common today. This shows why HNDL is not just a theoretical scenario but a natural extension of existing intelligence collection infrastructure: mass traffic storage was already done before quantum computers, for other purposes (traffic analysis, future cryptanalysis methods). That is why the CISA/NSA/NIST advisory frames this threat as “already active”, not “hypothetical”.
Who invented HNDL
An honest answer to this question: it is not known, and that is itself an example for this course. The phrase “harvest now, decrypt later” is relatively new (it became common after about 2020), but the mechanism is much older. In a 2013 essay written as a direct response to the Snowden disclosures (source 2), Bruce Schneier explicitly discusses the possibility that the NSA stores encrypted traffic today to decrypt it in the future with a quantum computer, without ever using the phrase “harvest now, decrypt later”. That is evidence the name came long after the mechanism.
When you explain this to a bank architect, making a precise but unsourced claim such as “HNDL was invented by X in 2020” is exactly the kind of mistake this course tries to avoid. The right frame: the mechanism was recognized at least a decade ago (Schneier 2013), the name is newer and who first used it is unclear. Saying “we don’t know” is, here too, a signal of professional honesty.
Do not confuse HNDL with “general surveillance”
A common mistake when a hostile architect questions this topic is confusing HNDL with a general, indiscriminate surveillance claim. HNDL’s strength as a threat model lies precisely in its selectivity: storing everything forever is not practical for an attacker (storage is not infinitely cheap, and decrypting stored data also needs computing resources once a CRQC arrives, which are limited). So a rational attacker prioritizes high-value, long-lived traffic (government communications, the key infrastructure of large financial institutions, critical trade secrets), not low-value, short-lived traffic. For a bank, this turns an overstated frame like “all our traffic is at risk” into the question “which of our traffic would be near the top of an attacker’s priority list”. That is yet another reason the inventory work in M12 must be a prioritized effort, not just “move everything to PQC”.
What we learned
HNDL refutes the logic “we are safe today because there is no CRQC yet”: the risk lies in data being capturable today and still valuable in the future, not in whether a CRQC exists today. That is the real source of migration urgency, and in the next lesson you will express it with concrete numbers (Mosca’s inequality).