The phrase "harvest now, decrypt later" entered the cryptographic security community's vocabulary well before the first credible quantum computing demonstrations. It describes a threat model that doesn't require a quantum computer to exist today — only the reasonable expectation that one will exist within a definable horizon, combined with an adversary with the capability and motivation to archive encrypted data at scale today.
For financial institutions, the HNDL threat model has a specific characteristic that makes it more pressing than it is for most other sectors: the data being encrypted today has a value horizon that may extend beyond the quantum timeline. A retail bank's customer account history, interbank wire transfer records, and foreign exchange settlement data are not valuable to an adversary for 90 days. They may be valuable for 10 to 20 years — competitive intelligence, regulatory strategy, litigation preparation, or state-level economic intelligence. If that data is currently protected with TLS using ECDH or RSA key exchange, an adversary archiving the traffic today acquires the ability to decrypt it the day a sufficiently powerful quantum computer becomes operational.
This article focuses on the threat model's specifics for financial sector infrastructure — not the question of when a CRQC will exist, but the structural factors that determine whether your institution's current encryption posture provides a meaningful defense against HNDL.
The CRQC timeline debate misses the point
The most common objection to prioritizing quantum migration is the CRQC timeline: "quantum computers capable of breaking RSA-2048 or EC P-256 are at least 15 years away." This objection is structurally correct as a point estimate but strategically irrelevant for three reasons.
First, the 15-year estimate has wide uncertainty bounds. The track record of quantum computing development timelines since 2010 is that capability has advanced faster than most expert estimates — not universally, and not linearly, but faster. Point estimates based on today's understanding of error correction overhead and physical qubit scaling have been wrong at every major milestone. Institutional security decisions made on the basis of "15 years" are implicitly betting that the estimate won't be revised downward by more than the institution's own migration lead time.
Second, migration lead time for financial infrastructure is 3 to 7 years for large institutions. The procurement cycle for HSM replacement — RFP, vendor evaluation, security assessment, pilot, staged rollout — takes 18 to 36 months at institutions with multiple payment processing systems. Following procurement, the integration work — updating PKCS#11 integrations, migrating key hierarchies, updating certificate chains, validating payment software — adds another 18 to 36 months. For inter-institutional infrastructure (SWIFT connectivity, bilateral settlement links, card network integrations), the timeline extends further because counterpart institutions must coordinate.
Third, data harvested today is already at risk. The HNDL threat is not a future risk — it is a present action with future consequences. Adversaries who want to maintain surveillance of interbank wire traffic do not need to wait for a quantum computer to start harvesting. They harvest now, at the cost of storage, against the option value of future decryption.
What data in financial institutions has a long-enough value horizon
Not all financial data has a value horizon that extends beyond a plausible CRQC timeline. Transaction-level retail payment data from 2026 is not competitively valuable to most adversaries in 2040. The data that deserves the most urgent attention:
Interbank settlement records and Fedwire transaction histories — These contain the flow of funds between institutions, which reveals counterparty exposures, net settlement positions, and relationships between financial entities. For state-level intelligence analysis of another nation's financial system, this data is valuable indefinitely.
Encrypted communication between financial institutions' CISO/legal/regulatory teams — Decision-making communications about regulatory strategy, M&A activity, legal exposure, and crisis response are valuable for years after the fact. This traffic often traverses TLS connections that are subject to passive monitoring more readily than production payment traffic.
Authentication and key management ceremony records — If an adversary can archive the encrypted traffic of an HSM key ceremony — including the authenticated management channel between operators and the HSM — and later decrypt it, they can reconstruct key material if the ceremony protocol was not designed for forward secrecy. This is a narrow but specific attack surface.
Customer financial records transmitted over legacy protocols — Older core banking integrations may not use TLS with forward secrecy (ECDH key exchange). Static RSA key exchange is still present in some banking software, meaning that compromising the RSA private key — whether classically or by quantum — decrypts all historical archived sessions with that key.
Why "wait for FIPS certification" is the wrong sequencing
A common response to the HNDL analysis is: "We'll migrate when FIPS 140-3 certified PQC hardware is available." This is strategically sound in principle — procurement of cryptographic hardware that has completed CMVP validation is good practice. The problem is timing.
FIPS 203 (ML-KEM/Kyber) and FIPS 204 (ML-DSA/Dilithium) were finalized in August 2024. The CMVP validation process for hardware implementing new algorithms takes 12 to 36 months from submission, depending on queue depth and complexity. The first FIPS 140-3 certificates specifically covering Kyber-1024 and Dilithium-3 hardware are likely to appear in 2026–2027. Institutions that begin their procurement process when those certificates appear will be completing migrations in 2029–2031 — assuming the CRQC timeline doesn't shorten.
The risk-adjusted posture for most large financial institutions is not "wait for certification" but "begin evaluation now, with hardware designed for certification, so that when certificates exist you have already completed the institutional learning, integration testing, and procurement approval that would otherwise add 18 to 24 months to your timeline." The term for this is conditional deployment: run PQC hardware in a hybrid mode (classical + PQC key exchange) in pre-production and limited production while CMVP validation is in progress, with a contractual commitment from the vendor on certification timeline and a migration plan to full PQC-native deployment upon certificate issuance.
What immediate actions look like
The following are the actions that meaningfully reduce HNDL exposure within a 12-month window for a financial institution that has not yet begun PQC migration:
1. Inventory TLS endpoints that use static RSA key exchange. Any TLS connection using RSA key exchange (not ECDHE) provides zero forward secrecy. Archived traffic from these connections is decryptable by anyone who later obtains the RSA private key — quantum or classical. Migrating these endpoints to ECDHE is a classical upgrade that should happen regardless of quantum timeline, and it provides immediate reduction in HNDL exposure for that traffic.
2. Identify the data value tiers. Not all encrypted traffic deserves equal priority for PQC migration. An inventory of which TLS connections carry long-horizon-value data (interbank settlement, management communications, key management channels) allows prioritized migration rather than requiring simultaneous upgrade of all endpoints.
3. Begin HSM vendor evaluation for PQC-capable hardware. The evaluation process — security review, integration testing, regulatory assessment, vendor qualification — takes 12 to 18 months for large institutions. Starting this process now means having a qualified vendor and tested integration approach ready when FIPS certificates become available.
4. Deploy hybrid TLS on the highest-priority endpoints. IETF hybrid TLS (X25519+Kyber-1024) provides HNDL protection for newly established TLS sessions from the day of deployment. Traffic encrypted with hybrid TLS is not decryptable by a future quantum computer, even if one of the two key exchange components is eventually broken. Hybrid TLS deployment does not require FIPS 140-3 certified hardware for the Kyber component — it requires hardware or software that correctly implements the IETF draft specification.
Cryptrig builds hardware for steps 3 and 4. We are not a risk assessment firm and we do not offer HNDL exposure consulting. The analysis above is the threat model framing that informs why we chose to build CQ1 as a PCIe-attached HSM for payment infrastructure rather than a general-purpose PQC library — the institutions that most need HNDL protection need hardware that can sustain the throughput of their highest-priority TLS endpoints, not a software library that degrades under payment-volume load.