The HNDL framing is owned by intelligence agencies in NSA, BSI, NCSC, ENISA. It is the operational reason every advisory memo treats PQC migration as urgent: you can't fix the ciphertext that an adversary already captured. The exposure window opened the day RSA was invented and only closes for new traffic the day you switch to PQC.
That is a real and worth-acting-on threat. It is also narrower than the press makes it sound. The load-bearing variable is secrecy lifetime — how long a given piece of data has to remain confidential. Get the data classification right and HNDL becomes a planning problem; get it wrong and you waste a budget on the wrong protections.
The mechanics, in three frames
The attack has three phases, and every phase has prerequisites that limit it:
- Capture. The adversary records encrypted traffic — at an internet exchange, a submarine cable landing, a backbone peering point. This is a state-actor capability. It is not free; it requires legal authority or physical access. The set of organisations doing it meaningfully is small.
- Store. Captured ciphertext sits in cold storage. Storage at this scale is cheap but not free. The adversary chooses what to keep based on what they expect to be valuable years from now.
- Decrypt. When a cryptographically relevant quantum computer exists, Shor's algorithm breaks RSA, Diffie-Hellman, and ECC in polynomial time. The adversary processes their stored archive and reads everything in bulk.
The first two phases are happening now for state-level adversaries; the third phase is the open question. Mainstream estimates put the arrival of a CRQC anywhere from late this decade to several decades out.
Secrecy lifetime is what decides exposure
Combine the three phases with a simple test: if the data stops being valuable to the adversary before the third phase arrives, the attack doesn't matter for that data. Apply that to a typical Indian bank's data inventory and the picture clarifies fast.
Data classes ranked by secrecy lifetime:
- Forever-secret. KYC documents, biometrics, Aadhaar references, customer income records. Decades of secrecy lifetime. High HNDL risk.
- Decade-class. Banking transaction histories, loan documentation, credit reports, internal risk models, trading strategies, IP. 10–15 years of secrecy value. High HNDL risk.
- Year-class. Pricing models, marketing campaigns, internal communications, audit reports. 1–5 years. Moderate HNDL risk.
- Month-class. Operational metrics, capacity planning, vendor communications. Months. Low HNDL risk.
- Hours-class. Session tokens, OTPs, payment authorisation codes, ephemeral keys. No HNDL risk.
What to encrypt forward today
The prioritisation falls out of the data classification:
- Forever-secret data in motion. External TLS for KYC submission flows, regulator-data submission, partner integrations carrying customer PII. Hybrid PQC TLS is the immediate fix.
- Forever-secret data at rest. Re-wrap the data-encryption keys for archives, KYC stores, biometric databases under ML-KEM-encapsulated KEKs. The symmetric encryption itself (AES-256) is unchanged.
- Decade-class data in motion. Same treatment, schedule behind forever-secret. Most internal mTLS sits here.
- Year-and-shorter classes. Migrate opportunistically as part of normal infrastructure refreshes. The HNDL clock does not bite this data.
The reality check
HNDL is funded by states, not by ransomware crews. If your threat model includes a foreign intelligence service that specifically wants your bank's customer PII or loan book ten years from now, take it seriously. If your threat model is financially-motivated crime, the HNDL clock is the wrong clock to optimise — those adversaries do not capture-and-wait.
The honest framing is this: PQC migration is urgent for the narrow set of data classes that genuinely have long secrecy lifetimes, and important-but-not-urgent for everything else. The migration is overdue. The panic is optional.