← Guide overview

What quantum threatens in a bank, and what it doesn't

Quantum Readiness for Banking Professionals: all chapters

• 1. What quantum threatens in a bank, and what it doesn't
• 2. Where cryptography lives in a payments estate
• 3. Building a cryptographic inventory
• 4. Deciding what to fix first
• 5. Crypto-agility first
• 6. Vendors and third parties
• 7. Governance and the regulatory map
• 8. A phased roadmap
• Readiness self-assessment
• Glossary

On this page

1. Meet Larkfield Bank
2. The one-sentence version
3. What is threatened, function by function
4. What is not threatened
5. The two clocks
6. Why this is a governance problem, not just a technical one
7. Five questions for your next steering committee
8. Sources and further reading

This guide is for the people in a bank who will be asked to own, fund, plan or oversee the move to quantum-safe cryptography: programme and portfolio leads, risk and governance managers, business analysts, and the executives they report to. You don't need to understand the mathematics. You do need to understand what is at risk, why the work takes years, and how to organise it. That's what the next eight chapters cover.

This first chapter answers the question every steering committee asks first: what exactly does a quantum computer threaten in a bank, and what doesn't it?

Meet Larkfield Bank

To keep things concrete, the guide follows one invented institution throughout. Larkfield Bank is fictional. It's a composite of a typical mid-sized Canadian bank, built from public descriptions of how banks work, and it doesn't describe any real institution.

CustomersAbout two million retail and business customers, online and mobile banking, a branch network.

PaymentsDebit and credit cards, interbank wires through the SWIFT network and Canada's Lynx system, real-time payments, and file-based payments with corporate clients.

TechnologyAround 400 applications, a core banking platform from a major vendor, hardware security modules (HSMs) for its most sensitive keys, and dozens of technology suppliers.

DataAccount records, transaction history, identity documents and mortgage files, many of which must be kept for years and some for decades.

At Larkfield, nobody owns "quantum" yet. The CISO has heard about it at conferences, enterprise architecture has a slide on it, and the board risk committee asked a question about it last quarter that nobody could answer crisply. That's a very common starting point, and it's where this guide begins.

The one-sentence version

A large quantum computer would break the cryptography banks use to establish trust and agree on keys, while the cryptography used to scramble the data itself would survive with larger keys.

Almost everything in this guide follows from that sentence, so it's worth unpacking.

