Your Bank’s HNDL Exposure Window Is Already Open

Last year, a regional bank’s security team detected an unauthorized connection on a core network appliance. They isolated the device, closed the vulnerability, and filed the incident report. The forensics confirmed that files had been copied – but they were encrypted. The conclusion was that the attacker had taken nothing of immediate value.

That conclusion may cost them everything in 2029.

The attacker didn’t need to read the files. The attacker needed to store them. What looks like a failed breach today is the first half of a two-stage attack that completes the moment a cryptographically capable quantum computer comes online. This is Harvest Now, Decrypt Later – and it is the most consequential cybersecurity threat facing banks and financial institutions right now, not in some distant quantum future.

If your institution holds customer records, transaction histories, authentication credentials, or regulatory correspondence that must remain confidential for years – and every bank does – the clock is already running.

The attack has three stages:

What makes this different from every other cybersecurity threat your institution has faced is the irreversibility. You can patch a vulnerability. You can revoke credentials. You can rebuild a compromised server. You cannot retrieve data that an adversary already holds in storage.

You may also see this described as Store Now, Decrypt Later (SNDL). The terms are used interchangeably across different authorities – NIST and CISA predominantly use HNDL, while SNDL appears more frequently in academic literature and some European cybersecurity frameworks including ENISA guidance. Both describe the same adversary strategy. If your compliance team or vendors use SNDL, they are referring to the same operational threat.

This is where most explanations of HNDL fall short. They describe the concept without explaining why it is so difficult to detect. The operational reality is that an HNDL attack looks almost identical to a conventional espionage intrusion – except the attacker leaves without doing anything visibly damaging.

In a typical HNDL operation, an attacker may:

That last point matters enormously. A conventional attacker monetizes the breach immediately – through ransomware, data sales, or extortion. An HNDL operator has a longer timeline and no reason to announce their presence. They want the breach investigation to conclude that the stolen files were encrypted and therefore harmless.

Security operations teams should not expect an alert labeled ‘Harvest Now, Decrypt Later.’ HNDL is an attacker’s strategy, not a distinct malware family or network signature. The same packet capture, the same backup exfiltration, the same unauthorized VPN access could be conventional espionage, identity theft – or the collection phase of an HNDL operation.

There are patterns worth investigating more carefully:

None of these indicators individually confirm HNDL intent. But an institution should not dismiss a breach because the stolen files were encrypted. That conclusion treats today’s encryption as a permanent guarantee. It is not.

Not all encrypted data is worth storing for a decade. A nation-state actor running HNDL operations is not archiving streaming video or software update traffic. They are filtering for data with the longest confidentiality life – and financial institution data sits at the top of that list.

Think about what a major bank actually holds and for how long it must remain confidential:

The exposure extends across every layer of a financial institution’s infrastructure:

The wrong question is: ‘Is this data encrypted today?’

The right question is: ‘Must this data remain confidential beyond the date when the cryptography protecting it may become breakable?’

For most of the data categories listed above, the answer is yes. That is what defines an HNDL target. Not the data’s current market value – its future confidentiality requirement.

Most banking systems use two layers of cryptography working together.

Symmetric encryption – AES being the most common – protects the actual content of the data. AES is considered relatively resilient against quantum attacks because Grover’s algorithm only provides a quadratic speedup, which can be compensated by doubling key length (AES-256 vs AES-128).

Public-key cryptography – RSA and Elliptic Curve Cryptography (ECC) – handles the authentication of communicating parties and the exchange of the symmetric keys used to encrypt each session. RSA and ECC are the vulnerable layer. Shor’s algorithm, running on a sufficiently capable quantum computer, can solve the mathematical problems these systems depend on in polynomial time rather than exponential time.

Here is the attack in plain terms: the adversary does not need to break AES. They record the encrypted session – which includes both the AES-encrypted data and the RSA or ECC key exchange that established the session key. When a quantum computer becomes available, they break the key exchange, recover the session key, and decrypt the historical data with it.

Dr. Michele Mosca at the Institute for Quantum Computing, University of Waterloo, formalized a simple inequality that every CISO in financial services should have in front of them:

