Post-Quantum TLS Has A Certificate Gap

A June 15 arXiv paper, Measurement Study of Post-Quantum Readiness of Internet: 2026, gives teams a useful snapshot of where public TLS migration appears to be moving and where it is still thin. The authors analyzed 32,011 active domains and reported that 49.3 percent supported a hybrid post-quantum key exchange such as MLKEM768 with X25519, while 50.7 percent still used classical key exchange. The sharper finding is that the study observed 0 percent adoption of hybrid or post-quantum certificate signature algorithms in its sample.

That split matters. Hybrid key exchange can reduce the risk that captured TLS traffic is decrypted later by a capable quantum computer. It does not, by itself, replace classical certificate signatures, certificate authorities, device trust stores, middleboxes, or application libraries. The practical migration plan has to be two-track: get ready for post-quantum key establishment, then inventory and test the authentication path that tells clients which server they are talking to.

The paper measured TLS and related web security parameters across 32,011 domains, using a mix of browser inspection, OpenSSL probing, and packet-level validation. Its dataset includes a broad public-web sample plus targeted domains from sectors such as banking, government, defense, cloud, education, healthcare, media, social platforms, telecom, and energy. That makes it useful for migration planning, but not a census of every server or every enterprise deployment.

The headline numbers are still worth attention. The authors report that 15.70 percent of domains in the sample still relied on TLS 1.2, 49.3 percent supported hybrid post-quantum key exchange, and 0 percent used hybrid or post-quantum certificate signature algorithms. In plain terms, the confidentiality side of the handshake is starting to change in some public infrastructure, while the authentication side is still largely classical.

TLS has more than one cryptographic job. Key exchange helps a client and server derive shared secrets for an encrypted session. Certificate signatures help the client decide whether the server identity is valid. A hybrid key exchange can combine a classical algorithm such as X25519 with a post-quantum mechanism such as ML-KEM so the session secret is not dependent on one mathematical assumption.

That does not make a classical certificate chain post-quantum. If a certificate uses RSA or ECDSA, its signature security still depends on assumptions that a sufficiently capable quantum computer would threaten. For most teams this is not an emergency patch. It is a dependency map. The key exchange layer can move earlier because browsers, CDNs, and servers can negotiate it without replacing the entire public key infrastructure at once.

Certificates are a shared ecosystem. A server operator cannot simply choose a new signature scheme and assume every client, root store, certificate authority, mobile app, scanner, TLS inspection box, HSM, and embedded device will accept it. Authentication migration has to preserve interoperability while avoiding silent downgrade, broken validation, or certificates that old clients cannot parse.

That is why the 0 percent certificate finding is not surprising. NIST has finalized post-quantum standards for key encapsulation and digital signatures, and its standardization project continues to develop additional signature options. Turning those standards into the public web's certificate layer requires CA/B Forum policy, browser support, operational testing, tooling changes, and answers to performance and size tradeoffs. Signature algorithms tend to have visible operational cost because every handshake and every validation path has to carry them correctly.

Harvest-now, decrypt-later risk is real for data with a long confidentiality lifetime. If an adversary records encrypted traffic today and later gains a quantum computer capable of breaking the classical key agreement, old sessions that lacked quantum-safe protection may become readable. This matters most for medical, legal, government, financial, source-code, diplomatic, research, and private community traffic that remains sensitive for years.

The same framing can be overstated. A quantum computer capable of breaking modern public-key cryptography is not available to ordinary attackers today. Post-quantum TLS also does not solve endpoint compromise, weak session cookies, phishing, exposed backups, or compromised identity providers. The sane response is prioritization, not panic: protect long-lived secrets first, identify systems that terminate high-value TLS, and avoid making brittle cryptographic changes without testing the full client population.

CISA, NSA, and NIST have been consistent on the first operational step: organizations need to know where public-key cryptography exists before they can migrate it. A useful inventory should not stop at public websites. It should cover CDNs, API gateways, service meshes, mobile APIs, webhook endpoints, admin panels, VPNs, SSH, S/MIME, code signing, artifact signing, device certificates, IoT management, database TLS, and internal PKI.

For each item, record the protocol, cryptographic library, certificate algorithm, key exchange behavior, termination point, owner, vendor, supported clients, renewal process, and whether the data protected has a long confidentiality lifetime. That inventory lets teams separate easy public-edge experiments from difficult embedded-client or regulated-system changes. It also prevents a common failure mode: upgrading the visible website while leaving the actual sensitive traffic behind a legacy gateway.

Start with measurement. Confirm what your real clients negotiate, not only what your server can advertise. Then test hybrid key exchange on a controlled edge where rollback is simple and telemetry is strong. Watch handshake failures, client families, bot traffic, middlebox behavior, certificate validation errors, and latency. For many organizations, CDN and browser support will make the public edge the least risky first experiment.

The next lane is procurement and dependency pressure. Ask certificate authorities, CDN providers, cloud load balancers, HSM vendors, mobile SDK owners, API gateway vendors, and endpoint management vendors for post-quantum roadmaps. Add cryptographic agility requirements to new contracts. For internal PKI, build lab chains and test certificate size, validation speed, old-client failure modes, and logging before policy changes reach production.

The paper's dataset and methodology make it useful, but it does not prove that half of the entire Internet is quantum-ready. Public domain samples can be shaped by CDNs, browser experiments, geographic choices, and negotiation behavior. A server that supports a hybrid option may not use it for every client. A domain that appears classical from one probe may behave differently for another network, browser, or TLS stack.

The durable lesson is still clear. Post-quantum readiness is not one switch. Key exchange, certificates, client validation, inventory, monitoring, and rollback all move at different speeds. Security teams should treat the June 2026 measurement as a prompt to start their own evidence collection: scan what they own, classify long-lived data, test hybrid negotiation, and build a certificate migration plan before policy or customer pressure forces a rushed change.