PQC Is Quietly Becoming Part of TLS

PQC Is Quietly Becoming Part of TLS

•3 min read

PQC Is Quietly Becoming Part of TLS

Post-quantum cryptography is no longer just a research topic for standards teams and browser engineers. It is starting to show up in the part that matters most for the public Internet: real TLS handshakes.

The turning point came on August 13, 2024, when NIST finalized FIPS 203 and standardized ML-KEM, the key encapsulation mechanism derived from Kyber. That gave the industry a stable name and a stable target. For TLS, the practical migration path has been hybrid key exchange: keep the proven classical piece, usually X25519, and combine it with ML-KEM-768 so the connection is protected even if long-lived traffic is being collected today for future decryption.

That is why the most important TLS label right now is not a pure post-quantum mode, but a hybrid one like X25519MLKEM768. The IETF TLS working group is still formalizing this path for TLS 1.3, but the direction is already clear. In plain language: the ecosystem has chosen a migration strategy that is conservative enough for production, but meaningful enough to reduce harvest-now-decrypt-later risk.

What makes this shift interesting is that deployment is already happening. Chrome first introduced hybrid Kyber support in 2023, then enabled the newer draft by default for desktop TLS 1.3 and QUIC in Chrome 124 in May 2024. Cloudflare reported in March 2025 that well over a third of the human traffic reaching its network was already protected by TLS 1.3 with hybrid ML-KEM key exchange. OpenSSL then moved the stack forward again with its 3.5 release on April 8, 2025, adding PQC algorithms and improved TLS key establishment controls. That combination matters: browsers, edge networks, and mainstream crypto libraries are no longer waiting on each other.

The shape of the migration is becoming clearer too. Key exchange is moving first. That makes sense: it protects traffic that can be captured now and attacked later. Certificates and signatures will take longer, because they carry more operational baggage, larger objects, more CA and browser coordination, and more performance sensitivity. In other words, TLS is not waiting for the entire post-quantum story to be finished before starting the part that already delivers value.

From the Fortinet side, this matters because post-quantum readiness has to land in products people actually operate, not just in white papers. Fortinet already looks like one of the earlier security vendors adapting this through the portfolio. Even before PQC reached mainstream TLS libraries, FortiOS 7.4 had introduced quantum-safe capabilities such as QKD integration in the network stack. That is the right direction: the migration will not stop at the browser edge. It has to reach firewalls, VPNs, SD-WAN, and inspection paths where teams actually carry sensitive traffic.

PQC in TLS is still a transition, not a finish line. But it is already real, already deployed, and increasingly hard to dismiss as “future work.”

Further Reading