Walk through what this means for a real institution. Take customer identity records with a 15-year confidentiality requirement. Add five years for a realistic cryptographic migration – discovery, vendor engagement, testing, and phased enterprise deployment. That sum is 20 years. If a cryptographically relevant quantum computer arrives in 2029 – the timeline Google’s internal roadmap places as the target – then from 2026, you have three years.

You do not have 20 years to start. The organization that begins its cryptographic inventory today finishes the migration with time to spare. The organization that waits until 2027 may discover its migration requires more time than the deadline allows.

For several years, the federal framing of HNDL was cautionary – ‘this risk cannot be ruled out.’ In 2025 and 2026, that framing changed.

The direct mandates in EO 14412 apply to federal agencies and federal contractors. But financial institutions should read it carefully for two reasons.

First, any institution that provides services to federal agencies, processes federal payments, or holds accounts for federal entities falls within the contractor ecosystem that the Federal Acquisition Regulation will pull into compliance. Second, the financial sector has consistently followed federal cybersecurity leadership – NSM-10, OMB M-23-02, and NIST guidance have all set the direction that bank regulators subsequently embed in examination frameworks. EO 14412 is directional for the whole sector, not just federal agencies.

The message from Washington is no longer to study the threat. It is to execute the transition.

This is the hardest thing to communicate about HNDL – and the most important.

Traditional incident response is built around four phases: containment, eradication, recovery, and lessons learned. Every breach in this framework has a remediation path. You isolate the affected systems, remove the threat actor, restore clean backups, patch the vulnerability, and return to operations. The damage is bounded.

HNDL creates a fifth problem that traditional incident response was never designed to address: irreversibility.

An institution can patch the compromised router. It can revoke credentials and replace certificates. It can rebuild every affected system from scratch and deploy post-quantum cryptography on every endpoint going forward.

What it cannot do is retrieve every copy of encrypted data already sitting in an adversary’s storage environment.

This is why HNDL cannot be treated as a future technology risk to be addressed after quantum computers arrive. By then, the collection window has closed – in the adversary’s favor. The institutions that begin their PQC migration now migrate with visibility, sequencing, and operational control. The institutions that wait may discover their quantum breach began years before they were aware a breach was possible.

NIST recommends prioritizing systems, applications, and data that depend on cryptography – especially where the data is sensitive and long-lived. The following sequence is what we work through with every financial institution that engages Quantum Infinite.

You cannot migrate what you cannot see. The first step is a comprehensive cryptographic inventory across your entire environment – every algorithm in use, every certificate, every protocol, every library, every embedded dependency in every application, appliance, and third-party integration.

Most institutions discover their cryptographic footprint is significantly larger than their IT asset inventory suggests. Legacy applications use cryptographic libraries that have not been updated since deployment. Third-party integrations introduce algorithms that the institution does not control. Cloud services use cryptographic implementations that vary by configuration.

The cryptographic inventory is not a one-time scan. It is the foundation of an ongoing cryptographic management program.

Once you know where cryptography is operating, the next step is understanding what it protects and for how long that information must remain confidential. This is the link that most assessments miss.

A payment gateway protecting transaction data that cycles every 90 days has a very different risk profile than an archive server holding 15 years of customer account correspondence. Both use encryption. Only one is a high-priority HNDL target. Prioritization depends on data longevity, not just cryptographic algorithm strength.

Examine every location where encrypted traffic could be intercepted in transit – VPN connections, branch-to-headquarters links, cloud integrations, third-party API connections, email infrastructure, file-transfer systems, and backup replication channels. These are the collection points an HNDL operator targets. Knowing where they are is prerequisite to protecting them.

Every hardware vendor, software provider, and SaaS platform in your environment has a cryptographic dependency. Many will require firmware updates, protocol upgrades, or full replacement to support NIST PQC standards. The ones that lack a clear PQC roadmap today are the ones most likely to become migration bottlenecks in 2028.

Require explicit PQC roadmaps, algorithm visibility, and upgrade commitments from every vendor in your cryptographic supply chain. Start these conversations now. Procurement cycles in financial services are long.

