Migrating TLS and network encryption to post-quantum
TLS is where most estates start, because externally facing key exchange is the harvest-now-decrypt-later front line. How hybrid TLS works, how to deploy it, and what to watch for.
Hybrid TLS is the highest-leverage first move
Externally facing TLS key exchange is harvestable today, so it usually migrates first. The mainstream approach is a hybrid named group (X25519MLKEM768) that combines classical X25519 with ML-KEM-768 — the session key is secure if either component holds. It is already shipping in major browsers and libraries and interoperates with classical clients, so you can deploy it ahead of a full estate migration.
TLS protects the majority of data in motion, and its key exchange is exactly what harvest-now-decrypt-later targets: record the handshake and ciphertext now, recover the session key once a quantum computer can break the classical exchange. Moving TLS key establishment to post-quantum is therefore the single change that retires the most present-tense confidentiality risk.
How hybrid key exchange works in TLS 1.3
TLS 1.3 negotiates a "named group" for key exchange. Hybrid PQC introduces groups that carry two key shares at once — a classical elliptic-curve share and a post-quantum KEM share. Both sides run both exchanges and combine the two shared secrets into the session key. An attacker must break both to recover it, so the handshake is secure as long as either component is. The dominant group today is X25519MLKEM768, pairing X25519 with ML-KEM-768 (FIPS 203).
Because hybrid groups are just additional named groups, negotiation degrades gracefully: a hybrid-capable server offered a classical-only client simply falls back to a classical group. That backward compatibility is what makes early deployment safe — you protect the clients that support PQC without breaking the ones that do not.
Deploying it
- **Start at the edge.** Terminate hybrid TLS at externally facing load balancers, CDNs, and reverse proxies first — that is where harvestable traffic concentrates.
- **Confirm library support.** Ensure both the server stack and the clients you care about support the hybrid group; support is now broad in current browsers and TLS libraries but not universal.
- **Watch the handshake size.** ML-KEM key shares are larger than classical ones, which can push the ClientHello across a single packet — see the pitfall below.
- **Keep classical fallback on** during transition so non-PQC clients still connect.
- **Measure latency** under the hybrid group before and after; the added CPU and bytes are modest but should be verified against your budget.
Larger ClientHello can hit middlebox and MTU issues
A post-quantum key share makes the TLS ClientHello substantially larger, sometimes spanning multiple packets. Some older middleboxes, load balancers, and buggy TLS stacks mishandle a ClientHello that does not fit in a single packet, causing intermittent handshake failures. Test through your real network path — not just server-to-server on a LAN — and include the middleboxes and firewalls that sit between clients and your edge.
Beyond web TLS
The same reasoning extends to other transport encryption: VPN/IPsec, SSH, and QUIC. Support maturity varies — web TLS is furthest along — so inventory which of your network protocols have PQC or hybrid options today, deploy where they exist, and track the rest as roadmap items awaiting upstream support. Authentication in TLS (the certificate signatures) is a separate migration covered under PKI and certificates; the key-exchange change above protects confidentiality regardless of when certificate signatures move.