Most security professionals first encounter "harvest now, decrypt later" (HNDL) as a theoretical threat — something from academic cryptography papers and NSA briefing decks. The framing is usually future-tense: when a cryptographically-relevant quantum computer (CRQC) arrives, adversaries will be able to break classical public-key encryption. The implication is that there is time. There is a window. Act later.
That framing is wrong, and the error is consequential for any financial institution that classifies data with a useful life exceeding five years — which is most of them.
The actual threat model: harvest today, decrypt when capability arrives
HNDL is not a future-tense threat. The harvesting phase is present-tense, ongoing, and documented. Nation-state actors with long-horizon intelligence objectives do not need a CRQC today to execute the collection phase of this attack. They need storage, network access, and patience.
The data being collected is not traffic that looks sensitive today. It is traffic that will be sensitive when the CRQC capability gap closes — which NIST and NSA project will occur between 2030 and 2035 based on current qubit scaling trajectories. That projection is conservative. It is also actionable: data generated today under RSA-2048 or ECDH P-256 key exchange will be decryptable under those timelines if the key exchange records are archived.
The financial sector data that falls into this category is not a narrow slice. It includes:
- SWIFT FIN messaging: MT103 and MT202 payment instructions, counterparty exposures, correspondent banking flows. Classification period under many institutions' data retention frameworks: 7–10 years.
- Long-term bond and structured product records: Instrument pricing, ownership, collateral positions. Relevant for audit and regulatory purposes for the full instrument life — often 10–30 years.
- HSM-wrapped master key encryption keys (MKEKs) and zone working keys (ZWKs): If an adversary records a key exchange session today, and later breaks the key encapsulation, every session key derived from that exchange is exposed retroactively.
- CA certificate chains and PKI root operations: The private key material used to sign certificates for internal infrastructure. A compromised root means every certificate issued by that CA over its lifetime is suspect.
THE 10-YEAR PROBLEM
If data has a classification life of 10 years and CRQC arrives in 7 years, migration must be complete before that data's retention period expires — which means migration planning must begin now. The planning and procurement cycle for a regulated financial institution to replace HSM infrastructure is itself 2–3 years. The window is not as wide as it appears from a 2025 vantage point.
The mechanism: why TLS-protected data is not safe
The most common CISO response to HNDL briefings is: "Our TLS connections are ephemeral. Forward secrecy means a key compromise doesn't expose past sessions." This is correct for the scenario where an adversary compromises a static long-term key today. It does not apply to the HNDL scenario.
In a TLS 1.3 session with ECDHE key exchange, the session key is derived from the ECDH shared secret. That shared secret is computed from the client's and server's ephemeral public keys. An adversary recording the entire TLS handshake today stores: the two ephemeral public keys, the encrypted record, and the ciphertext. If they can later compute the ECDH shared secret — which Shor's algorithm makes trivial once a CRQC exists — they can derive the session key and decrypt the archived session content.
Forward secrecy protects against a future key server compromise. It does not protect against a future break of the underlying elliptic curve discrete logarithm problem. Those are different threat models. HNDL exploits the latter.
The same analysis applies to RSA key exchange variants, IPsec IKE sessions, and SSH sessions. Any protocol that protects session confidentiality using classical asymmetric cryptography for key agreement is vulnerable to harvest-now-decrypt-later if records are being archived.
Who is collecting? What is the evidence?
The evidence for active HNDL operations is circumstantial but technically coherent. Several observed threat actor TTPs are consistent with large-scale network traffic archival programs:
- Unusual long-term persistence in network infrastructure devices (border routers, WAN optimization appliances, financial network gateways) at financial institutions and their upstream providers. Persistence without active lateral movement or exfiltration is a recognized indicator of collection-for-archival operations.
- Documented collection programs targeting TLS-encrypted bulk flows at internet exchange points, attributed in declassified reporting to nation-state signals intelligence agencies.
- The explicit statements in NSA's Commercial National Security Algorithm Suite (CNSA) 2.0 migration guidance, published August 2022, requiring post-quantum algorithm adoption for National Security Systems. The NSA does not publish migration timelines without an underlying threat assessment.
The financial sector is a priority collection target for nation-state intelligence operations. The combination of long-term encrypted data retention, high-value counterparty relationship data, and known HSM infrastructure patterns makes it a high-yield HNDL target.
Why the clock started years ago, not today
Bank CISOs often frame the question as: "When do we need to be migrated by?" The answer is that the question contains a false assumption. The migration deadline is not defined by when a CRQC is operational — it is defined by when data collected today will still be within its classification window when a CRQC arrives.
For a SWIFT transaction record with a 7-year retention requirement, collected in 2022 under classical key exchange, the harvest window closed in 2022. The record is already in an adversary's archive. Migration in 2028 does nothing for that record. It protects records generated after migration is complete.
This is why "start migration in 2028 when CRQC risk is more certain" is not a defensible posture. The data being generated in 2025 under RSA-2048 or ECDH P-256 key exchange will remain within classification window in 2032, when CRQC capability is plausible on current projections. If migration has not started by 2025, it cannot be completed by the time current-vintage data ages into the HNDL vulnerability window.
The migration sequencing problem for financial institutions
Financial sector HSM infrastructure replacement is not a software update. It involves:
- Procurement, acceptance testing, and production integration of new hardware (12–18 months for regulated institutions with full change management processes).
- Key ceremony re-execution for all affected key hierarchies, with appropriate dual-control and auditor presence.
- Counterparty and network certification for any shared key exchange protocols — SWIFT gateways, ACH processors, card network interfaces.
- PKCS#11 application testing across payment authorization middleware, core banking integrations, and certificate issuance paths.
- Regulatory notification for material changes to cryptographic controls under FFIEC, OCC, or CFTC examination scopes.
Each of these phases adds time. None of them are compressible to zero. An institution that begins scoping in 2025 will realistically be in hybrid deployment by 2027 and full PQC coverage by 2028–2029 — which is precisely the window that matters given CRQC timeline projections.
What "designed for" vs "certified" means in procurement
A key friction point in financial sector PQC procurement is the FIPS 140-3 validation gap. No hardware security module has yet achieved a FIPS 140-3 certificate with CRYSTALS-Kyber-1024 or Dilithium-3 as a validated algorithm — the finalized standards were published in August 2024, and the CMVP testing queue for PQC-native hardware is 18–24 months. This is a real constraint, not a vendor excuse.
The question is not "should we wait for a certified module." The question is "does our compliance framework allow conditional deployment of a module designed for Level 3 certification while formal testing completes." In many regulated environments, the answer is yes — particularly when the module's security design documentation, physical construction, and test evidence are available for examiner review.
Institutions that wait for a certified module before beginning integration testing will have lost 18–24 months of migration runway. The HNDL threat does not pause for regulatory certification timelines.
What bank CISOs should do now
The practical steps that matter in 2025:
- Inventory all data with classification lives exceeding 5 years that is currently protected by classical asymmetric key exchange. SWIFT messaging, CA root operations, long-term custody records, HSM key hierarchies.
- Map the key exchange protocols protecting that data — specifically which HSM or cryptographic library performs the key encapsulation or key agreement operation. This is your migration priority list.
- Begin hardware evaluation for PQC-native HSMs. Evaluation units are available. The integration testing cycle is the longest lead-time item in the migration process. Start it now even if deployment is 12–18 months out.
- Assess counterparty readiness for hybrid TLS. X25519+Kyber-1024 hybrid mode (IETF draft-ietf-tls-hybrid-design) is the bridge between classical and full PQC. Your payment network partners need to support it before you can deploy it end-to-end.
- Engage your regulatory examiner early. FFIEC and OCC examiners are beginning to ask about PQC migration planning. Institutions with a documented roadmap — even one that doesn't reach full deployment for 3 years — are in a better position than institutions that have not engaged the topic.
The threat model for harvest-now-decrypt-later is unusual because it requires acting before the capability that makes the threat real exists. Every year of delay is a year of data generated under protocols that will be broken — and for a financial institution, some fraction of that data will still be within its classification window when the break becomes possible.
What quantum timelines actually mean for budget planning
One source of institutional inertia on HNDL is the uncertainty in quantum timelines. "CRQC in 10 years" has been the headline estimate for 20 years, which has trained budget decision-makers to discount quantum risk as perennially future-dated. Understanding why the timeline uncertainty itself is not a reason to wait requires looking at what the distribution of outcomes looks like, not just the median estimate.
The median estimate from cryptographically-relevant quantum computing researchers in 2023–2024 — including the ranges cited in NSA CNSA 2.0 guidance and NIST post-quantum migration documentation — puts a cryptographically-relevant quantum computer capable of breaking RSA-2048 in the 2030–2035 window. That is a 10-year window. But the tails of that distribution are not symmetric. The downside tail (CRQC arriving earlier than expected) is driven by exponential progress in qubit quality and error correction, which historically has surprised the field with acceleration rather than deceleration. The upside tail (CRQC much later than expected) does reduce urgency but does not eliminate the HNDL problem — harvest-collected data is already in archives regardless of when decryption becomes possible.
For budget planning purposes, the relevant question is not "what is the median CRQC arrival date" but "what is the probability-weighted cost of being unprepared." An institution with $50B in long-term fixed income holdings whose ownership and collateral records are in archived TLS sessions from 2020–2025, combined with a 20% probability of CRQC before 2030, faces expected exposure that justifies infrastructure investment — not as a certainty bet, but as a risk-weighted decision. The budget case for PQC migration is structurally similar to the budget case for disaster recovery: the event is probabilistic, the mitigation has a known cost, and inaction creates a conditionally catastrophic outcome.
Framing this to board-level risk committees: PQC migration is not a compliance spend. It is a hedging cost against a tail risk whose probability is non-negligible and whose severity is unacceptable. The hedge is cheaper now than it will be in 2028 when certification queues, hardware availability constraints, and regulatory impatience compound.
The data that is already harvested: what it means operationally
A question that follows from this analysis: if data generated before 2025 is already in adversary archives, what should institutions do about it? The honest answer is that there is limited operational response for data already harvested under classical key exchange. Migration going forward prevents future data from joining those archives in a decryptable form. It does not retroactively protect data from 2019 or 2021.
The implication for data retention and incident response is real, however. Financial institutions should assess which categories of pre-2025 encrypted data — if decrypted under a future CRQC — would create the most severe regulatory, contractual, or counterparty exposure. SWIFT correspondent banking records detailing counterparty credit exposures, M&A-related wire transfer patterns, collateral position records: these categories warrant accelerated retention review. Data that would be damaging if exposed in 2030 should have a managed retention policy now, rather than sitting in archived backup storage for its full statutory retention period.
Cryptrig is not a consulting firm. We build hardware. But the hardware only helps if it is deployed before the data it should protect is generated. That is the clock that started years ago.