Is Your Bank Ready for Quantum Computers? We Checked the World's 100 Largest

Abstract

Key Points at a Glance

Short on time? The Key Points above and Figure 1 below give the full picture. Sections 1–8 present the findings and what they mean for banks; Sections 9 and 10 explain the technical background and how we ran the scan. Every bank's individual result is in Appendix A.

1. Headline Results

We asked one question: when a customer opens their bank's website or online-banking login in a current browser, is the connection protected against harvest-now, decrypt-later attacks, in which traffic recorded today is decrypted once a large quantum computer exists? Every major browser already offers the hybrid post-quantum key exchange that provides this protection, so the answer depends only on whether the bank's server accepts it. Section 9 explains how it works.

Fifty-nine of the 100 bank homepages and 48 of the 97 online-banking logins selected X25519MLKEM768 when it was offered. In total, 105 of 194 hosts (54%) are protected against harvest-now, decrypt-later attacks for customers with a current browser, and 61 of the 100 banks offer that protection on at least one of the two hosts we tested.

The four largest banks in the world, all Chinese, are classical only on both hosts, as are Crédit Agricole (no. 9) and Postal Savings Bank of China (no. 10). JPMorgan Chase, Bank of America, BNP Paribas and HSBC, the rest of the top 10, negotiate hybrid ML-KEM on both their homepage and their online-banking login.

2. Homepage vs. Online-Banking Login

For a bank customer, the online-banking login matters more than the homepage: it is where passwords, account data and payment instructions travel. Yet the login is the less protected of the two. Among the 97 banks with both hosts, 46 protect both, 38 protect neither, 11 protect only the homepage and just 2 (Morgan Stanley and Intesa Sanpaolo) protect only the login.

The "homepage only" group includes Citigroup, Sumitomo Mitsui Financial Group, Société Générale, UBS, La Banque Postale, CaixaBank, OCBC, Erste Group, ABN AMRO, Nationwide and Nomura. The pattern is consistent: corporate websites tend to sit on a modern CDN, while the transactional banking platforms behind the login were often deployed separately, sometimes years earlier, on separate infrastructure. Several of those login hosts, including Citi's US retail site, SMBC Direct and UBS e-banking, accept only TLS 1.2.

3. Regional and Size Differences

The regional picture is stark. All 12 US banks, all 8 Japanese, all 6 Canadian, all 6 British and all 4 Brazilian banks offer post-quantum TLS on at least one host, and most on both. At the other end, none of the 21 mainland Chinese banks negotiated hybrid ML-KEM on any of their 42 hosts, and 27 of those hosts accept only TLS 1.2. The five South Korean financial groups, the two Russian banks and the UAE's First Abu Dhabi Bank are likewise classical only.

Europe is divided. Spain, Italy, the Netherlands, Switzerland, Austria, Belgium, Denmark and Finland have PQC at every bank in the sample, and France at four of six. Germany has none: Deutsche Bank, DZ Bank, Commerzbank and LBBW all negotiate classical key exchange only. For German readers this is notable, as the BSI's technical guideline TR-02102-1 recommends deploying post-quantum key establishment in hybrid mode.^[3]

Size, by contrast, hardly matters. Each quarter of the ranking has between 14 and 16 banks with PQC on at least one host. The largest banks are not ahead because the very top of the list is dominated by Chinese state-owned lenders, and the smaller banks are not behind because many of them buy the same CDN services as their larger peers.

4. What Drives Adoption: The Edge Network

The clearest explanation for who has PQC is where the bank's TLS connection ends. Of 110 hosts served by the large Western CDN and cloud edge networks in our sample (Akamai, Cloudflare, AWS, Imperva, Microsoft Azure and Azion), 101 negotiated hybrid ML-KEM (92%). Of 68 hosts served from the banks' own address space or a domestic telecom provider, only 4 did (6%): the homepages and logins of Danske Bank and Raiffeisen Switzerland, which run hybrid key exchange on their own infrastructure. The 9 hosts on Wangsu/CDNetworks and 2 on Tencent EdgeOne, used by Chinese banks, and the 5 German and Swedish hosts on Google Cloud load balancers were all classical only.

