Key agreement moves first because it defends against harvest now, decrypt later and can usually ship as a software update. Authentication, meaning certificates and signatures, only matters at the moment of the connection, and post-quantum signatures are bigger and the certificate ecosystem is slow to change. So the two halves migrate at different speeds.
Two halves of a secure connection
A TLS handshake does two jobs. It agrees on a shared key, and it proves who the server is with a certificate signature. Quantum computers threaten both if they use RSA or elliptic curves, but the urgency differs.
Why key agreement goes first
Recorded traffic can be attacked later, so the key exchange must be quantum-resistant before the data stops being sensitive. That is the harvest now, decrypt later logic.
Cloudflare reported in its end-of-October 2025 post that over 50 percent of human traffic it served used post-quantum key agreement, and described deployment as, in most cases, an uneventful software update.
Why authentication is slower
A forged signature only helps an attacker during a live connection. It cannot be applied to recorded traffic after the fact. Without a working quantum computer, there is nothing to forge with yet.
The ecosystem is also harder to change. The same Cloudflare post says the path to post-quantum authentication is much less clear than for key agreement. It expects the vast majority of operators to keep post-quantum authentication disabled unless performance improves, and says post-quantum certificates are unlikely to be broadly available or trusted by all browsers before 2027.
What this means for your roadmap
- Move key exchange first: TLS, SSH, VPN. Check your libraries and proxies for support.
- Plan authentication as a longer project: certificate authorities, trust stores, device firmware and signing keys.
- Treat long-lived signatures differently. Firmware, code signing roots and documents that must verify for decades need earlier attention than a web certificate valid for months.
- Keep an inventory of where each signature is verified, because you need to know who has to update.
Things to test
- Larger handshakes through load balancers, middleboxes and embedded clients.
- Behavior when a peer does not support the new group.
- Logging that shows which key exchange each connection used.
Teams sometimes ask whether to wait and do both together. Usually that is the wrong call. The key exchange change is small and protects against a risk that exists now, while the authentication change depends on browsers, certificate authorities and device vendors moving. Doing them separately means you collect the benefit of the first without being blocked by the second.
Quick check
If our TLS key exchange is post-quantum, are we done?
No. The certificate signatures, code signing and internal PKI still use classical algorithms. Key exchange is the first and easiest step.
Can recorded traffic be attacked through its signatures later?
A signature checked during the session cannot be forged retroactively to read recorded data. The harvest risk sits with key exchange.
Sources
Last reviewed: 19 October 2026.
