Is India’s BFSI sector ready for the quantum switch? 125 financial institutions tested, 2026

56% of the Indian bank, insurer and market-infrastructure websites BitScore could test on 15 October 2026 negotiated hybrid post-quantum key exchange — 65 of 117.

That is the encouraging half. The uneven half is who: 19 of 25 life insurers, but only 3 of 12 public sector banks. And the deadline that arrives first is not a quantum one. From 15 March 2027 no public TLS certificate may run longer than 100 days, and only 12 of the 122 certificates we read already do.

We measured every institution on the regulators’ own lists — 125 in all: the 49 scheduled commercial banks on RBI’s list, the 62 life, general and health insurers on IRDAI’s, and the 14 exchanges, depositories and clearing corporations on SEBI’s. Six signals, all read from outside.

Where each sector stands

Pick a lens to sort the sectors by it. Each cell gives the share passing and the count behind it — of the institutions the lens could read, so a firewall that refused us is never scored as a failure.

Is post-quantum key exchange switched on?

On the front door, often yes. 65 of 117 main websites completed a TLS 1.3 handshake offering only X25519MLKEM768 — the hybrid of today’s X25519 and ML-KEM, the lattice-based key exchange NIST standardised as FIPS 203 in August 2024, and the hybrid group Chrome has offered by default since version 131.

The split is the story. Insurers lead at 40 of 59; banks trail at 19 of 45, with public sector banks lowest of any sector at 3 of 12. Much of the split is probably plumbing rather than policy: a site behind a content delivery network that has switched hybrid key exchange on inherits it, and a site served from its own load balancer does not. 9 of the 122 hosts we read still negotiate TLS 1.2 at best, which cannot carry it at all.

Regulators have started the clock. RBI set up its Q-SAFE expert committee on 25 May 2026 to evaluate the financial sector’s cryptographic inventory through a Cryptography Bill of Materials, assess crypto agility and recommend a roadmap, reporting within six months of its first meeting. The Department of Science and Technology’s National Quantum Mission task force has set quantum resiliency across critical information infrastructure by 2029 and enterprise-wide post-quantum cryptography by 2033. Day-to-day obligations still sit in RBI’s 2026 cybersecurity Directions; Q-SAFE is the separate quantum track.

Read the number for what it is. A passing website says the edge has moved. It says nothing about core banking, payment switches, APIs, the mobile app’s back end or the certificates themselves, which are still signed with RSA or elliptic-curve keys everywhere — and that inventory is exactly what Q-SAFE has asked for. 8 institutions answered an ordinary handshake but dropped the larger post-quantum one; they are counted as untested, not as failures, though a middlebox that cannot carry the bigger handshake is worth finding before a browser update does.

The 2027 certificate deadline arrives first

Quantum risk is a 2029-to-2033 problem. Certificate lifetimes are a March 2027 problem. Under the CA/Browser Forum’s Ballot SC-081v3, a publicly trusted certificate issued from 15 March 2026 may last 200 days; from 15 March 2027, 100; from 15 March 2029, 47.

Only 12 of 122 certificates are already on 100-day lifetimes or shorter — 11 of them the 90-day certificates that automated issuance produces. 81 sit at today’s 200-day ceiling, and 29 were issued before March 2026 for a year or more. For a team that renews by hand, the 2027 change doubles the work; the 2029 change makes manual renewal impractical. This is crypto agility in its most concrete form, and it is the same muscle a post-quantum migration needs.

CAA — the DNS record that says which certificate authorities may issue for a domain — is published by 24 of 125 institutions, and by just 7 of 62 insurers. Without it, any public authority can be talked into issuing a certificate for your domain. 5 websites served an incomplete certificate chain: browsers usually recover, but API clients and older phones do not.

What the .bank.in move left behind

RBI’s circular of 22 April 2025 (RBI/2025-26/28) told banks to move to the exclusive .bank.in domain by 31 October 2025. They did: all 49 banks on RBI’s list now serve their main website from a .bank.in address. The old domains are a different matter.

Customers spent years learning the old addresses, which is exactly why attackers like them. 7 previous bank domains are still live in DNS with no DMARC record, so mail forged in their name has no policy stopping it. 6 of the 7 publish no mail server, which makes the fix one line: a DMARC record with p=reject on a domain that never sends mail closes it to spoofing for good. One old bank domain still serves a certificate that expired months ago.

Who tells researchers where to report a flaw?

