Post-Quantum TLS Is Already Default in Browsers. Is It On Your Server?

The interesting thing about post-quantum TLS in 2026 is that the client side is finished. Chrome, Firefox and Edge have shipped the hybrid group X25519MLKEM768 as a default since version 131. Roughly nineteen out of twenty post-quantum TLS handshakes on the internet use it.

The server side is not finished. Origin support was measured near ten percent in 2026, up roughly tenfold year on year after Akamai enabled it by default for origin connections in January.

That gap is the story. Your visitors’ browsers are asking for quantum-resistant key agreement. Most servers are declining.

What is actually being protected

Post-quantum key exchange does not protect you from an attack that happens today. It protects you from an attack that happens later against traffic captured today.

The threat has a name: harvest now, decrypt later. An adversary with the budget to record encrypted traffic stores it, and waits. The session keys protecting that traffic were agreed using elliptic-curve Diffie-Hellman, which a sufficiently capable quantum computer breaks retroactively. Everything recorded becomes readable at that point, including traffic recorded years earlier.

The relevant question for a SaaS vendor is therefore not “is quantum computing here” but “how long does the data crossing this connection stay sensitive”. For authentication tokens, hours. For customer records, health data, financial positions or legal documents, decades.

What X25519MLKEM768 is

It is a hybrid: classical X25519 elliptic-curve Diffie-Hellman combined with ML-KEM-768, the NIST-standardised lattice key encapsulation mechanism. IANA codepoint 4588, or 0x11ec.

Hybrid matters. The session is secure if either component holds. If ML-KEM turns out to have a weakness, X25519 still protects you, and vice versa. This is why ETSI and the EUCC framework endorse hybrid deployment through at least 2028 and treat pure post-quantum deployments as premature.

Two siblings exist for other security levels and for FIPS environments: SecP256r1MLKEM768 and SecP384r1MLKEM1024.

Turning it on

The change is a server configuration line, not an architecture project. With OpenSSL 3.5 behind Nginx:

ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;

The ordering is deliberate. In TLS 1.3 the client sends key shares up front. If it offered a share for your first-preference group, the handshake completes in one round trip. If it did not, the server issues a HelloRetryRequest and the handshake costs an extra round trip.

Since virtually every current browser already offers an X25519MLKEM768 share, putting it first is the fast path for the majority and a fallback for everyone else. Clients without support negotiate X25519 exactly as before, with no client-side change and no compatibility break.

For a staged rollout on latency-sensitive endpoints, keep X25519 first and simply add the hybrid to the list, then reorder once you have measured.

The FIPS caveat worth knowing

ML-KEM is FIPS-approved. X25519 is not. The strictly FIPS-compliant hybrid is therefore SecP256r1MLKEM768, which Chrome does not ship by default. If you operate under a FIPS constraint you will end up preferring P256MLKEM768 and accepting that most browsers will not use it.

There is also a live Go issue to be aware of if you terminate TLS in Go: in fips140=only mode the runtime rejects crypto/ecdh.X25519 unconditionally, which breaks hybrid handshakes even though the group is on the approved curve list.

What this does not solve

Hybrid key exchange protects confidentiality of the session. It does nothing for authentication: your certificate is still signed with RSA or ECDSA, and those signatures are still classical.

That matters less than it sounds. A forged signature has to be produced during a live connection to be useful, so there is no harvest-now equivalent for authentication. Migration of the certificate chain is a later problem, and it is not one you can solve unilaterally today.

Where it maps for compliance

• NIS2 Article 21(2)(h), cryptography and encryption. Auditors increasingly ask about crypto-agility, meaning your ability to change algorithms without re-architecting.
• ISO/IEC 27001:2022 A.8.24, use of cryptography.
• DORA Article 9, for financial entities, where data retention periods are long and the harvest-now argument is strongest.

How to verify it

openssl s_client -connect yourdomain.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i "negotiated\|Cipher"

A successful handshake proves support. A failure proves nothing on its own, because the host might simply be unreachable, which is why any honest check repeats the handshake without the restriction before concluding anything.

That is how the SaaSFort check works: it attempts a handshake restricted to the hybrid group, and on failure confirms the server answers TLS at all before reporting the absence. The result is reported as informational rather than as a failure, because in 2026 not offering post-quantum key exchange is an exposure with a delayed effect, not a misconfiguration.

The short version

One configuration line. No client changes. No compatibility risk, because fallback is automatic.

The reason to do it now rather than in 2028 is that the data being recorded today is recorded today. You cannot retroactively encrypt it.