The goal of a PQC migration is not to replace RSA with ML-KEM and declare the work finished. Cryptographic standards will continue to evolve. NIST has already selected a fourth PQC algorithm (HQC) as a backup KEM. Standards bodies will continue releasing updates. A crypto-agile architecture allows your institution to update cryptographic algorithms without redesigning the systems that depend on them – reducing the cost and complexity of every future transition.

NIST finalized its first three post-quantum cryptography standards on August 13, 2024. These are available for deployment today:

NIST has urged organizations to begin transitioning immediately. Waiting for a cryptographically relevant quantum computer to be publicly announced is not a migration strategy. The adversary does not announce themselves when they start collecting.

Most PQC assessment vendors require you to upload your data – or at minimum your cryptographic configurations and key material metadata – to an external assessment platform or cloud environment. That is a new exposure window created in the process of identifying an old one.

Quantum Infinite’s approach is different by design.

Our assessment and migration work is conducted entirely on-premises, within your controlled environment. No banking data, cryptographic keys, or configuration data is transferred to an external system at any point in the engagement. Data sovereignty remains 100% with your institution throughout – not as a feature we offer, but as the architecture we operate on.

Quantum Infinite conducts:

Our cryptographic risk audit covers every layer of your institution’s cryptographic attack surface:

Quantum Infinite is a trusted advisor to ISAO TX and a member of the Texas Bankers Association. Our work is aligned with NIST FIPS 203, 204, and 205 – and with the U.S. federal cybersecurity mandates, including EO 14412 and NSM-10, that define the compliance horizon for financial institutions.

Harvest Now, Decrypt Later (HNDL) is a cyberattack strategy in which adversaries intercept and store encrypted data today using conventional intrusion methods, with the intent to decrypt it once quantum computers become powerful enough to break today’s public-key cryptography. The collection phase requires no quantum capability – only network access, storage, and patience. The breach begins at the moment of collection, not the moment of decryption. Banking records, authentication data, and long-lived financial documents are among the highest-value HNDL targets because of how long they must remain confidential.

HNDL is an active, present-day operational threat. The U.S. Government Accountability Office warned in January 2025 that adversaries can already copy protected data and store it for future access, and concluded that the quantum threat ‘might already be here.’ Executive Order 14412, signed in June 2026, explicitly describes ‘ongoing cyber activity’ in which adversaries collect data now for future quantum decryption. Intelligence agencies in the U.S., UK, Netherlands, Australia, and Singapore have all issued guidance treating HNDL as a current operational risk, not a future hypothetical.

Harvest Now, Decrypt Later (HNDL) and Store Now, Decrypt Later (SNDL) describe the same adversary strategy using different terminology. HNDL is the predominant term in U.S. federal guidance – used by NIST, CISA, the GAO, and the White House. SNDL appears more frequently in academic literature and some European cybersecurity frameworks. If your compliance team or vendors use SNDL, they are describing the same threat. Both terms refer to the collection of encrypted data today for future quantum decryption.

HNDL does not produce a unique security alert or distinct network signature. It uses the same intrusion techniques as conventional espionage. Security teams should treat the following as potential HNDL indicators warranting deeper investigation: bulk exfiltration of encrypted archives or backups, compromise of routers or VPN infrastructure without a clear ransomware or financial motive, collection of cryptographic metadata alongside data, exfiltration without a ransom demand or immediate public disclosure, and long-duration low-noise access to communication infrastructure. Stolen encrypted data should never be dismissed as harmless on the grounds that it cannot currently be decrypted.

The primary defense is migrating to post-quantum cryptography before quantum computers reach the capability to decrypt RSA and ECC. NIST finalized three PQC standards in August 2024 – FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) – and urges organizations to begin transitioning immediately. The migration process begins with a comprehensive cryptographic inventory, followed by risk-based prioritization based on data longevity. For financial institutions, the migration timeline is measured in years, not months – which is why starting now determines whether the transition completes before the quantum exposure window closes.

Most PQC assessment vendors require you to transfer cryptographic configuration data, metadata, or key material to an external platform during the assessment. That transfer creates a new exposure window in the process of closing an old one. Quantum Infinite’s Zero-Data Air-Gapped model means the entire assessment and migration is conducted within your institution’s controlled environment. Nothing leaves your systems. Data sovereignty remains 100% with your institution. This is not an optional feature – it is the architecture.