Almost nobody. security.txt, defined by RFC 9116, is a short file at /.well-known/security.txt naming who to contact about a vulnerability and when the file expires. 2 of 94 readable sites published one, both of them insurers; no bank and no market infrastructure institution did. Another 31 refused or timed out on the request, so they are left out of the count rather than marked absent.

It costs an afternoon. Without it, a researcher who finds something has no sanctioned route in, and the first notice an institution gets may be a public post.

Email authentication is the sector’s strong suit

107 of 125 institutions enforce DMARC on their main domain — quarantine or reject, on all mail — and 78 of 125 have gone to p=reject, the strongest setting. Public sector banks are highest at 11 of 12. It shows what the sector does when a control is visible, well understood and audited: it gets done. DNSSEC is the counterpoint — 34 of 49 banks sign their zone, but only 14 of 62 insurers do.

How many pass all five?

None. Scored on five lenses — post-quantum key exchange, CAA, DNSSEC, security.txt and enforced DMARC — 13 institutions pass four and the commonest score is two. Of those 13, all but one are missing only security.txt; across everyone, CAA is the next most often missing.

What to ask for this quarter

Five requests a CISO can take to the board or the IT steering committee, each checkable from outside:

• A cryptographic inventory. It is the first thing Q-SAFE asked of the sector, and the only way to know where RSA and elliptic-curve keys sit beyond the website.
• Automated certificate renewal before March 2027. If any certificate is renewed by a person, that process has under 18 months to change.
• Hybrid key exchange at the edge. Turn on X25519MLKEM768 wherever the CDN or load balancer supports it, and find out why any middlebox drops the larger handshake.
• CAA and DNSSEC on every domain you own. Both are DNS records, both are free, and together they decide who can impersonate you on the web.
• A security.txt, and DMARC p=reject on every old domain. One file and one record per retired domain.

The free domain check reads the same signals on any domain in about a minute; the email spoofing check covers DMARC, SPF and DKIM in depth.

What this does not measure

This is not a security rating and says nothing about breach risk. It reads one handshake and a handful of DNS records on each institution’s main website and domain — nothing behind a login, no internet banking or API hosts, no mobile back end, no internal systems. A pass on every lens would show good public hygiene, not a secure institution, and a fail on one is a fixable setting, not a finding of negligence. Exposure signals — dangling DNS, exposed keys, vulnerable products — were not measured at all.

How it was measured

Who is in it

Each institution is read at the website its regulator lists, or for banks the .bank.in site their old address leads to, following redirects. Four insurers share two group websites, and are read on the shared site.

What each lens tests

How it was measured

On 15 October 2026, from India, one institution at a time and at least 0.75 seconds apart, using Node.js 24 with OpenSSL 3.5 — the first OpenSSL release that can offer ML-KEM at all; on an older one the post-quantum test would report every server as unknown. Per institution: one homepage request to follow redirects, two TLS handshakes on port 443, one request for security.txt, and DNS queries through public DNS-over-HTTPS resolvers.

Not read, and so left out of that lens’s percentage: security.txt for 31 institutions, post-quantum key exchange for 8, and every TLS lens for the 3 with no answer on port 443. Every request carried a user agent naming BitScore and this site.

The data

The sector aggregates behind every figure are open under CC BY 4.0, as JSON and CSV, and listed in BitScore Open Data. Please credit “BitScore India BFSI Readiness Index, October 2026 — BitScore (bitscore.in)”.

Sources

• RBI Press Release 2026-2027/325 — Expert Committee for a Quantum Secure and Adaptive Financial Ecosystem (Q-SAFE), 25 May 2026
• RBI/2025-26/28 — Circular — Migration to ‘.bank.in’ domain, 22 April 2025
• DST, Quantum-Safe Ecosystem in India — National Quantum Mission task force report: CII quantum resiliency by 2029, enterprise-wide PQC by 2033 (page as archived 8 June 2026)
• CA/Browser Forum Ballot SC-081v3 — Schedule of reducing certificate validity: 200 days from 15 March 2026, 100 from 15 March 2027, 47 from 15 March 2029
• NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), 13 August 2024
• Google Security Blog — A new path for Kyber on the web — Chrome 131 offers hybrid ML-KEM (X25519MLKEM768), 13 September 2024
• RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure (security.txt)

Every source was read at its primary location on 15 October 2026. Related: the India Cyber Threat Scorecard, BitScore’s monthly count of threat activity against Indian organisations.