The sector with the tightest deadline is the least ready
The ranking came out backwards from what we expected. Internet infrastructure — the group with no regulator telling it to migrate — was the most prepared. Financial institutions, the group facing the firmest published deadlines, were the least.
| Sector | Measured | Hybrid PQC | Classical | Ready |
|---|---|---|---|---|
| Internet infrastructure & platforms CDNs, cloud and hosting providers, developer platforms |
15 | 10 | 5 | 67% |
| Security vendors Companies whose product is protecting other people |
14 | 7 | 7 | 50% |
| Financial institutions Banks and financial groups, global and Southeast Asian |
12 | 4 | 8 | 33% |
| All measured | 41 | 21 | 20 | 51% |
Half the companies selling security to everyone else are still negotiating key exchange that a sufficiently capable quantum computer is expected to break. That is not an accusation — it is a measurement, and it is the same measurement anyone can run against them, or against us.
Method
Each endpoint was contacted once on port 443 with a TLS 1.3 ClientHello that offers a hybrid
post-quantum group (X25519MLKEM768, IANA 0x11EC) alongside the classical groups.
The server chooses. We recorded what it chose.
- Accepted — the server selected the hybrid group. Recorded as
SAFE. - Declined — the server selected classical
ECDHEdespite hybrid being on offer. Recorded asHIGH, withdetection_mode: active_declined. - Not measured — no usable handshake completed within the timeout. Four endpoints. These are excluded from every percentage above rather than counted as failures.
This is what is on the wire, not what a configuration file claims or a questionnaire says. A server that could support hybrid but does not offer it is recorded as declining, because that is what a real client would experience.
Reproduce it
The scanner is our own, and the probe is a single command:
pqc-analyzer scan tls example.comThe same handshake is visible to any TLS client that offers the hybrid group — openssl s_client
with a recent build will show you the negotiated group for a single host. Nothing here needs our tool to verify;
it needs our tool to do 45 of them and total the result.
How the sample was chosen
Fifteen endpoints per sector, selected as publicly recognisable organisations in each category, weighted toward the ones an operator in that sector would name unprompted. No organisation is named in this report, and none was contacted. Every endpoint measured is a public web front door, reachable by anyone with a browser.
Why declining costs something today, not in 2030
The usual answer to post-quantum is that the deadline is 2030 or 2035, so there is time. That answer holds for signatures. It does not hold for key exchange.
Traffic captured today can be stored today and decrypted the day the capability exists. The industry calls this harvest now, decrypt later. It means the exposure window for a session is not the lifetime of the key — it is the lifetime of the secret inside that session. A payment record, a health record, a customer identity, a signing key: those stay sensitive long past 2035.
So for anything with a long secrecy requirement, the question is not “when is the deadline”. It is “how much of what we sent this year will still matter when it becomes readable”.
Limitations — stated, not buried
This is one probe against one front door per organisation. A public web endpoint is not an estate. An organisation can serve classical key exchange on its marketing site and hybrid everywhere that carries real data — or the reverse. This number characterises the front door and nothing else.
Forty-five endpoints is a sample, not a census. Fifteen per sector is enough to show a gap between sectors and not enough to put a confidence interval on it. Treat the ranking as a direction, not a rate.
Declining hybrid is not negligence. Some servers sit behind middleboxes or load balancers that have not shipped support yet; some organisations have deliberately staged their rollout. The measurement says what is negotiated, not why.
This report is vendor-authored. We built the scanner and we sell audits that produce numbers like this one. That is exactly 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 it. One command, one endpoint, no account, no signup. If your result differs from ours we would like to know, and we will say so in the next volume. A measurement that cannot come out badly is not a measurement.
Getting the number for an estate you are responsible for
The table above is a front-door sample of other people's infrastructure. It is not your number, and we will not pretend it is. If it is useful to see the same measurement run properly against domains you are responsible for — every endpoint, certificates and their trust chain, and what actually gets negotiated rather than what is configured — that is what we do.
We only scan what you ask us to scan. You send the domains; nothing is installed, nobody gets access to your network, and no traffic of yours is touched.
Ask for your own number → About ATK
You send a list of domains you are responsible for. We run the same probe across all of them, plus certificate inventory and trust-chain reconstruction, and return a report that says which endpoints negotiate what, which certificates cannot be rotated cleanly, and what to fix first.
Nothing is installed and nobody gets access. Everything measured is what a browser could see. Delivered within two working days.
Fixed price, published: US$390. If the estate is bigger than a front door — internal networks, capture points, a full cryptographic bill of materials — that is a different engagement and we will say so before you pay for the wrong one.
The same discipline, applied to detection instead of cryptography: Detection Reality Index Vol.1 — 24 techniques in, 3 alerts out · Vol.2 — IBM QRadar · Vol.3 — between two audits. Published in full, same terms: open method, stated limits, nothing gated.