One hybrid approach leads the way.
Nearly half of the stable panel chose a hybrid key exchange by March 2026. Every post-quantum selection under the study’s client used the same construction.
Chosen in a connection, or supported on request?
These are different questions. Explore the three hybrid approaches below.
n = 684,494 in every round. “Chosen” shows the key-exchange method selected against the study’s default client settings. “Supported” shows whether a method worked when it was the only option offered. An endpoint can support more than one method. Paper, Table 2 and §6.1
What is X25519MLKEM768?
X25519MLKEM768 combines conventional and post-quantum methods to establish a shared secret for a secure connection. This hybrid design retains conventional protection while adding resistance to quantum attacks. In our measurements, it was the only hybrid method selected under the study’s default client settings.
Authentication has not followed.
No post-quantum signature algorithms successfully negotiated in the 684,494-domain stable panel. Changing website authentication also involves certificates, certificate authorities, and browser validation. These dependencies help explain why the two transitions may move at different speeds.
No meaningful increase in connection setup time.
Across matched measurements, both the hybrid and conventional key exchange had a median handshake time of 32 milliseconds. Normal network variation can be larger than the additional cryptographic work.
This comparison concerns key exchange. Post-quantum authentication latency was not measured.
X25519 median
X25519MLKEM768 median
Median paired difference: 0 ms
Middle 50% of differences: −5 to +5 ms
328,290 domains that successfully negotiated both configurations. Handshake time covers TCP connection start to TLS handshake completion. Paper, §6.4.1
Who is behind the rollout?
See why the infrastructure serving a website matters.