Global PQ Readiness Index — September 2026
Probe date: 2026-09-03 UTC · Previous runs: 2026-05-10 and 2026-04-23 UTC
Method: active TLS 1.3 ClientHello probe for NIST-track hybrid key agreement
(codepoints 0x11EC X25519MLKEM768 and 0x11EB SecP256r1MLKEM768)
Scope: 350 public hosts, 8 sectors, 28 region tags — same list all three runs, unchanged
Published alongside: aggregate counts per sector and per run, plus the probe method in full.
Not in this report: per-host results. Earlier runs of this index did publish host-level data,
and those files are still in this repository — see "Why we are not publishing the host list" below.
In April, banking was the least post-quantum-ready sector we measured. It is now second from the top.
Four and a half months ago we probed 350 public TLS endpoints and found that banking sat at the
bottom of eight sectors. We re-ran it in May, and again this week — identical probe, identical host
list, all three times.
Banking moved from 28% to 94%.
That is not a typo, and it is the largest sector move in the dataset. It is still not the highest
figure in the table: news & media finished at 96.4%. Banking travelled the furthest, not the
highest, and those are two different claims.
The number we trust, and why
The headline comparison people will want is 42.6% → 73.1% across all 350 targets. We are not
going to lead with that number, because the set of hosts that answered changed between runs and
a shifting denominator can manufacture a trend out of nothing.
Instead: 293 of 350 hosts returned a usable answer in both runs. That fixed cohort is the
only honest basis for a delta, so every number below is computed on it.
| Run | Cohort PQ-safe | Banking |
|---|---|---|
| 23 Apr 2026 | 147 / 293 = 50.2% | 14 / 50 = 28.0% |
| 10 May 2026 | 150 / 293 = 51.2% | 15 / 50 = 30.0% |
| 3 Sep 2026 | 252 / 293 = 86.0% | 47 / 50 = 94.0% |
The shape matters more than the endpoints. In the 17 days from April to May, the cohort moved
+1.0 point. In the 116 days from May to September it moved +34.8. This was not a gradual
drift; something changed over the northern summer. We do not know what, and we are not going to
guess in a document like this.
105 hosts moved from classical to post-quantum hybrid. Across all three runs, zero moved the other way.
That zero is the control. A measurement where nothing can move backwards is not measuring
anything; here something could have regressed, and nothing did. The shift is directional, not
noise.
By sector, same-host cohort
| Sector | n | April | September | change |
|---|---|---|---|---|
| Banking | 50 | 28.0% | 94.0% | +66.0 |
| Government | 36 | 36.1% | 86.1% | +50.0 |
| E-commerce | 33 | 30.3% | 78.8% | +48.5 |
| Critical infrastructure | 30 | 43.3% | 80.0% | +36.7 |
| News & media | 28 | 60.7% | 96.4% | +35.7 |
| CDN & cloud | 34 | 64.7% | 85.3% | +20.6 |
| Control group (known PQ-shipping) | 23 | 69.6% | 87.0% | +17.4 |
| Big-tech SaaS | 59 | 71.2% | 81.4% | +10.2 |
The sectors everyone assumes are slowest — banking, government — moved fastest. The sector
everyone assumes is fastest — big-tech SaaS — moved least, because it had the least room left
to move.
We are not naming hosts. Sector, region, denominator and delta are the whole product here.
A named list would be a different thing with a different purpose, and this is not that.
Why we are not publishing the host list
Earlier runs of this index named individual hosts. This one does not, and neither will the ones
after it. Those earlier files are still in this repository. We are not going to quietly delete
them and imply the policy was always this one — and deleting them would not unpublish them anyway.
A sector percentage with a stated denominator answers the question people actually have — is my
industry moving? A named list answers a different question, one that turns a measurement into a
scoreboard about specific organisations who did not ask to be on it. We would rather publish
something narrower and be able to keep publishing it.
The method is stated in full and the aggregate counts are attached. Anyone who wants to check us
can assemble their own list and run the same probe — that is a better reproducibility guarantee
than taking ours on trust.
Three things this does not prove
- We measured a front door, not an estate. One public TLS endpoint per host. A bank whose www hostname negotiates ML-KEM may still run classical crypto everywhere that matters — internal PKI, batch file transfer, VPN, database links, HSM integrations. Front-door PQ is the cheapest possible indicator, and cheap indicators move first.
- We cannot separate deliberate migration from vendor default. A large share of this shift is almost certainly CDN and load-balancer defaults rolling forward underneath organisations that made no decision at all. That is still real protection against harvest-now-decrypt-later, but it is not evidence of a migration programme, and it can be rolled back by a config change nobody announces.
- 57 hosts are missing from the cohort. 46 errored in September, 55 in April. The most common failure is a server alert rejecting our ClientHello outright. We count those as not measured, never as classical. If a systematic bias hides in there, it is the weakest part of this dataset, and it is the first place we would look for a correction.
Corrections wanted
The method and the per-sector aggregate counts for all three runs are published here. If you can
show that a sector figure is wrong, that the cohort method hides an artefact, or that the 0x11EB
codepoint should be counted differently, tell us and we will re-run and publish the correction with
the same prominence as the original claim.
We will run this again in December on the same list. The delta is the point; a single snapshot of
this is close to worthless.
Top comments (0)