Akamai alone fronts 73 of the 194 hosts, and 68 of them negotiated PQC. That is no coincidence: Akamai made hybrid X25519MLKEM768 available as an opt-in in 2025 and switched it on by default for client-to-edge connections on its Enhanced TLS network in August 2026, with an opt-out.^[2][4] Cloudflare has negotiated the hybrid with supporting browsers by default for longer.^[5] In other words, for many banks in our sample post-quantum TLS arrived as a side-effect of their CDN contract, not of a migration programme. Four of the five Akamai-fronted hosts without PQC accept only TLS 1.2 (Citi's retail site, Morgan Stanley's homepage, SMBC Direct and OCBC's internet banking); the fifth, ABN AMRO's Dutch retail site, negotiates TLS 1.3 with classical X25519.

The TLS 1.2 blocker

Fifty of our 194 hosts accept only TLS 1.2, an older version of the protocol that cannot carry a post-quantum key exchange at all, whatever software or CDN sits behind it. Of these, 27 belong to Chinese banks, including the online-banking logins of all four of China's largest banks (ICBC, Agricultural Bank of China, China Construction Bank and Bank of China) and the homepages of China Construction Bank and Bank of China. For these banks, enabling TLS 1.3 is the necessary first step before post-quantum migration can even begin; Section 9 explains the technical reason.

The other 39 classical hosts already speak TLS 1.3 but chose X25519 (37) or P-256 (2) when hybrid groups were offered. For them, post-quantum key exchange is a software update or a configuration switch away.

5. The Authentication Gap: Certificates Are Still Classical

Key exchange is only half of TLS. The certificates that prove a site's identity are still entirely classical: of the 176 hosts on which we could read the certificate, 144 use RSA-2048 keys (82%), 20 ECDSA P-256 and 12 RSA-4096. No host presented an ML-DSA or SLH-DSA certificate, and none was expected. Post-quantum certificates are not yet issued for the public web, and the industry's preferred route for HTTPS, Merkle Tree Certificates, is still in its experimental phase, as we describe in our browser analysis.

This gap is less urgent than key exchange: a forged signature only helps an attacker at the time of the connection, so certificates must be post-quantum before a cryptographically relevant quantum computer exists, not before today's traffic is recorded. But banks' certificate estates, HSMs and trust chains take years to change, so planning has to start now.

6. The Regulatory Clock

Supervisors have stopped treating post-quantum migration as a research topic. The G7 Cyber Expert Group published a coordinated roadmap for the financial sector in January 2026. It recommends 2035 as the overall target for migration and suggests addressing the most critical systems in 2030–32. It also points out that data intercepted today may already be at risk.^[6] In the EU, the Coordinated Implementation Roadmap adopted in June 2025 asks Member States to start transitioning by the end of 2026 and to move high-risk use cases, explicitly including finance, to PQC by the end of 2030.^[7] NIST's draft transition plan, IR 8547, proposes to deprecate RSA and elliptic-curve key establishment and signatures after 2030 and to disallow them after 2035.^[8] Europol's Quantum Safe Financial Forum has urged banks to treat the transition as a priority now, citing store-now-decrypt-later attacks.^[9] In Germany, the BSI's TR-02102-1 recommends hybrid key establishment with ML-KEM, as our BSI compliance guide explains.^[3]

Measured against those deadlines, hybrid TLS on public websites is the easy part: it is standardized, supported by every major browser and often only a configuration change away. That 39 of the 100 largest banks do not offer it on either their homepage or their login, with less than five years to the EU's 2030 target for high-risk use cases and the G7's suggested window for critical systems, shows how uneven the starting line is. For many banks that already have PQC, it was switched on by their CDN; their own transactional platforms, internal links and certificates remain to be migrated.

7. Recommendations for Banks

• Turn it on where it is a switch. If your edge provider already supports X25519MLKEM768, enable it for every customer-facing hostname, logins and APIs included, and make sure no legacy opt-out is still in place.^[2][5]
• Retire TLS 1.2-only endpoints. TLS 1.2 cannot carry a post-quantum key exchange at all. Moving to TLS 1.3 is the prerequisite for PQC and closes older weaknesses at the same time; our TLS vulnerability analysis lists them.^[10]
• Treat the login as the priority host. Credentials, account data and payment instructions travel over the online-banking host, not the marketing homepage. It deserves the protection first.
• Check every hop. Confirm that the CDN-to-origin and internal service connections are also hybrid, since browser-facing PQC says nothing about them.
• Inventory certificates now. Post-quantum certificates are not yet available on the public web, but certificate automation, HSMs and trust stores take years to change. Plan the signature migration separately from key exchange; our article on key exchange vs. signatures covers the two timelines.
• Verify from outside, continuously. Re-scan after every configuration change, from more than one region.

8. Bottom Line

Much of today's progress came with the infrastructure: two thirds of the PQC hosts we found sit on Akamai, which enabled hybrid key exchange by default only in August 2026. The next steps are less automatic: moving legacy TLS 1.2 endpoints to TLS 1.3, bringing online-banking platforms up to the level of the corporate homepage, extending hybrid key exchange to CDN-to-origin and internal connections, and preparing certificate infrastructure for ML-DSA. We plan to repeat this scan periodically to track progress.

9. Technical Background: Why Banks, and Why TLS?

This section and the next are for readers who want the technical background to the results above and the details of how the scan was run.

Banks hold exactly the kind of data that an attacker would want to record today and decrypt later: account credentials, payment instructions, identity documents and the details of customers' financial lives. Much of that data stays sensitive for years. This is the harvest-now, decrypt-later threat: traffic captured now is protected only by the key exchange that set up the session, and today's classical key exchanges (ECDHE with X25519 or NIST curves) can be broken by a large enough quantum computer.

TLS is the first and most visible place to fix this. The upgrade is a hybrid key exchange: the TLS 1.3 named group X25519MLKEM768 combines classical X25519 with ML-KEM-768, the module-lattice KEM that NIST standardized in FIPS 203.^[11][12] The connection stays secure as long as either component holds. Every major browser already offers this group by default, as our browser comparison shows, so the deciding factor for a customer's connection is whether the bank's server accepts it.

That makes the server side measurable from the outside. A scan cannot see a bank's internal systems, but it can see what every customer's browser sees: which TLS version and key-exchange group the bank's public servers negotiate. That is the view this report measures, for the homepage and the online-banking login of each of the world's 100 largest banks.

10. Methodology

Sample

The sample is S&P Global Market Intelligence's ranking The world's largest banks by assets, 2026, published 29 April 2026. Most total assets in it are as of 31 December 2025.^[1] The 100 banks hold about US$133 trillion in assets and are headquartered in 24 countries. Mainland China accounts for 21 of them, the United States for 12 and Japan for 8.

For each bank we scanned up to two hostnames:

• Homepage: the group's official public website as linked from its investor and corporate pages, e.g. www.jpmorganchase.com or www.icbc.com.cn.
• Online-banking login: the host that serves the retail customer sign-in. We found it by following the bank's own "Log in" or "Online banking" link from its home-market retail site and recording the final hostname after redirects, e.g. secure.chase.com. For groups with several retail brands we used the main home-market brand. Three banks (DZ Bank, Norinchukin Bank and BNY) operate no retail online banking of their own and were excluded from the login sample. At three banks the login form sits on the homepage host itself; that host was scanned once and counted in both samples.

That gives 194 unique hosts: 100 homepages and 97 online-banking logins. The full list, including every hostname, is in Appendix A.

Scanner and procedure

Every host was scanned with CipherScope, our public post-quantum readiness scanner,^[14] using OpenSSL 3.6 as the TLS probe. The Standard profile opens a normal TLS connection and then a handshake that offers hybrid groups first (X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024) alongside classical fallbacks, exactly as a modern browser would. It records the group the server actually chooses. Hosts with a post-quantum result were then re-checked with the Deep profile (with six exceptions, see below), which samples up to four IPv4 and four IPv6 addresses, tests each hybrid group separately and confirms classical fallback.

Each host receives one of four results:

For 53 hosts CipherScope's TLS stack could not complete a handshake. In nearly all cases the reason was not a network block but an old server configuration: a server limited to TLS 1.2, or one that does not implement the secure renegotiation extension of RFC 5746, which OpenSSL 3 refuses by default.^[13] We resolved these hosts with a supplementary OpenSSL 3.6 handshake that offers the same hybrid groups first but tolerates legacy renegotiation. All 53 completed: 50 negotiated TLS 1.2 and 3 negotiated TLS 1.3 with a classical group. All of them are therefore reported as classical only, and are marked * in the appendix. As a cross-check, we repeated the same independent OpenSSL handshake on a random sample of 12 hosts that CipherScope had classified itself (6 PQC, 6 classical only). All 12 matched. Because of the scanner's daily limit, 100 hosts received the Deep re-check (every PQC-positive login and all PQC-positive homepages except the six lowest-ranked ones, which keep their Standard result). Every Deep re-check confirmed the result on all sampled addresses, so no host fell into the "Partly" category, and after the supplementary handshake none remained undetermined.

We also recorded the leaf certificate's public-key algorithm, and identified the network that terminates each TLS connection. For the latter we looked up the origin autonomous system (ASN) of the host's IPv4 address via Team Cymru's IP-to-ASN service,^[15] using CNAME records where a CDN runs inside third-party address space. The scans ran on 5–6 October 2026 from a single vantage point in Europe.

Additional observations

All 105 PQC hosts chose X25519MLKEM768, the group browsers prefer. The Deep scan also offered each hybrid group on its own: 10 of the 99 PQC hosts it covered additionally accept SecP256r1MLKEM768, the NIST-curve variant,^[12] and none accepted SecP384r1MLKEM1024.

A secondary check of the banks' public mail servers (MX hosts of the homepage domain, via STARTTLS) shows that post-quantum protection has barely reached e-mail: only BBVA's mail servers negotiated hybrid ML-KEM on all tested addresses and Nationwide's on some. Many mail servers could not be assessed from our vantage point, so we do not report a percentage.

Further Reading

For how the hybrid key exchange that protects these connections works, and why it combines a classical and a post-quantum component, read our technical analysis:

Appendix A: Results for All 100 Banks

Ranked by total assets (S&P Global, April 2026).^[1] The group shown is the key-exchange group the server selected when hybrid groups were offered first. Results marked * were resolved with the supplementary OpenSSL handshake described in Section 10. Results reflect our scans on 5–6 October 2026 and may have changed since.

How to Cite This Report

@misc{pqcryptography_top100banks_pqc,
  author       = {{PostQuantumSecurity.org}},
  title        = {Is Your Bank Ready for Quantum Computers? We Checked the World's 100 Largest},
  year         = {2026},
  month        = oct,
  day          = {6},
  url          = {https://www.postquantumsecurity.org/publications/top100banks-pqc-report.html}
}

References

1. Jimenea, A., & Lozano, C. (2026, April 29). The world's largest banks by assets, 2026. S&P Global Market Intelligence. https://www.spglobal.com/market-intelligence/en/news-insights/research/2026/04/the-worlds-largest-banks-by-assets-2026
2. Daffron, T. (2026, August). Future-Proofing the Internet: Akamai Achieves End-to-End PQC. Akamai Blog. https://www.akamai.com/blog/security/2026/aug/future-proofing-internet-akamai-achieves-end-to-end-pqc
3. Federal Office for Information Security (BSI). (2026). Technical Guideline TR-02102-1: Cryptographic Mechanisms: Recommendations and Key Lengths, Version 2026-01. PDF copy
4. Akamai. (2025, September 3). Akamai Enables Post-Quantum Cryptography on the Edge. Akamai Blog. https://www.akamai.com/blog/security/2025/aug/akamai-enables-post-quantum-cryptography-edge
5. Cloudflare. (2026). Post-quantum cryptography (PQC). Cloudflare SSL/TLS documentation. https://developers.cloudflare.com/ssl/post-quantum-cryptography/
6. G7 Cyber Expert Group. (2026, January). Statement on Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector. https://www.gov.uk/government/publications/advancing-a-coordinated-roadmap-for-the-transition-to-post-quantum-cryptography-in-the-financial-sector
7. European Commission & NIS Cooperation Group. (2025, June 23). A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
8. Moody, D., Perlner, R., Regenscheid, A., Robinson, A., & Cooper, D. (2024, November 12). NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards. https://csrc.nist.gov/pubs/ir/8547/ipd
9. Europol. (2025, February 7). Call for action: urgent plan needed to transition to post-quantum cryptography together. https://www.europol.europa.eu/media-press/newsroom/news/call-for-action-urgent-plan-needed-to-transition-to-post-quantum-cryptography-together
10. Rescorla, E. (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF. https://www.rfc-editor.org/rfc/rfc8446
11. National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://csrc.nist.gov/pubs/fips/203/final
12. Kwiatkowski, K., Kampanakis, P., Westerbaan, B., & Stebila, D. Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3. IETF Internet-Draft draft-ietf-tls-ecdhe-mlkem. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
13. Rescorla, E., Ray, M., Dispensa, S., & Oskov, N. (2010). RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension. IETF. https://www.rfc-editor.org/rfc/rfc5746
14. HybridCipher. (2026). CipherScope: Public PQC Readiness Scanner. https://cipherscope.hybridcipher.com/
15. Team Cymru. IP to ASN Mapping Service. https://www.team-cymru.com/ip-asn-mapping