Hybrid Post-Quantum TLS: How X25519MLKEM768 Works and How to Enable It (2026)

Hybrid post-quantum TLS is a TLS 1.3 handshake whose key exchange combines a classical elliptic-curve Diffie-Hellman exchange with ML-KEM, the post-quantum key-encapsulation mechanism standardized in FIPS 203. The session key is derived from both shared secrets, so the connection stays confidential as long as either algorithm holds. The most widely deployed hybrid group is X25519MLKEM768, standardized in RFC 10024 in August 2026.

Hybrid TLS is the first post-quantum control most organizations can switch on. It protects traffic against "harvest now, decrypt later" recording, it needs no new certificates, and Chrome, Firefox, Safari and OpenSSL 3.5 already use it by default.

This guide explains how the hybrid handshake works, the three groups defined in RFC 10024, who supports them, the operational issues to test for, and how to enable and verify hybrid key exchange on your own servers.

---

Table of Contents

1. How Hybrid Post-Quantum TLS Works
2. The RFC 10024 Hybrid Groups
3. Hybrid vs Pure ML-KEM in TLS
4. Browser, Library and Server Support
5. What to Test Before You Roll It Out
6. How to Enable Hybrid Post-Quantum TLS
7. How to Check Whether a Server Uses It
8. An Enterprise Rollout Plan
9. How DuoKey Helps
10. FAQ

---

How Hybrid Post-Quantum TLS Works

TLS 1.3 negotiates key exchange through "named groups". A hybrid group is a named group that runs two key exchanges in parallel and treats them as one:

1. ClientHello. The client generates a fresh X25519 key pair and a fresh ML-KEM-768 key pair. Its key_share for X25519MLKEM768 is the ML-KEM encapsulation key (1,184 bytes) followed by the X25519 public key (32 bytes): 1,216 bytes in total.
2. ServerHello. If the server supports the group, it encapsulates against the client's ML-KEM key, which produces a ciphertext and a 32-byte ML-KEM shared secret, and computes the X25519 shared secret. It returns the ML-KEM ciphertext (1,088 bytes) and its own X25519 public key (32 bytes): 1,120 bytes.
3. Key schedule. Both sides concatenate the two shared secrets (64 bytes) and feed the result into the normal TLS 1.3 key schedule. Everything after that is unchanged.

Three properties follow:

• Confidentiality against a future quantum computer. An attacker who records the handshake would need to break both X25519 and ML-KEM-768 to recover the session keys.
• Authentication is unchanged. The server still proves its identity with its existing RSA or ECDSA certificate. Hybrid key exchange protects against later decryption, not against a future forged certificate. Post-quantum authentication is the ML-DSA certificate migration.
• Nothing to store. Both key pairs are ephemeral, used for one handshake and destroyed, exactly like ECDHE today. There are no new keys to manage (see ML-KEM key management).

If a client lists the hybrid group as supported but sends a key share only for a classical group, a server that prefers the hybrid group can answer with a HelloRetryRequest, at the cost of one extra round trip. Servers and clients that do not know the group simply ignore it and fall back to a classical group.

---

The RFC 10024 Hybrid Groups

RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3" (Standards Track, August 2026), defines three hybrid groups:

For comparison, a plain X25519 key share is 32 bytes.

Points that matter in practice:

• X25519MLKEM768 is the default choice. It is the only group marked Recommended and the one browsers send.
• SecP256r1MLKEM768 and SecP384r1MLKEM1024 exist for environments that must use NIST curves, for example under FIPS 140 validation constraints. SecP384r1MLKEM1024 pairs P-384 with ML-KEM-1024.
• Order differs. In X25519MLKEM768 the ML-KEM part comes first, in both the key share and the combined secret. In the two NIST-curve groups the ECDH part comes first. Implementations that get this wrong fail to interoperate.
• Pre-standard code points are obsolete. RFC 10024 obsoletes the earlier X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498) entries, which used pre-standard Kyber. Clients or appliances that still offer only those groups need an update.

---

Hybrid vs Pure ML-KEM in TLS

A separate IETF document, draft-ietf-tls-mlkem, defines pure ML-KEM groups (MLKEM512, MLKEM768, MLKEM1024) with no classical component. As of October 2026 it is in the RFC Editor queue, with Informational status, and its groups are not marked Recommended.

For US national security systems, the NSA's CNSA 2.0 FAQ states that it "will not require" hybrid products and considers a system compliant only when it uses CNSA 2.0 algorithms in an NSA-approved manner. An NSA-authored IETF draft profiling TLS for CNSA 2.0 requires ML-KEM-1024 for key establishment. Outside that scope, hybrid is the common choice during the transition. Dates for national security systems are in the CNSA 2.0 timeline.

---

Browser, Library and Server Support

From Cloudflare's post-quantum support list (last updated June 2026):

Load balancers, firewalls and VPN gateways follow their own firmware schedules. Our implementation guides cover F5 BIG-IP for TLS and FortiGate for the equivalent hybrid key exchange in IPsec.

---

What to Test Before You Roll It Out

Hybrid TLS is designed to fall back cleanly, but larger handshakes expose weaknesses in the network path.

Measure handshake size and latency before and after, on the networks your users actually use.

---