Every day your institution’s encrypted communications and data archives sit protected only by RSA and ECC, they remain within the HNDL collection window. The adversaries running these operations are not waiting for you to prepare. They are collecting now, storing patiently, and waiting for 2029.

Once encrypted data has been harvested, no migration can guarantee that every stolen copy has been recovered or destroyed. The institutions that begin now migrate with visibility, sequencing, and control. The institutions that debate the deadline may discover that their quantum breach began years before the quantum computer arrived.

Quantum Infinite | quantum-infinite.com | San Antonio, TX | Christine@Quantum-Infinite.com

• Harvest: An adversary compromises network infrastructure – a router, VPN gateway, cloud account, email platform, or backup environment – and begins collecting encrypted traffic, files, and archives. The data cannot be read yet. That is not the point.
• Store: The collected ciphertext goes into adversary-controlled storage. Cloud storage costs roughly $0.001 per gigabyte per month. Storing years of intercepted banking traffic costs less than a moderate IT budget line item. There is no urgency. The attacker waits.
• Decrypt: When a cryptographically relevant quantum computer (CRQC) becomes available, the attacker applies Shor’s algorithm to break the public-key cryptography that protected the session keys. The historical data becomes readable – every transaction, every communication, every credential exchange that was captured.

Common HNDL Collection Techniques

An attacker may:

• Position themselves between communicating systems to silently capture encrypted traffic in transit.
• Compromise a router, firewall, VPN concentrator, or other network appliance to record encrypted sessions.
• Use scripts or malware to locate and copy encrypted databases, archives, and backup repositories.
• Exfiltrate encrypted files from cloud storage, email platforms, or internal file servers.
• Record VPN, TLS, SSH, IPsec, and application-layer communications.
• Steal digital certificates, protocol handshakes, and cryptographic configuration data.
• Collect key management metadata alongside encrypted data, giving future quantum decryption efforts a significant advantage.
• Leave the environment without deploying ransomware, publishing stolen data, or making any demands.

Potential Indicators of an HNDL Attack

Security teams should investigate the following indicators more closely:

• Unexplained packet capture activity or network sniffing on perimeter devices.
• Compromise of routers, VPN gateways, or security appliances without an obvious ransomware or financial motive.
• Bulk exfiltration of encrypted archives or backup repositories.
• Unusual access to certificate stores or key management infrastructure.
• Collection of protocol handshakes and cryptographic metadata alongside encrypted data.
• Data exfiltration without a ransom demand, public disclosure, or immediate follow-up activity.
• Low-noise, long-duration access to communication infrastructure.
• Theft focused on older, highly sensitive records rather than current operational data.

High-Value Banking Data Frequently Targeted

Examples of long-lived, high-value data include:

• Customer identity records
• Authentication credentials
• Know Your Customer (KYC) documentation, often retained for 7–10 years under regulatory requirements and, in many cases, indefinitely.
• Wire transfer documentation and high-value transaction records, which are often subject to long-term audit requirements and litigation holds.
• Merger and acquisition (M&A) communications, board-level correspondence, and strategic planning documents.
• Correspondent banking relationships and foreign exchange (FX) transaction data, which retain intelligence value well beyond regulatory retention periods.
• Digital certificates and cryptographic signing keys, which, if compromised retrospectively, could enable attackers to forge historical authorizations and digital signatures.
• Regulatory correspondence and legal archives, which could expose institutional liabilities or reveal regulatory and enforcement vulnerabilities.
• Encrypted branch-to-headquarters communications carrying sensitive operational and financial data.
• Digital and mobile banking session data, including customer authentication and transaction sessions.
• Payment network traffic and settlement records containing sensitive financial transaction information.
• Core banking platform communications, including inter-system and customer transaction data.
• Third-party payment processor integrations and API communications, which exchange sensitive financial and customer information.
• Cloud environments and hybrid infrastructure connections, where encrypted communications and data exchanges occur across on-premises and cloud platforms.

Identity and authentication system logs

Encrypted backup repositories – often the richest HNDL target because they aggregate years of data in one accessible location

