In this sample, Gulf and Asian insurers are ahead of European ones
Of the insurers we measured in the Gulf states, South-East Asia and Hong Kong, 63% (47 of 75) already negotiate hybrid post-quantum key exchange on their public website. In Europe the figure is 38% (24 of 63), and in Western Europe 29% (7 of 24).
Most of the European websites that said no are not old: 32 of the 39 support TLS 1.3 and still chose classical key exchange although the hybrid group was on offer. Turning it on is usually one setting on the server or load balancer that ends the TLS connection. We have not tested why European insurers are behind; we only measured the result.
Hybrid on the website is the easy part. It can arrive with a CDN or cloud load balancer without the insurer changing anything. It says nothing about customer portals, policy and claims systems, broker and reinsurer links or mobile apps, which is where policyholder and health data with a long secrecy requirement actually travels.
Results by region
Sorted by share. "Classical" means the server supports TLS 1.3 but chose a classical group although the hybrid group was on offer. Regions rather than countries, because in several countries we measured only one or two insurers and a country row would name them.
| Region | Clear result | Hybrid PQ | Classical, TLS 1.3 | TLS 1.2 or older | Share hybrid |
|---|---|---|---|---|---|
| Hong Kong (small sample) | 6 | 5 | 0 | 1 | 83% |
| South-East Asia | 37 | 26 | 7 | 4 | 70% |
| Gulf states | 32 | 16 | 9 | 7 | 50% |
| Southern Europe | 10 | 5 | 5 | 0 | 50% |
| Nordics (small sample) | 8 | 4 | 4 | 0 | 50% |
| Central & Eastern Europe | 21 | 8 | 8 | 5 | 38% |
| Western Europe | 24 | 7 | 15 | 2 | 29% |
| All 7 regions | 138 | 71 | 48 | 19 | 51% |
Not counted: 7 websites returned no readable key-exchange group or failed to connect in one of the two runs. No website gave two different readable answers on the same day in this sample. In our bank measurements the same website sometimes alternated between hybrid and classical within minutes (see Vol.2), so a single scan is a sample, not a status.
Method
Each website was contacted on port 443 with a TLS 1.3 ClientHello that offers the hybrid group
X25519MLKEM768 (IANA 0x11EC) alongside classical groups, twice, about 25 minutes apart. The server chooses; we recorded what it chose.
A result counts as clear only when both runs agree.
- Hybrid PQ: the server selected
X25519MLKEM768in both runs. - Classical, TLS 1.3: TLS 1.3 but a classical group in both runs, usually
X25519, sometimes another elliptic curve or finite-field Diffie-Hellman. - TLS 1.2 or older: the server refused TLS 1.3 when offered. TLS 1.2 cannot carry hybrid key exchange at all.
Reproduce it
Our probe is stock OpenSSL 3.5, whose default ClientHello already offers the hybrid group first. The same command shows the result for one host:
echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 | grep -E 'Negotiated TLS1.3 group|^ *Protocol'Every run starts with a control: if cloudflare.com does not come back as X25519MLKEM768, the batch stops.
Source: 290 handshake records (two per website) in our raw measurement table for 26 October 2026, last written 2026-10-26 06:21 UTC,
SHA-256 4ea852e34bd13aef3a015a9cf4072fb6b06c1cdea196ca61d0cb73adec90a9ba. Every number on this page is computed from that table by script; none is typed by hand.
How the sample was chosen
European insurers were taken from Wikidata (entities that are an insurance company, with an official website, not dissolved). Gulf and Asian insurers were taken from the regulators' registers of licensed insurers (for example the Central Bank of the UAE, the Saudi Insurance Authority, the Monetary Authority of Singapore and Bank Negara Malaysia). An insurer is in the sample if it publishes a general contact address and we measured its website. That is not a random sample and does not represent a whole national market or the insurance industry; treat each row as a description of the insurers we measured, not of a national market.
No insurer is named in this report. Insurers in the sample with a published contact address have received, or will receive in the coming days, a short individual note from us with their own result.
The full list of 145 websites and their results is kept unchanged; its SHA-256 is
09d49fe3434cc003f29b735e8b6265eccd93bde1d744a2fa23e5670fb9ca1928, so a later correction can be checked against what we measured here. Every figure on this page can be recomputed from
the published rows (one per insurer: region, result, date, number of runs; country and hostname removed).
Limitations, stated, not buried
One front door per insurer. A public website is not an estate. An insurer can serve classical key exchange on its marketing site and hybrid everywhere that carries real data, or the reverse. For EU insurers, the DORA rules on ICT risk ask for a documented policy on encryption; a front-door measurement is a starting point for that, not a substitute.
One vantage point. We measured from Hanoi, Vietnam. A content delivery network can answer differently in another region.
The sample is small and uneven. 145 insurers, from 6 in Hong Kong to 32 in the Gulf states. Rows marked "small sample" describe a handful of companies.
This report is vendor-authored. We sell cryptographic inventories that produce numbers like these. That is why the method and the command are above: so the number can be argued with rather than believed.
If you think we are wrong
Run the command on your own company's website. If the answer differs from ours, write to us and we will publish the correction next to this page, as we did for Vol.1.