How to Enable Hybrid Post-Quantum TLS

OpenSSL 3.5 or later. The default TLS key shares already offer X25519MLKEM768 and X25519, so an application linked against OpenSSL 3.5 negotiates the hybrid group with clients that support it unless its configuration overrides the group list. Check for hard-coded group or curve lists in your configuration: they often silently exclude the hybrid group.

NGINX built with OpenSSL 3.5:

ssl_protocols TLSv1.3 TLSv1.2;
# Hybrid first, classical fallback
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Apache HTTP Server with OpenSSL 3.5:

SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

Appliances and managed services. Follow the vendor's documentation and firmware requirements; for F5 BIG-IP, see our step-by-step guide. For cloud load balancers and CDNs, check the provider's TLS policy names for post-quantum or hybrid support.

Keep a classical group in the list. Removing it breaks clients that do not support the hybrid group yet.

---

How to Check Whether a Server Uses It

From the command line, with OpenSSL 3.5 or later:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i -E "group|temp key"

If the server supports the group, the output names X25519MLKEM768 as the negotiated group. If the handshake fails with only that group offered, the server does not support it.

In a browser. In Chrome, the Security panel of DevTools shows the key exchange used for the page.

At scale. For many domains and endpoints, use a scanner that actively probes for the hybrid group, because a passive look at the certificate tells you nothing about key exchange.

---

An Enterprise Rollout Plan

1. Inventory TLS endpoints. List internet-facing and internal endpoints, the TLS stack behind each (library, appliance, managed service) and whether it terminates or passes through TLS. A cryptographic inventory gives you the list.
2. Start where the data lives longest. Prioritize endpoints that carry data with a long confidentiality requirement: customer data, payments, health records, intellectual property.
3. Upgrade stacks, then enable. Move servers to OpenSSL 3.5 or another library with hybrid support, then enable X25519MLKEM768 with a classical fallback.
4. Cover both legs. For TLS terminated on load balancers or proxies, enable hybrid groups on the client side and the server side.
5. Measure negotiation. Track the share of handshakes that use the hybrid group per endpoint. It tells you which clients and partners are still classical.
6. Record it in your roadmap. Hybrid key exchange is one workstream of the PQC migration roadmap. Certificates and signatures follow separately.

---

How DuoKey Helps

According to DuoKey's documentation:

• Outside-in measurement. The free Quantum Risk Score uses publicly observable signals such as TLS configuration, and includes hybrid key exchange support in its crypto-agility signal. It needs no internal access.
• Active detection. The domain mode of DuoKey's PQC Scanner, the discovery engine of DuoKey CPM, performs a TLS handshake against each target and detects the negotiated key exchange. Its --pqc option runs a live post-quantum probe and is the mode that distinguishes a hybrid key exchange such as X25519MLKEM768 from classical X25519.
• Tracking over time. CPM keeps the results in a CBOM with dated remediation targets, so the share of endpoints on hybrid key exchange becomes a measurable migration metric.

---

FAQ

Q: What is hybrid post-quantum TLS?

It is TLS 1.3 with a key exchange that combines classical ECDHE (for example X25519) and ML-KEM (FIPS 203). The session key depends on both, so traffic stays confidential unless both algorithms are broken. Certificates and authentication do not change.

Q: Is X25519MLKEM768 standardized?

Yes. RFC 10024 (Standards Track, August 2026) defines X25519MLKEM768 with code point 0x11EC, together with SecP256r1MLKEM768 and SecP384r1MLKEM1024. X25519MLKEM768 is the only one of the three marked Recommended by IANA.

Q: Do I need new certificates for post-quantum TLS?

Not for hybrid key exchange. Your existing RSA or ECDSA certificates keep working. Certificates change only when you migrate authentication to post-quantum signatures such as ML-DSA.

Q: How much larger is a hybrid TLS handshake?

With X25519MLKEM768 the client key share grows from 32 to 1,216 bytes and the server key share from 32 to 1,120 bytes, about 2.3 KB more in total. Test middleboxes and proxies that make assumptions about ClientHello size.

Q: Does hybrid TLS meet CNSA 2.0?

Not by default. The NSA considers national security systems compliant only when they use CNSA 2.0 algorithms in an NSA-approved manner, and an NSA-authored TLS profile requires ML-KEM-1024. X25519MLKEM768 uses ML-KEM-768. Outside national security systems, hybrid TLS is the common transition choice.

Q: How do I check if a website uses post-quantum TLS?

Run openssl s_client from OpenSSL 3.5 or later with -groups X25519MLKEM768 and look at the negotiated group, or open the Security panel in Chrome DevTools. For many endpoints, use a scanner that actively probes for the hybrid group.

---

References

• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• IETF Datatracker: draft-ietf-tls-mlkem, ML-KEM Post-Quantum Key Agreement for TLS 1.3
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• Cloudflare: Post-quantum cryptography support
• OpenSSL 3.5 release notes
• OpenJDK JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• NSA: CNSA 2.0 and Quantum Computing FAQ (Ver. 2.2, October 2026, PDF)
• IETF Internet-Draft: CNSA 2.0 TLS profile (draft-becker-cnsa2-tls-profile-05)
• DuoKey Docs: PQC Scanner, domain mode