Banks use two broad families of cryptography. Public-key cryptography (RSA and elliptic-curve cryptography are the names you'll hear) lets two systems that have never met agree on a secret key, and lets software prove who sent something through digital signatures and certificates. Symmetric cryptography (mostly AES) and hash functions (the SHA family) then do the bulk work of encrypting data and checking it hasn't been altered.

One clarification before going further. Post-quantum algorithms are public-key cryptography too; they're simply built on different mathematics. So when this guide talks about vulnerable public-key cryptography, it means RSA and the closely related discrete-logarithm systems, which include the elliptic-curve schemes banks use most.

A quantum algorithm discovered by Peter Shor in 1994 would let a sufficiently large quantum computer break RSA and those discrete-logarithm systems completely. Another, Lov Grover's search algorithm, only weakens symmetric cryptography and hashing. For encryption, 256-bit keys are generally considered enough. For hashes, the requirement depends on the job: resisting someone reversing a fingerprint is a different property from resisting two inputs with the same fingerprint, and each use should be checked against current guidance. Many banks already use sizes that are fine.

So a bank's quantum programme is overwhelmingly about one thing: finding and replacing RSA and elliptic-curve cryptography. For a governance lead, that's useful. It turns "quantum breaks our encryption", which sounds unbounded, into a defined scope.

What is threatened, function by function

It helps to sort a bank's cryptography by the job it does rather than by algorithm name. Here is how the threat lands on each job, with Larkfield examples.

Job	Larkfield examples	Quantum effect	When it matters
Agreeing keys for secure connections	Online banking sessions, APIs, links to SWIFT and Lynx, connections to suppliers	Broken (RSA and elliptic-curve)	Already: recorded traffic can be decrypted later
Proving identity with signatures and certificates	Website and system certificates, payment message signing, card authentication, signed software updates	Broken (RSA and elliptic-curve)	From the day a capable machine exists, but slow to replace
Holding the most sensitive keys	RSA and elliptic-curve keys stored in HSMs	Broken: the device protects the key, not the maths	Same as above
Encrypting stored and transmitted data	Database and backup encryption, encrypted file transfers once a key is agreed	Weakened; 256-bit keys remain strong	Check key sizes; no new algorithm needed
Checking data hasn't changed	Message integrity checks, hashing in logs and records	Weakened; modern hashes such as SHA-256 and longer remain strong	Check hash function and size for each use

Two details in that table catch executives out.

The attacker only needs the public key. Shor's algorithm works out a private key from its matching public key, and public keys are, by design, public: they sit in certificates and are sent openly at the start of every connection. This isn't a perimeter problem that firewalls or monitoring can solve. The weakness is in the mathematics.

Keys in HSMs are not protected from this. A hardware security module stops a key being stolen or misused. It doesn't change the key's mathematics. An RSA key inside an HSM is still breakable from its public half, without anyone touching the device. "Our keys are in HSMs, so we're fine" is a common and understandable misconception worth correcting early.

What is not threatened

Precision about what isn't at risk is just as important, because overstating the threat damages credibility with technical teams and with boards alike.

• Not "all encryption". Bulk data encryption with AES-256 and modern hashing remain sound. Larkfield doesn't need to re-encrypt its databases with new algorithms.
• Not today. No quantum computer capable of breaking today's public-key cryptography exists. Nobody knows when one will, and this guide won't pretend to. Chapter 4 shows why you don't need a date to plan.
• Not a reason for exotic hardware. The defence is post-quantum cryptography: new algorithms, standardised by NIST in 2024, that run on the computers banks already have. Quantum networking hardware isn't required.
• Not mainly a technology purchase. No single product makes a bank quantum-safe. The work is finding where RSA and elliptic-curve cryptography are used and replacing them, system by system, with suppliers and counterparties moving at the same time.

The two clocks

The table above has a column that matters more than any other: when it matters. The threat runs on two separate clocks, and they set different priorities.

The confidentiality clock is already running. An adversary can record encrypted traffic today and store it until a quantum computer can unlock it. This is called "harvest now, decrypt later". At Larkfield, the payment messages and account data crossing its networks this year will still be sensitive in ten years: they reveal who pays whom, account details and personal information. If that traffic is captured now, its protection has a shelf life, and nothing done later can undo the capture.

The integrity clock starts later but needs a long run-up. Harvesting gives an attacker nothing to decrypt in a signature, and forgery becomes possible only once a capable quantum computer can work out signing keys. From then on, though, an attacker could create signatures that verify under an old public key, including ones made to look historical. Whether such a forgery is believed would depend on timestamps, archives and other evidence, so long-lived signed records need planning too. And the things that check signatures, such as payment cards in wallets, ATMs, network equipment, supplier systems and the certificate chains that let banks trust each other's messages, are spread across many owners and replaced on long cycles. Changing them takes years of coordination.

Confidentiality (key agreement)

exposure accrues from today

Integrity (signatures)

long preparation needed

The practical consequence, explored in Chapter 4, is a simple ordering principle: deal first with the harm that can't be undone. Data captured today can never be un-captured, so protecting key agreement on the most sensitive connections usually comes before replacing signatures.

Why this is a governance problem, not just a technical one

Larkfield's security engineers can explain the cryptography. What they can't do on their own is run the response, for four reasons that each get their own chapter.

1. Nobody knows where all the cryptography is. It's spread across applications, infrastructure, suppliers' products and configuration files. Building that picture is an organisation-wide exercise (Chapters 2 and 3).
2. Everything can't be fixed at once. Someone has to decide what goes first, using business judgement about data sensitivity and retention, not just technical ease (Chapter 4).
3. Much of it belongs to someone else. Vendors, payment networks and counterparties control large parts of the estate, so contracts, roadmaps and third-party risk management come into play (Chapter 6).
4. It outlasts budget cycles. A programme running to the mid-2030s needs a named owner, a place on the risk register and regular reporting, with regulators increasingly asking how it's being managed (Chapter 7).

That's the shape of work that business analysts, programme managers and risk leads do every day. The cryptography is new; the disciplines aren't.

Five questions for your next steering committee

1. Do we know, even roughly, how many of our systems rely on RSA or elliptic-curve cryptography?
2. Which of our data must remain confidential for ten years or more, and which connections carry it?
3. Who owns quantum-readiness today, and is it recorded on the technology risk register?
4. Have we asked our most critical suppliers when their products will support post-quantum cryptography?
5. Does anyone believe our HSMs protect us from this? (If so, start there.)

Sources and further reading

Larkfield Bank is fictional and its figures are illustrative. Everything else is drawn from the public sources below. Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account. Checked on 11 October 2026. Spotted an error? Email hello@plainquantum.com.

1. StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024
2. Peer-reviewed paperPolynomial-time algorithms for prime factorization and discrete logarithms on a quantum computerPeter Shor, SIAM Journal on Computing, 1997
3. Peer-reviewed paperA fast quantum mechanical algorithm for database searchLov Grover, STOC, 1996
4. Government guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023
5. Government guidanceRoadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Security, 2025
6. Government guidanceGuideline B-13: Technology and Cyber Risk ManagementOffice of the Superintendent of Financial Institutions (OSFI), 2022
7. Industry guidanceG7 Cyber Expert Group: coordinated roadmap for the transition to post-quantum cryptography in the financial sectorG7 Cyber Expert Group (via US Treasury), 2026