What Readiness Claims Can Withstand Scrutiny?

A claim such as “the server supports PQC” sounds precise, but it can describe several different realities. The subject here is the diagnosis of post-quantum readiness claims: separating capability, configuration, negotiated behavior, authenticated trust, visibility, and controlled retirement. By following the evidence from an advertised feature to a real protected path, you can identify what is proven, what remains provisional, and when migration, deeper testing, policy enforcement, or a compensating control is the honest next action.

Start with the level of the claim

The first diagnostic question is not whether a component has a PQC option. It is what the claim is supposed to establish. An installed cryptographic library demonstrates capability. A server configuration demonstrates intended behavior. A handshake observation demonstrates what one client and server selected under particular conditions. A certificate and trust result demonstrates an authentication path. A production measurement demonstrates something about actual use. None of these observations, alone, proves the next one.

This distinction follows directly from how a security protocol operates. The client advertises supported versions, suites, and key-establishment groups. The server selects a mutually acceptable option according to its own capabilities and policy. The certificate then has to validate through a trust path that the client accepts. A provider, operating system, proxy, or hardware module may perform the operations. A policy may permit a hybrid option for new sessions while allowing a classical mechanism only to recover existing data. “Ready” is therefore a statement about a scope and a path, not a property that can be copied from one layer to every other layer.

The measurement study provides a bounded case. It reports an active analysis of 32,011 domains assembled from a large popularity list and a targeted banking list. Its browser, OpenSSL, cURL, packet, and certificate observations are useful because they examine deployed behavior rather than only documentation. But the paper also states that the extracted TLS parameters are negotiated values. They depend on client and server capabilities, browser and operating-system behavior, cryptographic libraries, and policies. The result is evidence of what the tested path did, not a complete description of every capability held by every service in the sample.

The same banking domain illustrates the difference. On one device, the study observed QUIC with TLS 1.3, X25519, and AES-256-GCM. On another, it observed TLS 1.2 with ECDHE-RSA and AES-128-GCM. The observation does not show that one device was universally secure and the other universally unsafe, nor does it prove that every difference between clients has the same cause. It does show that server-side support does not determine the path in isolation. A service owner who tests only the first device can miss a compatibility population that still reaches the same service through classical public-key cryptography.

The second diagnostic question is whether the observed key exchange is the whole security claim. The study reports that 49.30% of its sampled domains negotiated the hybrid X25519MLKEM768 group and 50.70% remained on classical or otherwise quantum-vulnerable groups. That is meaningful evidence of partial transition.