For most of the last decade, post-quantum cryptography (PQC) sat in the "important but not yet urgent" column of the bank technology roadmap. 2026 moved it. In March, Google set 2029 as the target for its own post-quantum migration. Less than two weeks later, Cloudflare adopted the same year. In June, a US executive order gave high-value federal systems hard deadlines of 2030 and 2031. And in October the conversation reached the payments back office: Nacha's Payments Innovation Alliance published a vendor questionnaire so financial institutions can ask every supplier where its cryptography lives and when it will be quantum-safe.
This article explains what the quantum threat actually breaks, why the timelines moved, what is already deployed, and how I would structure a post-quantum migration in a bank or payments company.
What quantum computers break, and what they do not
Banking runs on two families of cryptography. Symmetric algorithms such as AES encrypt bulk data quickly. Asymmetric (public-key) algorithms such as RSA and elliptic-curve cryptography (ECC) set up secure channels, exchange the symmetric keys and produce digital signatures for identity, certificates, code signing and non-repudiation. The Bank for International Settlements' roadmap for the financial system summarises the asymmetry of the threat: a cryptographically relevant quantum computer (CRQC) running Shor's algorithm could recover private keys and so forge signatures or unwrap the symmetric keys that protect data. Grover's algorithm only gives a quadratic speed-up against symmetric keys, a risk that can be handled for now with larger keys, which is why governments recommend AES with 256-bit keys for sensitive data.
That creates two distinct risks:
- Harvest now, decrypt later (HNDL). An adversary records encrypted traffic today and decrypts it once a CRQC exists. This is a present-day risk for anything that must stay confidential for years: financial records, biometric data, long-term contracts.
- Forged authentication. Breaking a signature requires a working quantum computer in real time, so it is a future threat. But when it arrives, the impact is worse. As Cloudflare puts it, data leaks are severe, but broken authentication is catastrophic: any overlooked quantum-vulnerable key becomes a door, and any automatic software-update mechanism becomes a remote code execution path.
The BIS paper adds a point that matters for banks in particular: long-lived signatures on mortgages and other digitally signed contracts may need to be re-signed or counter-signed with quantum-safe signatures, and devices that verify software updates may need post-quantum signature support built in when they are manufactured.
The standards are ready
The tools exist. In August 2024 NIST finalised its first three post-quantum standards after an eight-year process that assessed 82 algorithms from 25 countries:
- FIPS 203, ML-KEM (from CRYSTALS-Kyber): the primary standard for key establishment, the "encryption" side.
- FIPS 204, ML-DSA (from CRYSTALS-Dilithium): the primary standard for digital signatures.
- FIPS 205, SLH-DSA (from SPHINCS+): a hash-based signature standard built on different mathematics, intended as a backup if ML-DSA proves vulnerable.
NIST's message at the time was direct: "There is no need to wait for future standards." Its draft transition report, NIST IR 8547, then set the end date for today's algorithms: RSA and elliptic-curve signatures and key exchange at 112-bit security are deprecated after 2030, and quantum-vulnerable public-key algorithms are disallowed after 2035.
Why 2026 changed the timeline
Three developments compressed the planning horizon this year.
1. Big technology providers moved first. On 25 March Google announced a 2029 target for its PQC migration, citing progress in quantum hardware, quantum error correction and factoring resource estimates. Google also changed its priority: because signatures must be migrated before a CRQC exists, it now puts authentication services first and recommends that other engineering teams do the same. Android 17 is adding ML-DSA signature protection. On 7 April Cloudflare followed with a 2029 target for full post-quantum security, including authentication. Cloudflare's explanation points to research announced the week before: according to Cloudflare, Google said it had greatly improved the quantum algorithm for breaking elliptic-curve cryptography and published a zero-knowledge proof instead of the algorithm itself, and Oratomic published a resource estimate in which breaking P-256 on a neutral-atom computer required about 10,000 qubits. These are claims about research, not a demonstrated attack, but they are the reason two of the internet's largest operators shortened their own deadlines.
2. Governments set dates. The G7 Cyber Expert Group's January 2026 roadmap for the financial sector points to 2035 as the overall target and suggests addressing the most critical systems in 2030–32. The US executive order "Securing the Nation Against Advanced Cryptographic Attacks", signed on 22 June, requires federal high-value assets and high-impact systems to use PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031. It also directs CISA and NIST to publish minimum elements of a cryptographic bill of materials (CBOM) within 270 days, and asks federal procurement rules to require contractors to comply with PQC-inclusive FIPS standards by the end of 2030.
3. The supply chain is being asked to show its work. Nacha's quantum-safe readiness instructions state the consequence plainly: vendors will need to provide CBOMs, financial institutions will need to ingest them into risk management, and procurement will change to require PQC-compliant components. Its questionnaire covers six areas: compliance, keeping payment services running, accountability, preparing for the unexpected, contractual terms and collaboration.
What is already deployed
Post-quantum encryption is no longer experimental. Cloudflare says it enabled post-quantum encryption for all websites and APIs in 2022, and that over 65% of human traffic to its network is now post-quantum encrypted. It uses hybrid key agreement, and its recommended scheme, X25519MLKEM768, combines classical X25519 with ML-KEM. In July 2026 it began supporting ML-DSA signatures for the connection between Cloudflare and customer origin servers.
In payments, South Korea's Toss Payments reported in April 2026 that it had applied PQC across its whole electronic payment flow, including its data centres, AWS infrastructure and payment pages. Users on recent Chrome, Edge, Safari and Firefox get it automatically, and older environments fall back to existing encryption. Notably, Toss had first moved to TLS 1.3 in 2025, which is the prerequisite: the BIS paper notes that TLS 1.2 cannot be configured with post-quantum algorithms.
Post-quantum authentication is the hard part. Cloudflare's own product status still lists visitor-facing signatures as planned, and it warns that adding PQC is not enough: quantum-vulnerable algorithms must eventually be turned off to prevent downgrade attacks, and secrets exposed under the old cryptography must be rotated.
Why banking is harder than the web
From a bank technology perspective, the web is the easy case. The difficult estate is everything that does not update itself automatically: core banking platforms, card and payment switches, hardware security modules (HSMs), ATMs and point-of-sale terminals, interbank links, batch file transfers with partners, and long-retention archives. Much of that cryptography is embedded in vendor products or decades-old integrations, which is why the G7 roadmap and Nacha both emphasise third-party dependencies, and why the BIS paper warns against treating the change as a simple algorithm replacement. PQC keys and signatures are also larger, and the BIS notes performance trade-offs and implementation complexity that require testing across the full stack, from hardware and libraries to protocols and applications.
A post-quantum migration plan for banks
The phases below follow the G7 roadmap (awareness, discovery, risk assessment, execution, testing, validation), with practical lessons from the security leaders BankInfoSecurity interviewed in October.
- Fund discovery first, not the whole programme. Francis Gorman of Bank of Ireland suggests asking the board for about 18 months to understand the exposure and come back with a sized programme. Leave the physics out: directors need to know which services and data are exposed, how long fixing it will take and what to fund first.
- Build a cryptographic inventory. Map every algorithm, key, certificate and protocol to the business service it protects and to how long that data must remain confidential. Long-lived sensitive data is your HNDL exposure; long-lived keys and code-signing roots are your authentication exposure.
- Make vendors part of the plan. Send a structured questionnaire (Nacha's is a ready-made starting point), ask for CBOMs and roadmaps, and repeat at least annually. Cloudflare's advice is to make post-quantum support a procurement requirement.
- Take a quick, visible win. Gorman describes hybrid key exchange on external endpoints as low-hanging fruit that needs only configuration changes and also reveals which clients still depend on older protocols. Upgrading to TLS 1.3 is part of the same step.
- Prioritise authentication and long-lived keys. Root and intermediate certificates, API authentication keys, code-signing keys and HSM-held master keys deserve early attention, in line with Google's and Cloudflare's revised threat models.
- Design for cryptographic agility. The BIS defines it as the ability to change algorithms, parameters and keys quickly with minimal disruption. Centralise cryptography behind services and libraries rather than hard-coding it into applications, so the next change is configuration, not a rewrite. NIST itself has noted that this transition "will certainly not be the last one required", as the G7 statement quotes.
- Measure progress the board can understand. Useful metrics include the share of critical services assessed, unsupported systems identified, certificate-management coverage, vendors evaluated and the time needed to execute a cryptographic change. Gorman's example target: "80% of all public certificates managed end-to-end by 2029".
- Plan the budget honestly. Forrester's Jitin Shabadu told BankInfoSecurity that many Fortune 50 and Fortune 100 companies are budgeting close to $100 million over a decade, and Gorman put the full journey at five to 15 years. None of this is wasted if Q-Day comes late: inventory, certificate automation and agility pay off for every future cryptographic change.
This is also where post-quantum planning meets other banking initiatives. Agentic payments, which I covered in Agentic payments in 2026, rely on signed intent and scoped credentials; those signatures need the same quantum-safe roadmap. And a cryptographic inventory is, in the end, a data problem: the discipline of building a single trusted view, which I described for a unified data warehouse for brokers, applies to keys and certificates as much as to customers.
Closing thought
Nobody can give a reliable date for Q-Day, and boards do not need one. What changed in 2026 is that the people building quantum computers and running the internet's largest networks have shortened their own deadlines, regulators have written dates down, and the payments supply chain has started asking vendors for evidence. For a bank, the question is no longer whether post-quantum cryptography is needed but whether the migration will start early enough to be done calmly. Start with the inventory, the vendors and the authentication keys; everything else follows from knowing where your cryptography lives.
References
- Making the Case to the Board for Post-Quantum Readiness, BankInfoSecurity (ISMG), 7 October 2026
- Quantum-Safe Encryption Readiness: Instructions for Financial Institutions, Using the Vendor Questionnaire, Nacha Payments Innovation Alliance, 2026
- Securing the Nation Against Advanced Cryptographic Attacks, The White House, 22 June 2026
- Cloudflare targets 2029 for full post-quantum security, Cloudflare Blog, 7 April 2026
- Post-quantum authentication to origins is now supported, Cloudflare Blog, 29 July 2026
- PQC in Cloudflare products, Cloudflare Docs
- Quantum frontiers may be closer than they appear, Google, 25 March 2026
- G7 Cyber Expert Group Statement on Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector, G7 Cyber Expert Group via GOV.UK, 13 January 2026
- Quantum-readiness for the financial system: a roadmap (BIS Papers No 158), Bank for International Settlements, July 2025
- NIST Releases First 3 Finalized Post-Quantum Encryption Standards, NIST, 13 August 2024
- Transition to Post-Quantum Cryptography Standards (NIST IR 8547, initial public draft), NIST, November 2024
- Toss Payments becomes first in South Korea's finance, IT sectors to fully adopt post-quantum cryptography, DigitalToday, 3 April 2026