Why your bank is already preparing
On this page
- A day in the life of your money
- Two kinds of lock
- Which lock quantum breaks
- Harvest now, decrypt later
- The simple test: Mosca's inequality
- The new locks already exist
- What governments and regulators are saying
- Why it's hard for banks
- Banks have done this before
- What a migration looks like
- What it means for you as a customer
- Five questions to ask your organisation
- Sources and further reading
No quantum computer today can break into online banking. Yet banks, regulators and governments are already spending real money preparing for one. This piece explains why, from someone who has spent fifteen years inside banking and payment systems. It's the longest in the series, because it pulls together everything from Parts 1 to 4.
A day in the life of your money
Before talking about threats, it helps to see how much cryptography a single ordinary day involves. Suppose you check your balance, buy a coffee and pay a supplier overseas.
- Opening your banking app. Your phone and the bank's servers set up an encrypted connection, the same padlock you see in a browser. Public-key cryptography lets them agree on a secret key without ever having met, and a digital certificate proves you're talking to the real bank.
- Tapping your card. The chip in your card holds cryptographic keys. It proves to the terminal that it's a genuine card, using certificates issued through the card networks.
- Sending money abroad. Your payment becomes a structured message passed between banks, often over international networks and through national systems such as Canada's Lynx. Those messages travel over encrypted links, and banks use certificates and digital signatures to prove each message really came from the bank that sent it and hasn't been altered.
- Behind the scenes. The most important keys live inside hardened devices called hardware security modules, and the bank's internal systems talk to each other over encrypted channels too.
Most people never see any of this. That's the point: it works quietly. But it means cryptography is spread across thousands of systems, many built by different vendors, at different times, under different owners.
Two kinds of lock
Almost everything in that list relies on two kinds of cryptography working together.
Public-key cryptography (names you'll hear: RSA, elliptic curve) does two jobs. It lets two parties agree on a secret key over an open network, and it lets software prove who sent a message through digital signatures. It protects the padlock in your browser, app logins, card chips and the certificates banks use to trust each other's messages.
Symmetric cryptography (AES is the common one) then uses that agreed key to scramble the actual data quickly. It's the workhorse that encrypts the contents of your session, your stored records and much more.
Which lock quantum breaks
Shor's algorithm, from Part 4, breaks the maths behind RSA and elliptic-curve cryptography. A large, error-corrected quantum computer could work out the private keys behind those systems. With a stolen private key, an attacker could read traffic protected by it, or forge signatures that look exactly like the bank's own.
Symmetric encryption fares much better. Grover's search speed-up only weakens it modestly, and using longer keys such as 256-bit AES is generally considered enough. So the urgent job is replacing public-key cryptography, which happens to be the part spread through every system in the list above.
People in the field call the hypothetical day a quantum computer can do this Q-day, and the machine a cryptographically relevant quantum computer. Nobody knows the date. The planning challenge is acting sensibly without knowing it.
Harvest now, decrypt later
Here's why "it's years away" isn't reassuring. An attacker can copy encrypted traffic today, store it cheaply, and wait. When a capable quantum computer arrives, they unlock it. Anything that still matters at that point is exposed: account records, identity data, contracts, trade secrets.
This threat is about confidentiality, the secrets inside the data. Signatures are a slightly different story: a forged signature only matters once someone can actually forge it, so the risk there starts on Q-day itself. But systems that rely on signatures, like the certificates inside card chips or the software running payment hardware, can take many years to replace, so they need planning now too. There's a fuller explanation in the library: "Harvest now, decrypt later," explained.
The simple test: Mosca's inequality
The University of Waterloo researcher Michele Mosca framed the question as three numbers:
Nobody knows Z for certain. But for a bank, X can be decades: mortgages run for twenty-five years, identity records are kept for a long time, and some data must stay confidential indefinitely. Y is long too, for reasons we'll get to below. Put those together and the arithmetic says the work has to start well before anyone can point to a working quantum computer. That's why it has.
The new locks already exist
In August 2024 the US National Institute of Standards and Technology (NIST) published its first post-quantum cryptography standards, after an open international competition that began in 2016. They run on ordinary computers and are designed to resist quantum attacks.
These aren't experimental anymore. Major web browsers and services already use a hybrid of old and new key exchange for many connections, which means a lot of everyday web traffic has quietly gained some protection against harvest-now attacks. There's a plain guide to how the new algorithms work in Post-quantum cryptography for non-engineers.
What governments and regulators are saying
Here's an odd feature of this problem: the threat date is uncertain, but the deadlines are not. Governments and standards bodies have stopped waiting for a quantum computer and started publishing a calendar.
- United States. NIST's draft transition plan proposes deprecating today's vulnerable public-key algorithms from 2030 and disallowing them by 2035. The NSA's CNSA 2.0 guidance requires post-quantum algorithms in new national security systems acquired from 2027.
- European Union. A coordinated EU roadmap published in June 2025 asks member states to have cryptographic inventories in place by the end of 2026, high-risk systems moved by 2030, and the rest by 2035.
- Canada. The Canadian Centre for Cyber Security's roadmap for federal government systems, published in June 2025, asks departments for migration plans by April 2026, high-priority systems migrated by the end of 2031, and everything else by the end of 2035.
- The financial sector. The G7 Cyber Expert Group, which brings together finance ministries and central banks, has set out a coordinated post-quantum roadmap for financial institutions. It is explicitly guidance rather than regulation, but it calls for named executive ownership and crypto-agility. Central banks have run practical trials too: the Bank for International Settlements' Project Leap, with the Banque de France and Deutsche Bundesbank, tested post-quantum cryptography on communications for a real payment system.
For Canadian banks the picture is worth stating precisely, because it's easy to overstate. The federal government's dates bind government systems, not banks. Canada's banking regulator, OSFI, has not issued a separate post-quantum deadline. Instead it expects banks to manage quantum risk within their existing technology and cyber-risk obligations under its Guideline B-13, and in 2023 OSFI and the Financial Consumer Agency of Canada surveyed financial institutions on their readiness for AI and quantum computing.
Put together, the signals from many independent authorities point at the same shape: inventories now, high-risk systems around 2030, everything by 2035. A bank doesn't need a deadline addressed to it personally to read that direction.
You migrate to the calendar, not to the day a quantum computer is announced. By then the lead time is gone and the harvested data is already lost.
Why it's hard for banks
So far this article has been about the threat. Responding to it is a different kind of problem: less about cryptography than about running a large, multi-year change programme across systems, vendors and partners.
Swapping algorithms sounds like a software update. It isn't, for six reasons.
Nobody has a complete list. Cryptography is in websites and apps, but also in card systems, ATMs, hardware security modules, payment messaging, links to partners and vendors, and decades-old systems nobody wants to touch. Automated scanning tools find a lot of it. Some of the most important uses, though, are set in configuration files and middleware that only people who know the payment flows would think to check.
Trust chains cascade. Banks prove identity using chains of certificates, from a root authority down to individual systems. A chain is only as quantum-safe as its weakest link, and anyone who could forge the root could impersonate everything beneath it. That puts the certificate infrastructure behind payment messaging near the top of the list, and it can only move as fast as the whole network agrees to.
Both ends have to change. A payment message is only as safe as the weakest link between sending bank, network and receiving bank. That means coordinating with other institutions, payment networks and vendors, not just upgrading your own systems.
Hardware lasts. Payment cards sit in wallets for years. Terminals, ATMs and hardware security modules are replaced on long cycles, and some can't simply be updated with new algorithms.
The new keys are bigger. Post-quantum keys and signatures are many times larger than today's. In most places that's fine, but systems with tight size limits, like card chips or some message formats, need careful testing.
It has to happen without breaking anything. Banks can't stop processing payments for an upgrade. Changes go in gradually, tested in stages, with rollback plans.
Banks have done this before
None of this is entirely new. The financial industry has retired cryptography before, and those experiences shape how it approaches quantum.
In the 1990s and 2000s, the DES encryption standard became too weak as computers got faster, and banks moved to triple DES and then AES. Card networks and ATM systems took many years to complete that change. In the 2010s, the SHA-1 algorithm used in website certificates was shown to be weakening; browsers announced deadlines, and by around 2017 they stopped trusting SHA-1 certificates altogether. Organisations that hadn't kept track of where SHA-1 was used found out the hard way, when systems broke.
Payments also has recent experience of huge, coordinated industry change that isn't about cryptography. The move to the ISO 20022 messaging standard for cross-border and high-value payments took years of planning, with thousands of banks worldwide running old and new formats side by side until a fixed cut-over date. It showed that an industry can coordinate a deep change across many institutions, and also how long that takes even with a clear standard and deadline.
The lessons carry straight over: know where everything is, plan for a long period of running old and new together, coordinate with counterparties early, and expect it to take longer than the first estimate. Post-quantum migration is bigger than any of these, because public-key cryptography touches more systems, but it isn't a leap into the unknown.
What a migration looks like
One simplification helps enormously. The quantum problem in payments is almost entirely a public-key problem. Symmetric encryption and hashing survive with larger keys, so the programme is mostly about replacing the public-key layer: key exchange, signatures and the keys held in hardware security modules. A typical plan runs in four phases, timed against the 2030 and 2035 horizon:
- Inventory and crypto-agility (now). Build a cryptographic inventory, often called a cryptographic bill of materials: every place cryptography is used, which algorithm, what it protects, how long that data must stay secret and who owns it. At the same time, make algorithms swappable through configuration rather than rebuilds. Nothing else can happen without these two.
- Hybrid pilots (next few years). Turn on hybrid key exchange, old and new together, starting with the connections that carry the longest-lived sensitive data. That stops new traffic being harvested.
- Production migration (towards 2030). Move signatures, certificate chains and hardware key storage to the new algorithms. Much of this moves in step with payment networks and vendors.
- Retire the old algorithms (2030 to 2035). Remove RSA and elliptic-curve cryptography from the payment path entirely.
The order follows a simple principle: fix the harm you can't undo first. Data captured today can never be un-captured, so key exchange on sensitive channels comes before signatures, which only become forgeable once a quantum computer exists.
What it means for you as a customer
For now, nothing you need to do, beyond keeping your phone, browser and banking apps updated so you get the new protections as they arrive. Your money is not at risk from quantum computers today.
One practical warning: as "quantum" becomes a buzzword, expect scammers to use it. No genuine bank will ask you to move money or share passwords to "protect your account from quantum hackers".
Five questions to ask your organisation
- Do we have an inventory of where we use public-key cryptography?
- Which of our data needs to stay confidential for ten years or more?
- Who owns post-quantum migration, and is it on the risk register?
- What are our key vendors and partners planning, and by when?
- Could we change algorithms without rebuilding our systems?
- Quantum threatens public-key cryptography, the part that agrees keys and proves identity.
- Data stolen today can be decrypted later, so long-lived secrets are already at risk.
- Replacement standards exist. The hard part is finding and migrating every place cryptography hides.
Built from public standards and published research. Views are the author's own and describe the industry in general, not any specific institution. Educational only; not security advice for any specific organisation.
You now know more about quantum computing than most people in the room. To go further, read "Harvest now, decrypt later," explained and Post-quantum cryptography for non-engineers, or browse the library.
Sources and further reading
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. Dates and figures were checked against these sources on 11 October 2026. Spotted an error? Email hello@plainquantum.com and it will be corrected, with a note.
- StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024
- Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024
- Government guidanceNSA releases future quantum-resistant algorithm requirements for national security systems (CNSA 2.0)US National Security Agency, 2022
- Government guidanceA Coordinated Implementation Roadmap for the Transition to Post-Quantum CryptographyEuropean Commission / NIS Cooperation Group, 2025
- Government guidanceRoadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Security, 2025
- Government guidanceGuideline B-13: Technology and Cyber Risk ManagementOffice of the Superintendent of Financial Institutions (OSFI), 2022
- 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
- ExperimentProject LeapBIS Innovation Hub
- Peer-reviewed paperCybersecurity in an era with quantum computers: will we be ready?Michele Mosca, IEEE Security & Privacy, 2018
- Government guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023
- StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP