A large-scale Internet measurement study offers a useful warning for post-quantum programs: support for a hybrid key exchange does not mean that an entire connection, application, or organization is quantum-ready.
The preprint “Measurement Study of Post-Quantum Readiness of Internet: 2026”, submitted June 15, examined negotiated TLS parameters across 32,011 domains. The authors report that 49.3% of the measured domains supported a hybrid post-quantum key-exchange mechanism, while 50.7% continued to use classical key exchange. They observed no hybrid post-quantum certificates in the dataset.
This source is more than 30 days old and, as an arXiv preprint, should not be treated as peer-reviewed consensus. Its measurements are nevertheless useful because they illustrate the difference between one post-quantum mechanism and end-to-end cryptographic readiness.
A TLS connection has more than one cryptographic job
TLS uses cryptography for several purposes. Key establishment allows participants to derive secrets for protecting a session. Authentication helps a client determine that it is communicating with the intended server. Symmetric encryption protects application data after the handshake.
These functions can migrate on different schedules.
A server may support a hybrid mechanism combining a classical exchange such as X25519 with ML-KEM while still presenting a certificate signed with a classical algorithm. That can improve protection for session-key establishment without making the authentication layer resistant to a future cryptographically relevant quantum computer.
The study’s reported contrast—substantial hybrid key-exchange support but no observed hybrid PQC certificates—shows why “PQC enabled” is too imprecise for inventory or governance.
Teams need to know which function is using which mechanism.
Support is not the same as negotiation
The study also describes different client devices negotiating different protocols with the same service. Client software, operating systems, network paths, and compatibility behavior can influence the observed result.
This creates another important distinction: a server may support a mechanism, a policy may prefer it, a particular client may be capable of it, and a real connection may negotiate something else.
An inventory built only from configuration files or vendor claims may record capability without observing use. A network observation may capture actual negotiation but see only the clients and paths present during the observation period.
Both forms of evidence are valuable, but they answer different questions. A canonical inventory should retain their provenance instead of flattening them into one status field.
TLS 1.3 is an enabling foundation, not a PQC certificate
The authors report that 15.7% of measured domains still relied on TLS 1.2, including systems in critical sectors. TLS 1.3 removes several older mechanisms and provides a more suitable structure for hybrid key establishment.
Moving to TLS 1.3 is generally important modernization work. It should not, however, be described as equivalent to deploying post-quantum cryptography.
A TLS 1.3 connection can still use classical elliptic-curve key exchange and classical certificate signatures. Conversely, a hybrid key exchange may be available only for particular clients or through a content-delivery provider.
Useful status language should therefore be specific: TLS 1.3 supported or observed; hybrid ML-KEM key exchange supported or observed; classical certificate authentication observed; post-quantum certificate testing in progress; or end-to-end status unknown.
This vocabulary is less convenient than a single readiness badge, but it produces decisions that can withstand scrutiny.
Internet measurements have limits
The reported percentages should not be generalized automatically to every enterprise environment.
The dataset, sector classification, scanning locations, client capabilities, observation period, CDN behavior, and measurement methodology all influence results. Internet-facing TLS also represents only one portion of an organization’s cryptographic estate.
Internal services, VPNs, machine identities, code-signing systems, firmware validation, cloud control planes, data-at-rest encryption, messaging systems, and operational technology may follow different migration paths.
The study is best used as evidence of an uneven transition—not as a universal benchmark against which every organization should score itself.
What organizations should measure
A practical readiness program should break down the cryptographic functions supporting each important service.
For TLS, record supported and observed protocol versions, key-establishment mechanisms, certificate algorithms, trust-chain dependencies, client and server versions, termination points such as proxies and CDNs, the source and time of each observation, and business ownership and data-sensitivity context.
Then determine whether fallback behavior can expose traffic to a mechanism the organization intended to retire. Test representative clients and network paths rather than assuming the newest browser represents every connection.
The objective is not a one-time percentage. It is a continuously updated account of what was observed, what remains classical, what can change, and who owns the next action.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record supporting discovery, canonical inventory, evaluation, action, and proof.
Vista can reconcile evidence from connected discovery channels into durable records, evaluate cryptographic and PQC state, help teams organize remediation work, and generate scoped CBOM evidence. This supports more precise distinctions between protocols, algorithms, certificates, assets, and observations.
Vista does not claim that one observation proves complete coverage. It is not a vulnerability scanner, does not generate PQC keys, and does not perform every migration. A discovery gap remains a gap. Teams can evaluate the source-available Core edition through the Vista deployment paths.
The study’s central operational lesson is simple: migration happens by cryptographic function and by connection, not by marketing label. Hybrid key exchange is meaningful progress, but it is not the end of the inventory.
Sources
- Measurement Study of Post-Quantum Readiness of Internet: 2026, Vanishka Mohan Dubey and Gaurav Varshney, June 15, 2026.
- Post-quantum cryptography, National Institute of Standards and Technology.
- RFC 8446: The Transport Layer Security Protocol Version 1.3, Internet Engineering Task Force, August 2018.