What ML-KEM (FIPS 203) Changes in the TLS Handshake
ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism and is the first NIST-finalized post-quantum standard for key exchange, published as FIPS 203 in August 2024 (NIST FIPS 203). It derives from the CRYSTALS-Kyber scheme. A KEM is not a signature algorithm: it encapsulates a shared secret from which both sides derive the same session key. This key exchange is exactly what protects the confidentiality of a TLS connection, which is why it is the first target of post-quantum migration.
The sizes are the decisive difference from classical cryptography. ML-KEM-768, the parameter set dominant on the web, uses an encapsulation key of 1184 bytes, a ciphertext of 1088 bytes, and a 32-byte shared secret (NIST FIPS 203). In the handshake, the client places its 1184-byte encapsulation key into the key_share extension of the ClientHello, and the server encapsulates and returns the 1088-byte ciphertext. For comparison, a classical X25519 curve occupies just 32 bytes in the key_share.
Both the IETF draft and the BSI explicitly recommend hybrid operation (IETF draft-ietf-tls-ecdhe-mlkem). X25519MLKEM768 combines the classical X25519 curve with ML-KEM-768: as long as no cryptographically relevant quantum computer exists, X25519 carries the security; once one appears, ML-KEM takes over. An attacker would have to break both schemes at once. The client therefore sends 32 bytes of X25519 plus 1184 bytes of ML-KEM, roughly 1216 bytes in the key_share (NIST FIPS 203).
2026: Default in Chrome, Firefox, and on Apple Platforms
The shift came faster than many expected. Chrome has shipped the standardized hybrid key exchange as a default since Chrome 131 (November 2024), Firefox enabled X25519MLKEM768 for HTTPS with Firefox 132 and for QUIC from Firefox 135. Apple added system-wide support in iOS 26 and macOS Tahoe 26 in the fall of 2025. In addition, widely used TLS libraries such as OpenSSL and the Go standard library adopted the mechanism (Measurement Study of Post-Quantum Readiness of the Internet 2026).
| Platform | Hybrid on by default | Scope |
|---|---|---|
| Chrome | from version 131 (Nov 2024) | HTTPS, later QUIC too |
| Firefox | from version 132 | HTTPS, QUIC from Firefox 135 |
| Apple (iOS/macOS) | iOS 26 / macOS Tahoe 26 | system-wide, fall 2025 |
| OpenSSL, Go, etc. | 2024-2025 | hybrid X25519MLKEM768 |
The result of this early decision is measurable: over 50% of human-generated TLS traffic to Cloudflare already used the hybrid X25519MLKEM768 key exchange by late October 2025 (Cloudflare Radar). Because browsers offer the post-quantum key share on their own, the server alone decides whether the connection is established hybrid or classical. Anyone running TLS 1.3 cleanly is often further along than they think. A look at the difference between TLS 1.2 and TLS 1.3 makes clear why the protocol version is the prerequisite.
The 1.2 KB Key Share: Why Older Server Stacks Fail
Post-quantum cryptography is not free. The hybrid key_share grows from 32 bytes to roughly 1216 bytes, and with it the entire ClientHello: instead of a few hundred bytes, a ClientHello of well over 1.5 KB now leaves the browser. It no longer fits in a single network packet. This is where protocol ossification becomes visible: some middleboxes, load balancers, and older TLS libraries tacitly assume that a ClientHello always fits in one packet and discard anything that violates that assumption (Cloudflare Radar).
Classical X25519: 32 bytes in the key_share. Hybrid X25519MLKEM768: 32 bytes of X25519 plus 1184 bytes of ML-KEM-768 encapsulation key add up to roughly 1216 bytes in the client key_share. The server response consists of the 1088-byte ML-KEM ciphertext plus 32 bytes of X25519, about 1120 bytes together (NIST FIPS 203). That is the point at which inflexible server and network components drop the connection.
How real this risk is was shown by an early experiment: when browsers test-sent post-quantum keys of similar size directly in the ClientHello, about 0.05% of connections broke because individual components could not process the larger message (Cloudflare Radar). That sounds small, but across millions of connections it adds up to noticeable failures. The typical failure modes:
- Handshake failure on a large ClientHello: middleboxes or WAFs discard packets that do not fit into one segment, and the browser falls back to an error page.
- Version intolerance: older stacks react to unknown
key_sharegroups with a downgrade to TLS 1.2 instead of a clean HelloRetryRequest. - MTU and fragmentation issues: restrictive network paths do not fragment the larger ClientHello correctly, leading to timeouts.
- Misconfigured load balancers: TLS-terminating proxies without an update to hybrid groups ignore the post-quantum part or abort.
Browser vendors learned from the early failures and staged the rollout gradually: first as an opt-in experiment, then as a default, accompanied by telemetry on aborted handshakes. For website operators, the responsibility therefore shifts to their own infrastructure. A server that cleanly processes the larger ClientHello benefits without any action; an outdated stack silently drops out of hybrid protection, with no error message to signal it.
The transport protocol matters too: with QUIC and HTTP/3, the handshake lives in UDP datagrams, where the larger ClientHello meets different fragmentation rules than over TCP. Anyone offering both protocols should test both paths.
Harvest Now, Decrypt Later: The Threat Is Already Running
The reason for urgency is not tomorrow's quantum computer but today's data theft. In the harvest now, decrypt later pattern, attackers record encrypted traffic now and store it to decrypt once a sufficiently powerful quantum computer becomes available. Anything that must stay confidential for a long time is affected: health data, contracts, intellectual property, credentials. Because only the key exchange protects retroactive confidentiality, it is the most urgent building block of the migration.
The BSI made the consequence unambiguous in February 2026: migration plans must not only be created but executed now (BSI, Migration to Post-Quantum Cryptography). As deadlines, the authority names end of 2030 for especially sensitive data and end of 2031 for general operation. Since a full transition typically takes five to ten years, there is little time left to start. Anyone securing the encryption of mail transport will find the same logic in the article on MTA-STS and TLS-RPT for encrypted mail transport.
Post-quantum methods should initially be used only in combination with classical methods. As long as no quantum computer exists, the classical method provides protection; once one is available, the quantum-resistant method does.
— BSI, Migration to Post-Quantum Cryptography (paraphrased)
How Post-Quantum-Ready the Internet Really Is
A large-scale measurement study assessed the state of play in 2026. Across 32,011 domains, the actually negotiated TLS parameters were analyzed, from protocol version and cipher suite to key exchange (Measurement Study of Post-Quantum Readiness of the Internet 2026). The picture is split in two: one half has made the leap, the other has not.
Just under half of the domains support a hybrid post-quantum key exchange such as ML-KEM-768 with X25519 (Measurement Study 2026).
The majority of the remaining domains still rely solely on classical key exchange, leaving them exposed to harvest now, decrypt later (Measurement Study 2026).
Only a good half of domains negotiate TLS 1.3 by default, the prerequisite for hybrid key exchange (Measurement Study 2026).
A substantial share, especially in banking and government, still relies on TLS 1.2 without a post-quantum option (Measurement Study 2026).
The gap between industries is notable. Precisely the sectors with especially sensitive data, such as banking and government, lag in modernization: their above-average share of TLS 1.2 means they cannot yet technically offer the hybrid key exchange (Measurement Study of Post-Quantum Readiness of the Internet 2026). Of all places, where harvest now, decrypt later carries the greatest damage potential, the backlog is most pronounced. For operators in regulated industries, this increases the pressure to act, since the BSI deadlines apply regardless of the current level of modernization.
On the infrastructure side, the large CDNs drive the numbers: Cloudflare appears in the study as the most visible post-quantum-capable provider and covers a substantial share of hybrid connections (Measurement Study 2026). For many SMEs this means: if the website sits behind a modern CDN or reverse proxy, the hybrid key exchange is often active without any action of their own. Those who serve directly must update the server stack themselves.
The Authentication Gap: Key Exchange Yes, Certificates No
One finding of the measurement study deserves special attention: while nearly half of the domains already exchange keys in hybrid mode, the prevalence of hybrid post-quantum certificates was 0% (Measurement Study 2026). Authentication still runs on classical signatures: 54.05% of the domains studied use RSA with SHA-256, 42.32% ECDSA with SHA-256 (Measurement Study 2026). Post-quantum signatures such as ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) have not yet arrived in practice.
The key exchange protects retroactively against harvest now, decrypt later and therefore takes priority. The signature layer, that is the certificate chain, is only attackable once a quantum computer can forge live, not retroactively. That is why the order makes sense: KEM first, then signatures. Anyone who wants to keep an eye on newly issued certificates will find the right early-warning system in certificate transparency monitoring.
For operators, this does not mean ignoring the signature layer but building crypto agility: designing systems so that algorithms can be swapped without rebuilding the entire architecture. That is exactly what the BSI recommends as the core principle of migration (BSI, Migration to Post-Quantum Cryptography). Anyone who cleanly automates certificates and keys today can add PQ signatures later with little effort.
How to Check Your Post-Quantum Readiness
Post-quantum readiness is not a one-time checkmark but a state that can shift with every server update, every CDN change, and every configuration adjustment. These steps produce a reliable baseline:
- Ensure TLS 1.3: without TLS 1.3 there is no hybrid key exchange. Check whether your server offers TLS 1.3 and uses TLS 1.2 only as a fallback, not as the default.
- Check the hybrid group: verify that your server lists X25519MLKEM768 among the supported groups and actually negotiates it with a modern browser.
- Test a large ClientHello: make sure middleboxes, WAF, and load balancers process a ClientHello over 1.5 KB without dropping the connection.
- Control downgrade behavior: a server that silently falls back to TLS 1.2 on an unknown group loses post-quantum protection unnoticed.
- Check the QUIC path separately: if you offer HTTP/3, test the hybrid handshake over UDP as well, where different fragmentation rules apply.
- Monitor continuously: a one-time test goes stale. Anchor the check of protocol, cipher configuration, and certificate in ongoing monitoring.
The same diligence required for the Chrome HTTPS requirement from October 2026 applies to the post-quantum configuration: both rarely fail for lack of will, but for unnoticed configuration gaps. Continuous SSL certificate monitoring provides the foundation for this.
Monitor Your TLS Configuration Continuously
The most effective protection against silent downgrades is visibility. The XICTRAQ security scan continuously checks the TLS and handshake configuration of your website: supported protocol versions, cipher configuration, certificate validity, and the HTTP security headers including HSTS. If a connection falls back from TLS 1.3 to TLS 1.2, if a secure cipher suite disappears from the configuration, or if a certificate approaches expiry, the monitoring raises an alert before visitors or auditors notice.
Because the check is tied to every uptime check, a continuous picture emerges instead of a snapshot. Changes to the TLS configuration, for instance after a server update or a CDN change, are detected as a deviation and reported through your alerting channels, whether by email, Slack, Discord, or Telegram. That way, post-quantum readiness is not left to chance but becomes a monitored state. In addition, DNSSEC monitoring detects tampering with name resolution that would undermine a secure handshake.
What Operators Should Do Now
The good news: for most website operators, the first step is smaller than feared. This checklist puts you in a solid starting position:
- Update the server stack: bring your TLS library and web server to a version that supports X25519MLKEM768.
- Check CDN settings: if a CDN or reverse proxy is in use, enable or confirm the hybrid key exchange there.
- Test middleboxes and load balancers: ensure that large ClientHellos over 1.5 KB are passed through unchanged.
- Anchor crypto agility: automate certificate and key management so that algorithms remain swappable, as the BSI recommends (BSI, Migration to Post-Quantum Cryptography).
- Detect tampering: notice unexpected changes to content and configuration early, for example with the methods from the article on detecting and reporting defacement attacks.
- Monitor permanently: include protocol, cipher configuration, and certificate in ongoing monitoring instead of relying on a single test.
This article draws on: NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism, ML-KEM), IETF draft-ietf-tls-ecdhe-mlkem (hybrid ECDHE / ML-KEM key exchange for TLS 1.3), BSI (Migration to Post-Quantum Cryptography, recommendations), the Measurement Study of Post-Quantum Readiness of the Internet 2026 (arXiv), and Cloudflare Radar (State of the Post-Quantum Internet). Figures reflect the state of the respective publication.
Frequently Asked Questions About Post-Quantum TLS and ML-KEM
Do I need to switch to ML-KEM immediately as an SME?
Is my server insecure if it still encrypts classically?
Why do some connections break due to the larger key share?
What is the difference between ML-KEM and a post-quantum certificate?
Is it enough to use ML-KEM alone instead of hybrid?
How do I notice if my TLS configuration degrades unnoticed?
Post-Quantum Readiness as an Ongoing Task
The move to ML-KEM is not a deadline but an ongoing process. The browsers have taken the first step and offer the hybrid key exchange on their own, the large CDNs enforce it at the edge, and the BSI deadlines set the framework. What remains is the task of getting your own TLS configuration ready and keeping it ready. Anyone who updates the server stack, tests middleboxes, and builds crypto agility today is prepared for the post-quantum era without panic. The XICTRAQ security scan takes over ongoing monitoring and reports downgrades before they become a problem.