• January 2025: The U.S. Government Accountability Office released a report concluding that adversaries can already copy protected data and store it for future access. The GAO stated the quantum threat ‘might already be here.’
• June 2026: The White House issued Executive Order 14412, ‘Securing the Nation Against Advanced Cryptographic Attacks.’ The order establishes a national policy to transition federal information systems to NIST-approved post-quantum standards and directs support for critical infrastructure operators – including financial institutions – to do the same. It sets a December 31, 2030 deadline for post-quantum encryption and December 31, 2031 for post-quantum authentication.
• July 2026: The Office of Management and Budget issued M-26-15, ‘Execution of the Migration to Post-Quantum Cryptography,’ providing the federal implementation framework for EO 14412.
• FIPS 203 – ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism): Replaces RSA and Diffie-Hellman in key exchange. This is the primary standard for protecting data confidentiality.
• FIPS 204 – ML-DSA (Module-Lattice-Based Digital Signature Algorithm): Replaces RSA and ECDSA for digital signatures. Protects authentication and non-repudiation.
• FIPS 205 – SLH-DSA (Stateless Hash-Based Digital Signature Standard): An alternative signature scheme with different security assumptions. Provides redundancy if lattice-based approaches face future cryptanalytic advances.

On-premises cryptographic discovery across web servers, APIs, application code, databases, network infrastructure, and digital certificates

Cryptographic Bill of Materials (CBOM) development – a complete map of every algorithm, key, certificate, and protocol dependency in your environment

HNDL exposure analysis – identifying which encrypted data and communications have the highest longevity risk profile

Sensitive-data longevity assessment – connecting cryptographic controls to the confidentiality timelines of the data they protect

Quantum-vulnerable algorithm and protocol identification, including embedded dependencies in third-party code and vendor appliances

Vendor and third-party dependency mapping – identifying which external systems require PQC roadmaps before your migration can complete

Risk-based migration prioritization – sequencing your transition based on data longevity, business impact, and system criticality

PQC roadmap development aligned with NIST FIPS 203, 204, and 205 and U.S. federal cybersecurity mandates

Proof-of-concept validation – confirming interoperability, performance, and operational continuity before enterprise-wide deployment

• Web Server and URL Analysis: We expose, map, and eliminate risk across all web services, endpoints, and URLs – identifying cryptographic usage patterns and prioritizing vulnerabilities by real-world impact, not theoretical severity.
• Code Base Analysis: Deep inspection of application code and dependencies to detect weak, deprecated, or quantum-vulnerable cryptographic libraries and implementations. Risks are eliminated at the source.
• Network Analysis: Assessment of internal and external network communications, mapping every cryptographic protocol in use and identifying gaps against NIST PQC compliance requirements.
• Digital Certificate Analysis: Evaluation of certificates, key lengths, algorithms, and trust chains across your enterprise – including lifecycle status, expiration risk, and certificate resilience against the quantum transition.

Harvest Now, Decrypt Later (HNDL) is a cyberattack strategy in which adversaries intercept and store encrypted data today – using conventional intrusion methods – with the intent to decrypt it once quantum computers become powerful enough to break today’s public-key encryption. The collection phase requires no quantum capability. The breach begins the moment your encrypted data is taken, not the moment it is read.

Palo Alto Networks’ Unit 42 2026 Global Incident Response Report found that the fastest quartile of intrusions reached data exfiltration in 72 minutes in 2025 – down from 285 minutes in 2024. The window between initial access and collection is shrinking. HNDL begins at the moment of exfiltration, not the moment of decryption.

The attacker is not trying to break the vault today. They are stealing the locked vault, the lock design, and the key-exchange evidence – then waiting for a tool powerful enough to open it. NIST states that long-lived secrets create an immediate reason to begin using post-quantum protection.

Data Confidentiality Life  +  Migration Time  >  Time Until Quantum Compromise  =  You Are Already in the Risk Window

A future PQC migration protects new communications. It cannot travel backward in time and protect communications that were harvested years earlier. A breach does not become harmless because the damage has been postponed.

Security arrives at your data. Your data never leaves your environment. Not during the cryptographic inventory. Not during the HNDL exposure analysis. Not during migration.