Hybrid PQC TLS

X25519MLKEM768 Explained

X25519MLKEM768 is one of the most visible signs that post-quantum cryptography is moving from standards documents into real web infrastructure. It combines today's widely used X25519 key exchange with ML-KEM-768 from the NIST post-quantum standards.

X25519

The classical elliptic-curve component already used widely in TLS key exchange.

ML-KEM-768

The post-quantum key encapsulation component standardised by NIST as part of FIPS 203.

Hybrid Result

A combined session secret designed so the connection remains protected if either component stays secure.

Why It Matters

Classical TLS protects data in transit today, but the key exchange methods used by ordinary TLS can be vulnerable to a future cryptographically relevant quantum computer. That creates harvest-now-decrypt-later risk for sensitive traffic recorded today.

X25519MLKEM768 addresses that risk at the TLS key exchange layer by adding a post-quantum component while keeping compatibility with modern web infrastructure.

What It Does Not Solve

Hybrid TLS key exchange is not a complete post-quantum migration. It does not replace all certificate signatures, software signatures, identity tokens, encrypted databases, backups, internal services or supplier cryptography.

It is still a valuable early move because it protects a highly exposed layer of the stack: public and API traffic that adversaries can record from networks today.

How to Test for It

  1. 1. Scan the public endpoint. Check whether the server negotiates a hybrid key exchange for HTTPS.
  2. 2. Confirm TLS 1.3 support. Provider support for hybrid key exchange usually depends on a modern TLS stack.
  3. 3. Check the CDN or hosting provider. Many deployments depend on Cloudflare, Fastly, AWS CloudFront or a load balancer, not just the origin server.
  4. 4. Document what remains classical. TLS key exchange may be hybrid while signatures and internal systems still need migration.

Verify X25519MLKEM768 with OpenSSL

Use an OpenSSL 3.5 or later build with this group enabled. Replace example.com in all three places with your hostname. This diagnostic offers only the hybrid group, so it tests support rather than the server's usual preference.

openssl s_client -connect example.com:443 -servername example.com -tls1_3 -groups X25519MLKEM768 -verify_hostname example.com -verify_return_error -brief < /dev/null

Confirm a completed TLS 1.3 handshake, successful certificate verification and X25519MLKEM768 as the negotiated group. Save the hostname, test time, OpenSSL version and output. Then test with your normal client configuration to check whether ordinary connections also select the hybrid group.

  • An unrecognised group error means the local client cannot run this test.
  • A handshake failure needs investigation; it may involve the server, network or TLS configuration.
  • A successful CDN edge test does not verify the separate connection to the origin.

For syntax and supported groups, consult the OpenSSL s_client reference and OpenSSL group configuration documentation. Cloudflare also documents PQC on the separate origin connection.

Prefer a browser-based starting point? Check your public endpoint for hybrid PQC TLS. Use the PQC implementation verification checklist to plan the wider pilot and record its limits.

X25519MLKEM768 questions answered

What is X25519MLKEM768?

X25519MLKEM768 is a hybrid TLS key exchange that combines the classical X25519 elliptic-curve exchange with ML-KEM-768, a NIST-standardised post-quantum key encapsulation mechanism.

Does X25519MLKEM768 make a whole website quantum-safe?

No. It protects TLS session establishment against future quantum decryption if deployed correctly, but signatures, internal APIs, databases, VPNs and key management still require separate assessment.

Why is it called hybrid?

It is hybrid because it combines a classical key exchange with a post-quantum mechanism. The session remains protected if either component remains secure.

Is X25519MLKEM768 a TLS cipher suite?

No. It is a key exchange group. A TLS 1.3 cipher suite name alone does not tell you whether the connection negotiated hybrid post-quantum key exchange. Record the negotiated group separately.

Does support-x25519mlkem768: true prove a connection is quantum-safe?

A support flag alone is insufficient evidence. Check what the emitting tool means by support, then confirm the group negotiated in a successful TLS handshake. The result applies to that connection, not every service or internal connection.

Check for Hybrid PQC TLS

Run the free scanner to see whether your public website negotiates post-quantum key exchange or only classical TLS.

Free readiness account

Keep This Guide Connected to a Real Website Scan

A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.

No cardStart the free evidence path without a paid plan.
Saved scanKeep the public endpoint result after the browser session.
Rescan laterRerun after TLS, header or provider changes.

Prefer to scan first? Open the free quantum security scanner.

Create Your Free Account

Start with Google, Microsoft or a one-time email code. You can add a domain now if you want the scanner to run after signup, but it is not required.

No cardNo passwordFree saved scan
Add a domain to scan after signup (optional)

Leave this blank to create the account first and scan later.

or use email code

No card or password is needed. The free account can keep scan evidence for rescans and badge qualification when you add a public domain.