post quantum crypto intermediate · 14 min read · April 29, 2026

Hybrid TLS with Post-Quantum KEMs: How the Internet Is Migrating in 2026

The 2026 production migration to post-quantum cryptography on the public internet uses hybrid key exchange — combining classical X25519 with post-quantum ML-KEM in TLS 1.3. The hybrid approach protects against both quantum break-throughs (ML-KEM saves you) and unforeseen lattice-cryptanalysis breakthroughs (X25519 saves you). This tutorial covers the IETF-standardized hybrid groups, deployment status across browsers and CDNs, and the open performance and policy questions.

Prerequisites: Tutorial 22: ML-KEM and ML-DSA in Practice

The largest live deployment of post-quantum cryptography in 2026 is on the public internet, in the form of hybrid key exchange in TLS 1.3. By early 2026, hybrid TLS was active by default in Chrome, Edge, Firefox, and Safari, supported by Cloudflare, AWS, Google’s edge, Fastly, and most major CDN providers. Between 30 and 50 percent of all TLS handshakes initiated by major browsers in 2026 use a hybrid post-quantum group, depending on the browser and platform.

Hybrid means: the TLS handshake uses both a classical key exchange (X25519 elliptic-curve Diffie-Hellman) and a post-quantum key encapsulation mechanism (ML-KEM, formerly known as Kyber). The session key is derived from both. An attacker who breaks one but not the other cannot read the session.

This is the conservative migration strategy: protect against future quantum attacks via the post-quantum half, while not betting the entire security of the connection on lattice cryptography that has been studied for only ~15 years. Tutorial 22 covered the cryptographic primitives (ML-KEM specifically); this tutorial covers their integration into TLS, the IETF standards, and the operational state of the migration.

The IETF hybrid group standard

The IETF standardized the hybrid key exchange in late 2024. The relevant document, RFC 9598 (and its predecessor draft “draft-kwiatkowski-tls-ecdhe-mlkem”), defines two hybrid groups:

X25519MLKEM768 (group code 0x11EC): X25519 elliptic-curve DH combined with ML-KEM-768.
SecP256r1MLKEM768 (group code 0x11EB): NIST P-256 ECDH combined with ML-KEM-768.

Browsers and servers exchange these as a TLS Named Group, exactly like the older x25519 or secp256r1. Every TLS-1.3-capable endpoint that wants hybrid PQ security advertises and negotiates one of these groups.

The cryptographic action during the handshake:

Client generates an X25519 ephemeral key + an ML-KEM-768 ephemeral encapsulation, and sends both public values.
Server generates an X25519 ephemeral, computes the shared secret with the client’s X25519 public, decapsulates the ML-KEM ciphertext, and combines both shared secrets via a HKDF.
The combined key derives the session keys.

If quantum computers eventually break X25519 (Shor on classical ECC), the ML-KEM half still protects. If a structural break is discovered against ML-KEM (e.g., a new lattice algorithm), X25519 still protects. You only lose security if both halves break.

The key combiner

The cryptographically subtle part: how do you combine two shared secrets into one in a way that inherits security from both?

The naive approach — concatenate the shared secrets and run them through HKDF — works, with a caveat: HKDF needs the inputs to have enough entropy. If one half has zero entropy (the algorithm is broken), the HKDF output gets full entropy from the other half and is still secure.

The IETF-standardized combiner is essentially this:

\text{combined\_secret} = \text{HKDF}(X25519\_secret \,||\, MLKEM\_secret, \text{transcript hash}).

The transcript hash includes both public keys and the message exchange so far, binding the combiner to the specific handshake. This prevents downgrade attacks where an attacker substitutes a weaker public key.

Security is provably at least as strong as the stronger of the two algorithms. If $X25519$ is unbroken, the combined secret is secure. If $ML-KEM$ is unbroken, the combined secret is secure. Only if both break does the combined secret fall.

This is the conservative-migration argument: hybrid TLS is no more vulnerable than classical TLS today (X25519 alone is a baseline) and gains post-quantum protection without giving up that baseline.

Deployment status as of 2026

The deployment of hybrid TLS has been one of the cleanest cryptographic migrations in internet history. Tracking by Cloudflare and Akamai shows the rollout:

2023: Initial support in Chrome 116 and Cloudflare’s edge as an experimental feature.
2024: Default enablement in Chrome desktop and mobile. Firefox 124 adds support. Microsoft Edge follows.
Late 2024: TLS 1.3 hybrid groups standardized in RFC 9598. AWS, Google, Cloudflare, and Fastly enable on production traffic.
2025: Apple Safari adds support. iOS 18 and macOS Sequoia ship with hybrid TLS by default.
2026 (now): Most major browsers and CDNs use hybrid TLS by default. Tracking shows ~30-50% of TLS handshakes are now hybrid. The remainder are mostly older browsers, embedded devices, or specific TLS implementations that haven’t been updated.

