The breach is visible. The harvest may not be.
When a bank detects unauthorized access to a network appliance, the response is well-rehearsed: isolate the device, close the vulnerability, rotate credentials, file the incident report. If forensics confirm the exfiltrated files were encrypted, the investigation often closes with a reasonable conclusion – the attacker took nothing usable.
That conclusion depends on an assumption that no longer holds indefinitely: that encrypted data stays unreadable forever. Shor’s Algorithm is the reason it doesn’t. It gives a sufficiently capable quantum computer a mathematical shortcut through the problems RSA and ECC depend on – and it means data an attacker cannot read today may become readable years from now, using nothing more than a copy taken today.
This is not a restatement of what Shor’s Algorithm is or how it works. Shor’s Algorithm covers that ground in detail. This article addresses a narrower, more operational question: what does this algorithm actually threaten inside a bank’s infrastructure, and what has to happen before that threat becomes practical.
Why Shor’s Algorithm Changes the Banking Security Equation
Most cybersecurity threats operate on a single timeline: the attack and the damage happen close together. Shor’s Algorithm breaks that assumption. It introduces a threat with two separate dates – the date data is collected, and the date it becomes decryptable – that can be separated by years.
For a bank, that separation matters more than almost any other industry. Financial institutions hold data with confidentiality requirements measured in years or decades: account relationships, KYC documentation, wire records, board communications, regulatory correspondence. None of that data needs to be readable today for an attacker to consider it worth stealing today. It only needs to still matter on the day a cryptographically relevant quantum computer exists.
That is the equation Shor’s Algorithm changes. Security teams have always asked, “is this data protected right now?” The more relevant question is becoming: “will this data still need to be protected on a date we cannot yet fix on a calendar?”
What Does Shor’s Algorithm Actually Threaten?
Shor’s Algorithm does not threaten encryption uniformly. It targets a specific mathematical category – the public-key cryptography used to establish trust and exchange keys – not the symmetric encryption that protects bulk data. Understanding exactly where that line falls is what determines what a bank actually needs to replace.
RSA and Digital Signatures
RSA underpins both encryption and digital signatures across banking infrastructure – from TLS certificates to code-signing and authentication tokens. Shor’s Algorithm attacks the factoring problem RSA is built on, which means a cryptographically relevant quantum computer could, in principle, derive a private key from its public counterpart. Every signature and every encrypted session relying on RSA inherits that exposure.
ECC and Key Exchange
Elliptic curve cryptography secures much of modern TLS and key exchange, including ECDH and ECDSA. It relies on the elliptic curve discrete logarithm problem – a different problem from RSA’s factoring, but one Shor’s Algorithm solves through the same underlying technique. ECC is not a safer alternative to RSA against this threat; it shares the same category of exposure.
TLS and Secure Communications
TLS sessions – online banking, mobile app traffic, branch-to-headquarters links, API calls to payment processors – depend on RSA or ECC to establish the session key before symmetric encryption takes over. That handshake is the exposed step. The bulk data that follows is typically AES-encrypted, which Shor’s Algorithm does not efficiently break – but the key exchange that protected it is exposed, and recovering that key exposes everything encrypted under it.
Digital Certificates and PKI
Certificate authorities, trust chains, and the public-key infrastructure that authenticates servers, services, and devices are built on RSA or ECC signatures. If the signing keys behind that trust chain become forgeable, the authentication model itself – not just individual sessions – is compromised.
Long-Term Encrypted Financial Data
Archived records, backups, correspondent banking data, and litigation-hold documents are frequently encrypted with the same public-key infrastructure protecting live traffic. Data that must remain confidential for a decade or more carries the exposure forward regardless of when it was originally captured.
The Banking Data Problem: What Happens When Encrypted Data Is Harvested Today?
This is where the threat stops being theoretical. Harvest Now, Decrypt Later (HNDL) describes an attacker strategy already in use: intercept or exfiltrate encrypted data now, store it, and wait for the decryption capability to catch up. It requires no quantum computer at the collection stage – only network access, storage, and patience. Harvest Now, Decrypt Later (HNDL) covers the mechanics of how that collection happens and what it looks like from a security operations standpoint.
For a bank, the exposure isn’t abstract. Customer identity records, transaction histories, authentication logs, wire documentation, and board-level correspondence are the kind of data that satisfies two conditions simultaneously: it is routinely encrypted with RSA or ECC-protected sessions, and it needs to remain confidential well beyond any near-term planning horizon.
The quantum computer does not need to exist today for the confidentiality risk to begin today. The breach event – the moment data leaves the bank’s control – is what starts the clock. Decryption is simply a later step in an attack that has already succeeded.
This reframes how “no evidence of quantum attacks today” should be read. It is accurate – there is no public evidence that a cryptographically relevant quantum computer exists or that current-generation quantum hardware can break production RSA or ECC keys. But that statement describes the decryption stage, not the collection stage. Conventional intrusions, data exfiltration, and unauthorized access to encrypted archives are documented, ongoing realities across financial services and adjacent sectors – the kind of incidents disclosed in SEC filings and breach notifications every year. Whether any specific historical incident was collection for future quantum decryption specifically is rarely something a bank can determine at the time. That is precisely the point: the strategy is designed to look identical to a contained, low-consequence breach.
A Bank’s Cryptographic Perimeter Is Larger Than Its Network
A bank’s own network is rarely where its full cryptographic exposure lives. Modern financial infrastructure depends on a wide mesh of external connections, each carrying its own cryptographic dependencies that the bank does not directly control.
Third-party vendors handling core banking, payments, or customer communications maintain their own certificate infrastructure and TLS configurations. APIs connecting to payment processors, credit bureaus, and fintech partners each represent a key-exchange point. Cloud environments and managed services introduce cryptography through configurations the bank’s security team may never directly audit. File-transfer platforms used for batch settlement or regulatory reporting frequently rely on legacy protocol versions. Backup and archival systems – often the largest single repository of long-lived sensitive data – inherit whatever cryptographic standard was in place when they were built, sometimes years or decades earlier.
None of this is unique to any one institution, and it is not evidence of any specific quantum-related compromise. It reflects a documented pattern across the financial sector: third-party and vendor-related incidents are a recurring category in breach disclosures precisely because the cryptographic perimeter of a modern bank extends well past its own firewall. A bank’s PQC readiness assessment that stops at its own network has not actually assessed its real exposure.
What Financial Institutions Need to Identify Before Replacing RSA
Replacing RSA or ECC is not the first step – it’s one of the last. Before any replacement decision makes sense, an institution needs a clear picture of where those algorithms are actually in use.
Identify Where RSA and ECC Are Used
This starts broader than most institutions expect. RSA and ECC appear in TLS configurations, VPN tunnels, application code, embedded device firmware, API authentication, code-signing infrastructure, and certificate chains – often introduced by teams or vendors no longer directly involved in maintaining the system.
Build a Cryptographic Inventory
Discovery identifies what exists; inventory is the structured, maintained record of it – algorithms, key sizes, certificates, protocols, and the applications or business functions each one supports. Cryptographic discovery is the practical starting point most migration plans skip in favor of jumping straight to algorithm selection.
Identify Long-Lived Sensitive Data
Not every system carries equal urgency. Data that must remain confidential for years – customer records, KYC files, transaction archives – deserves migration priority well ahead of data with short-lived operational value.
Map Third-Party Cryptographic Dependencies
Every vendor, API, and managed service in the environment carries its own cryptographic posture. A migration plan that doesn’t account for a vendor’s own PQC roadmap will hit a bottleneck the bank doesn’t control.
Prioritize Critical Systems
Prioritization should follow exposure and business criticality – not a uniform, alphabetical rollout across every system simultaneously.
Assess Migration Constraints
Legacy applications, hardware security modules with limited algorithm support, and systems with strict uptime requirements each introduce constraints that shape how migration sequencing has to work in practice.
Why Replacing RSA Is Not a One-Step Migration
Swapping RSA for a post-quantum algorithm is not a configuration change. It touches certificates, key management systems, application code with hard-coded cryptographic calls, authentication protocols, and every system that has to interoperate with the newly migrated one during the transition period.
Performance characteristics differ between algorithm families, which can affect systems with strict latency requirements. Interoperability has to be validated before and during rollout – a certificate chain that mixes legacy and post-quantum signatures needs to function correctly across every client and server that touches it. Many institutions are approaching this through hybrid deployments, running classical and post-quantum algorithms in parallel during the transition to preserve compatibility while building confidence in the new standards.
This is why crypto-agility – the ability to update cryptographic algorithms, keys, and certificates without rebuilding the systems around them – matters more than the specific algorithm chosen today. Standards will continue to evolve. An institution that migrates once and treats the work as finished will face the same disruption again the next time a standard changes.
Where Post-Quantum Cryptography Fits
Post-quantum cryptography (PQC) is the direct response to what Shor’s Algorithm threatens: a new generation of algorithms built on mathematical problems – structured lattice problems, among others – that are not known to be efficiently solvable by Shor’s Algorithm or any other currently known quantum algorithm.
In August 2024, NIST finalized its first three PQC standards. FIPS 203 specifies ML-KEM, the primary key-encapsulation mechanism intended to replace RSA and ECDH for key exchange. FIPS 204 specifies ML-DSA, a lattice-based digital signature standard intended to replace RSA and ECDSA for signatures. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme offering a conservative, independently-founded alternative to lattice-based signatures.
These are federal standards. They are not, on their own, an automatic legal mandate binding every private-sector financial institution – but they function as the reference point vendors, examiners, and industry guidance are converging around, which is why institutions aligning early tend to face less disruption than those waiting for an explicit deadline. Regulatory context and NIST PQC guidance covers how federal direction is shaping expectations across the financial sector.
What Should Banks Do Now?
A practical PQC migration follows a sequence, not a single decision:
Discover – identify where RSA, ECC, and other quantum-vulnerable algorithms are actually in use.
Inventory – document what discovery finds in a structured, maintained record.
Assess – evaluate what each cryptographic asset protects and how exposed it is.
Prioritize – sequence systems by data sensitivity, longevity, and business criticality.
Plan – build a phased roadmap that accounts for vendor readiness and operational constraints.
Test – validate interoperability and performance before enterprise-wide deployment.
Migrate – transition prioritized systems to NIST-aligned, quantum-resistant algorithms.
Maintain crypto-agility – build the capability to update algorithms again as standards evolve.
None of this requires waiting for a cryptographically relevant quantum computer to exist. The data being harvested today doesn’t wait either. Post-quantum cryptography for financial institutions walks through how this sequence applies specifically to banking environments, and post-quantum cryptography services for banks outlines how this work gets structured in practice.
What the Texas Bankers ISAO Conversation Means for Financial Institutions
Quantum Infinite addressed this exact intersection of technical risk and operational planning directly with industry stakeholders through the Texas Bankers ISAO session, “Quantum Risk to Quantum Resilience: A Practical Session for Financial Institutions.” The conversation focused on what financial institutions can practically act on now – cryptographic discovery, exposure assessment, and migration sequencing – rather than treating quantum risk as a distant, unstructured concern.
That distinction matters. The institutions best positioned when standards and deadlines tighten further are the ones that have already built visibility into their own cryptographic environment, not the ones that begin discovery after the fact.
Shor’s Algorithm Is the Warning – Migration Is the Response
Shor’s Algorithm does not need to be running against a bank’s RSA keys today for the risk to be real today. The breach – the collection – happens now, using conventional intrusion methods that require no quantum capability at all. What changes in the future is not whether the data was taken; it’s whether it can be read.
RSA and ECC secure the trust layer underneath most of banking’s digital infrastructure – TLS, signatures, certificates, authentication. That exposure extends past the bank’s own network into every vendor, API, and archive that touches its data. Addressing it starts with knowing where that cryptography actually lives, not with selecting a replacement algorithm first.
NIST’s finalized PQC standards give institutions a defined target. Cryptographic discovery, inventory, and risk-based prioritization give them a route to get there – deliberately, on a timeline they control, rather than one dictated by an exposure window that may have already opened.
Frequently Asked Questions
Que.1 Can Shor’s Algorithm break RSA?
Ans. Yes, in principle. A quantum computer capable of running Shor’s Algorithm against RSA-sized keys could factor the public modulus and recover the private key, undermining RSA’s core security assumption. No current quantum hardware can do this against real-world key sizes.
Que.2 Does Shor’s Algorithm threaten banks?
Ans. Yes. Banks rely heavily on RSA and ECC for TLS, digital certificates, authentication, and PKI – all exposed by Shor’s Algorithm. Combined with long data-retention requirements and third-party cryptographic dependencies, financial institutions carry more exposure than most industries.
Que.3 Which banking systems use RSA or ECC?
Ans. TLS connections for online and mobile banking, digital certificates and PKI, VPNs and branch-to-headquarters links, API authentication with payment processors and vendors, code-signing systems, and archival systems encrypted under older key-exchange standards.
Que.4 What is Harvest Now, Decrypt Later?
Ans. Harvest Now, Decrypt Later (HNDL) is an attacker strategy of collecting encrypted data today and storing it until a future quantum computer can decrypt it. It requires no quantum capability at the collection stage – only network access and patience.
Que.5 Does a bank need to wait for a quantum computer before migrating?
Ans. No. Data harvested today remains exposed regardless of when decryption becomes possible. Migration timelines for large institutions run into years, which is why starting cryptographic discovery now – rather than after a quantum computer exists – determines whether the transition finishes in time.
Que.6 What should banks replace before quantum computers can break current cryptography?
Ans. RSA and ECC used for key exchange and digital signatures – in TLS, PKI, certificates, and authentication systems – with NIST-standardized post-quantum algorithms: ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures.
Que.7 How does post-quantum cryptography protect financial institutions?
Ans. PQC algorithms are built on mathematical problems not known to be efficiently solvable by Shor’s Algorithm, replacing the vulnerable RSA/ECC layer that protects key exchange and signatures while leaving already-strong symmetric encryption like AES-256 largely unaffected.
Que.8 What should a bank do first for PQC migration?
Ans. Cryptographic discovery – identifying where RSA, ECC, and other vulnerable algorithms are actually in use across applications, certificates, vendors, and infrastructure – before any algorithm selection or replacement decision.