Summary
On 1 September 2026 we ran a single TLS handshake against 40 public web front doors and read both sides of it: the negotiated key exchange, and the certificate chain the server presents.
- 31 of 40 negotiated hybrid post-quantum key exchange (
X25519MLKEM768). - 0 of 40 presented a post-quantum signature — at any position in the chain.
The key-exchange result is not our contribution; it confirms what CDN operators have been reporting publicly since mid-2026. We include it only as the comparison that gives the second number its meaning. The two halves of the same handshake are on opposite sides of a migration, and we think the reason is structural rather than a difference in effort.
Method, and how to reproduce it
One TLS handshake per host, from one vantage point, using openssl s_client -showcerts. For each
certificate the server presents we read the signature algorithm, the public key algorithm and size,
and notAfter. The negotiated group is read from the client's own report of the handshake. Nothing
is authenticated, nothing is intrusive, and every host is a public front door — the same class of
observation a public TLS test site performs. A single host takes one command; the contribution of a
tool here is only doing it 40 times and totalling the result.
Hosts were drawn from three groups, chosen before measurement:
| group | hosts | hybrid PQ KEX | PQ signature | median chain horizon |
|---|---|---|---|---|
| Internet infrastructure & platforms | 12 | 10 | 0 | 1 685 days |
| Banks (US / UK / EU) | 16 | 13 | 0 | 1 535 days |
| Control: organisations that deliberately lead on cryptography | 12 | 8 | 0 | 2 193 days |
| total | 40 | 31 | 0 | 1 685 days |
Medians are the mean of the two central values. Leaf signature algorithms across all 40: 28 RSA-based, 12 ECDSA. No other algorithm appeared.
The unit is a host, not an organisation. Forty hosts are operated by thirty-seven distinct organisations: three organisations contribute two hosts each, and one of those three appears in both the infrastructure group and the control group. The control group is therefore twelve hosts operated by ten organisations. We report hosts because a host is what a handshake is made to, but no count here should be read as a count of institutions.
The control group is the actual finding
The third group was selected to be as unfavourable to a “they are simply behind” reading as we could make it. It consists of organisations whose public identity is built on getting cryptography right — privacy-focused messaging and mail providers, VPN and network-identity operators, an anonymity network, a digital-rights organisation, and three projects that maintain cryptographic libraries that implementers, including us, use to perform this very measurement.
That group returned 0 of its 12 hosts, the same as everyone else, while 8 of the 12 had already moved their key exchange.
We read this as evidence that the absence of post-quantum authentication at the web front door is not a question of awareness, capability, or will. The organisations most motivated and most technically equipped to deploy it have not deployed it either — because at the time of measurement there is no path to: no publicly trusted CA issues certificates with post-quantum signatures, so no subscriber can obtain one regardless of how much they want it.
The mechanism we would propose for the asymmetry, and would like the workshop to test against other data:
- Key exchange fails retroactively. Traffic recorded today is decryptable later, so the pressure exists now. It is also deployable unilaterally: two endpoints agree and it is done.
- Signatures fail only prospectively, and deployment requires an entire ecosystem to move together: a CA that can issue, a root program that will trust, verifiers in browsers and operating systems, and hardware that can sign.
If that framing is right, then the number above is not measuring how seriously these organisations take post-quantum risk. It is measuring which half of the handshake can be changed without anyone's permission.
A second measurement: the horizon that matters is not the one operators control
A common and reasonable response is that certificates are short-lived, so authentication can be migrated whenever the ecosystem is ready.
The leaf certificates we observed do have short remaining validity: 20 to 190 days. But within the same presented chain, the certificates above them ran to 903 to 4 157 days — a median of roughly 4.6 years, and at the far end a chain member valid into January 2038.
The short-lived object is the one the operator issues and can replace. The object that sets how long a classical signature must remain verifiable sits above it, and the operator neither issues nor withdraws it. We think discussions of migration timelines would benefit from separating those two horizons explicitly, because the shorter one is the one usually quoted.
Limitations
These belong in the body, not in a footnote, because they bound every number above.
- n = 40, one point in time (1 September 2026), one vantage point. We make no claim about any industry, population, or trend. Forty hosts is a sample and not a survey; it is enough to show that a contrast exists and not enough to size it.
- The unit is a host, not an organisation, and the two do not coincide: 40 hosts, 37 organisations, with one organisation present in two different groups. The control group is twelve hosts and ten organisations. Nothing in the result turns on this — the signature count is zero under either unit — but the group sizes should be read as host counts.
- 9 of 40 handshakes did not report a negotiated group in our client output. Those are counted as not observed, not as declining post-quantum key exchange. The correct reading of the first number is “31 confirmed”, never “9 refused”.
- The chain horizon is a lower bound. Root certificates are usually not transmitted by the server, so the horizons above are computed only over what was presented. The true figures are longer, not shorter.
- This is the front door only. It says nothing about internal PKI, code signing, machine identity, or the certificates inside an estate — which is where the difficult part of any authentication migration lives, and which this method cannot see.
- Content delivery networks may return different chains in different regions; a measurement from another vantage point may differ.
What we would like to discuss
The workshop's call asks for constraints as well as measurements, and our measurement mostly produced a constraint. If the front-door signature migration is blocked on issuance rather than on adoption, then the questions we would find most useful are:
- What is the actual gating dependency in the chain (issuance, root program inclusion, verifier deployment, signing hardware), and which of them can proceed in parallel?
- Certificate sizes change materially with post-quantum signatures. What does that do to handshake behaviour on constrained and lossy paths, and is anyone measuring it in deployment rather than in a laboratory?
- Is there value in a periodically repeated, openly published measurement of both halves of the handshake, so that the community can see the authentication side begin to move rather than inferring it? We are willing to keep running and publishing ours, and would rather it were one of several independent measurements than the only one.
We would finally note something that applies to this paper as much as to anything else: a published number about a moving world goes stale silently, and the key-exchange side has moved fast enough this year that a figure a few months old can already read differently. That is an argument for repeating measurements, for dating every figure, and for publishing the host list and the raw handshake output alongside the number rather than the number alone.
Data
Because the paragraph above would otherwise be an assertion rather than a practice, the sample and the raw output are published with the paper, not on request:
- the 40 hosts, by group — plain text, one host per line
- the raw per-host result — negotiated group, every certificate
in the presented chain with its signature algorithm, key algorithm and size, and
notAfter