Library support is broadly available:

OpenSSL 3.5+ (released 2024) supports hybrid TLS natively.
BoringSSL has supported hybrid groups since late 2023 (used by Chrome, Cloudflare).
Rustls 0.22+ has hybrid support.
wolfSSL, mbedTLS added support in 2025.
Java/Bouncy Castle added hybrid TLS in BC 1.78 (2025).

Embedded and legacy devices are the long tail. Cisco, Juniper, F5 have updated their products to support hybrid TLS, but installed-base updates are slow. Industrial-control devices, point-of-sale systems, and old VPN concentrators still use pure-classical TLS.

Performance impact

The performance story is mostly fine. Hybrid TLS handshakes are larger and somewhat slower than classical handshakes:

Metric	Classical (X25519)	Hybrid (X25519+ML-KEM-768)
Public key + ciphertext (client to server)	32 B	1,200 B
Public key + ciphertext (server to client)	32 B	1,120 B
TLS handshake added round-trip latency	baseline	typically negligible
CPU cost per handshake (server)	baseline	+10-20%
Bandwidth cost per handshake	baseline	+2.4 KB

The 2.4 KB additional handshake size matters most on lossy or constrained networks. On low-MTU connections (older mobile, satellite), the larger ClientHello can fragment, adding round-trips.

In practice, on a normal modern internet connection, the hybrid handshake adds 0-1 ms to TLS setup. On a degraded connection (high loss, low bandwidth), it can add hundreds of milliseconds.

What hybrid does NOT cover

Hybrid TLS in 2026 covers key exchange (the way the client and server establish a session key). It does not yet cover:

Authentication. TLS server authentication (the certificate verifies the server) still uses RSA or ECDSA in production. ML-DSA-based certificates are deployable but not widely used. CA infrastructure is still classical-only.
Pre-shared keys (PSKs). Older session-resumption mechanisms still use classical-derived PSKs.
Long-term identity. Certificate transparency, OCSP, and certificate signatures all use classical signatures.

The key-exchange protection means harvest-now-decrypt-later attacks (capture encrypted traffic now, decrypt later when quantum computers arrive) are mitigated for the session-key portion. But the certificate signatures and authentication chain remain classical, and a future quantum attack against ECDSA would let an adversary forge certificates and impersonate servers in real time.

The next migration phase is PQ certificates — replacing classical signatures in the public-key infrastructure with ML-DSA or hybrid signatures. This is harder because of certificate sizes (ML-DSA certs are ~5-10× larger than ECDSA) and the complexity of upgrading global CA infrastructure. Production rollout is targeted for 2027-2030.

Operational implications for system administrators

If you operate a TLS-fronted service in 2026:

Update your TLS library. OpenSSL 3.5+, BoringSSL recent, or equivalent. Hybrid groups should be enabled by default in 2025-2026 versions.
Verify hybrid is being negotiated. Tools like nmap --script ssl-enum-ciphers or testssl.sh show negotiated groups. Look for X25519MLKEM768 in the supported groups list.
Monitor handshake performance. Most monitoring won’t show degradation, but if you’re on a constrained network, the larger handshake matters.
Plan for PQ certificates. This is the next migration. ML-DSA certificates are starting to appear; expect hybrid certificates to become available in 2026-2027.

If you’re a developer of TLS-using applications:

Trust your library. Modern TLS libraries handle hybrid groups transparently. You don’t need to think about cryptographic primitives.
Test with embedded clients. Older devices may still negotiate classical-only; ensure your service supports both.
Measure bandwidth and CPU. The 10-20% CPU overhead is usually negligible but matters at high handshake volume.

Common misconceptions

“Hybrid TLS is twice as slow as classical.” No — the additional CPU cost is 10-20%, not 100%. ML-KEM is fast; the bottleneck is the additional bandwidth and the larger ClientHello on lossy networks.

“Hybrid TLS is now standard everywhere.” Default in major browsers and CDNs; not yet in many embedded systems, older client libraries, and legacy enterprise environments. The migration is ~50% complete in observable traffic and may take another 2-3 years to reach near-universal support.

“PQ certificates are coming soon.” “Coming” is doing a lot of work. ML-DSA certificate support in major CAs is just starting in 2025-2026. Public-key infrastructure transitions take 5-10 years; expect 2030 for meaningful PQ-cert deployment.

“Hybrid TLS is overkill if quantum computers are 10+ years away.” It’s not overkill if the threat is harvest-now-decrypt-later: an adversary who captures TLS traffic in 2026 can decrypt it in 2036 if quantum computers exist by then and the session was protected only by ECDH. The migration must precede the quantum threat by years, which is why 2024-2026 was the right time to start.

Where this goes next

Tutorial 52 covers the harvest-now-decrypt-later threat model in operational detail — what an attacker can do, what data is at risk, and how to assess your organization’s exposure to the timeline.