ML-KEM Is Already in Your Connections: How to See It, Stack by Stack

Somewhere between late 2024 and early 2026, without a single pop-up asking permission, a large share of the world's encrypted web traffic changed how it agrees its secret keys. Browsers, phone operating systems and the most common remote-login tool quietly began offering a new kind of key exchange built on ML-KEM, the post-quantum standard defined in Federal Information Processing Standard (FIPS) 203. By early December 2025, Cloudflare, one of the largest networks that carries web traffic, counted 52 percent of human-generated requests reaching it as post-quantum protected. That raises three practical questions that the algorithm descriptions never answer. Where exactly is this already on? How can an ordinary person, or an AI agent, check whether one particular connection used it? And when the answer is yes, what does that yes actually prove? This guide answers all three, piece of software by piece of software, with dates you can check.

A switch that flipped without asking

Think about the lock on your front door being replaced while you were out, by a locksmith who left your keys working exactly as before. Nothing looks different, nothing feels different, and yet the mechanism inside is new. That is roughly what happened to a large part of internet encryption. When a browser connects to a website protected by Hypertext Transfer Protocol Secure (HTTPS), the two sides first run a short opening conversation called a handshake. Inside that handshake they agree a fresh secret key that will scramble everything that follows. The agreement step is the part a future quantum computer threatens, because someone can record the handshake today and try to break it years from now. That is the record-now, decrypt-later problem in one sentence.

The fix that shipped is not ML-KEM on its own. It is a pairing with an awkward name: X25519MLKEM768. X25519 is the well-tested classical method most connections already used; ML-KEM-768 is the middle-strength version of the new standard. The two run side by side and both feed the final secret, so an attacker would need to break both. The protocol that carries this is Transport Layer Security (TLS) version 1.3, the modern version of the protection behind the padlock in a browser address bar.

Because the change happens inside the handshake, there is no new button, no new padlock colour and no message to the user. A connection either negotiates the new method or it falls back to the old one, and it does so in a fraction of a second. That invisibility is a gift for adoption, and a problem for anyone who needs to know what is actually protected. The rest of this guide is about making the invisible visible.

It helps to separate two words that often get blurred: supported and used. A piece of software supports ML-KEM when the code is there and could be switched on. It uses ML-KEM on a particular connection only when that code is enabled, offered, accepted by the other side, and actually chosen. Most confusion about post-quantum readiness comes from treating the first word as if it meant the second. A product page that says 'supports post-quantum TLS' tells you something about possibility; a negotiated connection tells you something about reality.

Who turned it on, and when

Software does not get post-quantum protection all at once. Each product decides when to offer it, whether to turn it on by default, and whether to give administrators a way to switch it off. A default is simply what happens if nobody changes a setting, and defaults are what most of the world actually runs. Here is the state of the main pieces of software as published by their own makers, checked in October 2026.

Google's Chrome browser began offering a hybrid post-quantum exchange to every desktop user in version 124, in spring 2024, using a pre-standard draft of the algorithm then called Kyber. In September 2024 Google announced that Chrome 131 would switch to the final standard, ML-KEM, and drop the draft entirely, because the two are not compatible and post-quantum key shares are too large to offer two at once. Firefox added the same hybrid exchange in version 132, and Mozilla's administrator guide now states that Firefox offers hybrid X25519 plus ML-KEM-768 by default. Apple's operating systems released in September 2025, including iOS 26 and macOS Tahoe 26, advertise the hybrid exchange automatically for connections made through Apple's networking libraries.

Beyond browsers, OpenSSH, the most widely used tool for logging into remote servers through Secure Shell (SSH), has offered a post-quantum exchange by default since version 9.0 in April 2022, and made the ML-KEM-based one, called mlkem768x25519-sha256, its default in version 10.0 in April 2025. OpenSSL, the open-source cryptography library inside a huge amount of server software, added ML-KEM in version 3.5 and changed its default list to prefer the hybrid groups. The Go programming language turned the hybrid on by default in version 1.24. Java's standard networking library puts X25519MLKEM768 first by default from Java Development Kit (JDK) 27.

Windows is the instructive exception. Microsoft's Secure Channel component, known as Schannel, is the TLS engine used by many Windows services and applications. Hybrid ML-KEM support in Schannel reached general availability on 14 July 2026, but Microsoft's own documentation lists the post-quantum groups as supported and not enabled by default; an administrator has to add them, for example with the Enable-TlsEccCurve command. The capability exists, yet a fresh system will not use it until someone decides it should.

Two details in that history are worth keeping. First, the name changed underneath everyone. The draft algorithm deployed in 2024 was called Kyber and travelled under a different TLS codepoint, a registration number that tells both sides which method is meant: 0x6399 for the Kyber draft, 0x11EC for the final ML-KEM hybrid. The registry now marks the Kyber draft as obsolete. A log line, a scanner report or a vendor document that still says Kyber is describing the pre-standard version, which current browsers no longer speak. Second, nearly every maker also published a way to turn the feature off: an enterprise policy in Chrome and Firefox, a runtime setting in Go, the server-side choice in Schannel. Off switches are reasonable during a transition, but each one is also a place where protection can quietly disappear, so they deserve the same attention as the defaults.

Post-quantum is a property of each stack, not of a device

Here is the idea that surprises most people, and the one that matters most in practice. A computer is not post-quantum or classical as a whole. Every program that opens an encrypted connection uses some TLS or SSH implementation underneath it, often called its stack: a bundle of code that knows how to run the handshake. Different programs on the same machine frequently use different stacks, and each stack has its own version and its own defaults.

Picture one office computer. Its Chrome browser carries its own built-in cryptography library and negotiates X25519MLKEM768 with any website that supports it. A background service on the same computer, written to use Windows Schannel, connects to an internal server with plain classical key exchange, because the post-quantum groups are off until an administrator enables them. A Python script that a team wrote last year uses whatever OpenSSL its Python was built with; if that is a version older than 3.5, it simply has no ML-KEM to offer. And the same person's SSH client, if it is OpenSSH 10.1, prints a warning whenever the server it reaches cannot do post-quantum exchange.

So the honest answer to 'is this machine quantum-safe for key exchange?' is: which program, talking to which server? Inventories that record operating system versions alone will miss this. The useful record is per connection path: the client program, the library and version it uses, the server software, and what they negotiated.

Why do programs bring different stacks at all? Partly history, partly control. Browsers ship their own cryptography so they can update it every few weeks without waiting for operating systems. Operating systems provide a shared stack so that thousands of applications get security fixes in one place. Programming languages such as Go and Java include their own implementations so that programs behave the same on every platform. Python and many command-line tools lean on whichever OpenSSL they were built against. Each of those choices is sensible, and together they explain why the same question has a different answer in each program.

The same rule applies on the server side. A web server, a load balancer, an application gateway and a database driver on the same host can each carry a different stack. When a team says its service is post-quantum ready, the follow-up question is always: which component terminates the connection, meaning which one actually runs the handshake, and what does that component offer?

Both ends have to agree

A handshake is a negotiation, a little like two travellers finding a shared language. The client speaks first, listing the key-exchange methods it can use, in order of preference, in a message called the ClientHello. To save a round trip it also attaches a key share for its favourite method: the public part of a brand-new key pair. The server looks at the list and picks one method it also supports. If the server knows X25519MLKEM768, the connection becomes hybrid. If it does not, a correctly built server ignores the unfamiliar option and picks the classical X25519 instead, and the connection still works.

That design is why the switch could roll out quietly: old servers keep working with new clients. It also means a modern browser is necessary but not sufficient. The server, or whatever sits in front of it, must also support the new method. In TLS 1.3 the server makes the final choice, so a website's operator decides whether visitors get post-quantum protection, as long as the visitor's software offers it.

There was one ugly surprise. The post-quantum key share is large: 1,216 bytes from the client, compared with 32 bytes for X25519 on its own. That pushes the opening message past the size of a single network packet. Some servers and network appliances had been written assuming the opening message always arrived in one piece, and they dropped the connection instead of waiting for the rest. A public page called tldr.fail tracked the affected products. Most have been fixed, but this is why several stacks ship an off switch: Go documents a setting that reverts its default for exactly this situation, and Chrome, Firefox and Apple all publish guidance for administrators.

There is also a quieter cost when the guess goes wrong. Because the client sends a ready-made key share for its favourite method, a server that supports the hybrid but was not sent a share for it has to ask again, using a message called HelloRetryRequest, which costs one extra round trip across the network. Cloudflare describes exactly this trade-off for its own connections to customers' servers: sending the post-quantum share immediately is faster but broke a small fraction of connections in its scans, while waiting one round trip was slower but safe. Clients and servers therefore have to guess well, and Google has proposed letting servers advertise their supported methods in advance so clients can guess right the first time.

How to check one connection

Checking does not require special equipment. It requires knowing where each kind of software reports what it negotiated. For a browser, the simplest route is a test page that reports the key exchange your connection used; Cloudflare runs one at pq.cloudflareresearch.com, which states whether the visiting browser negotiated X25519MLKEM768. Browser developer tools also show connection details for the page in front of you, though the exact panel names change between versions.

On a Mac running macOS Tahoe 26, Apple documents a built-in command, nscurl with the tls-diagnostics option, that connects to any web address and prints the negotiated key-exchange group. A server that supports the new method returns the line 'Negotiated TLS key exchange group (name): X25519MLKEM768'. On any system with OpenSSL 3.5 or later, the s_client tool can connect to a server while offering only the hybrid group; if the server cannot do it, the connection fails, which is itself the answer.

For SSH, the verbose mode of the OpenSSH client prints the chosen key-exchange algorithm near the top of its output, and from version 10.1 OpenSSH goes further: it prints a warning that the connection is not using a post-quantum key exchange and may be vulnerable to store-now, decrypt-later attacks, pointing to the project's explanation page. A warning like that turns a hidden property into something every user sees.

Programs can check themselves too. Python's standard ssl module gained, in version 3.15, a method on a connected socket that returns the group used for key agreement, so a script can record whether its own connection was hybrid. Other runtimes offer comparable connection details or debug logs; the documentation for the runtime in use says where. Logging that one value, connection by connection, is the difference between hoping a migration happened and knowing it did.

Two cautions keep these checks honest. A check reports what happened between the checking tool and the first server it reached, using the checking tool's own stack. If the tool is newer than the application you care about, a positive result can flatter the application. The most reliable check is therefore made by the same program, or at least the same library and version, that carries the real traffic. And a negative result is not always the server's fault: a company network may route traffic through an inspection proxy that opens its own connection, so the browser may be negotiating with the proxy rather than the website.

# macOS Tahoe 26: look for 'X25519MLKEM768' in the key exchange line
nscurl --tls-diagnostics https://www.example.com

# OpenSSL 3.5+: offer only the hybrid group; failure means the server cannot do it
openssl s_client -connect www.example.com:443 -groups X25519MLKEM768 -brief </dev/null

# OpenSSH: the 'kex: algorithm:' line names the key exchange
ssh -v user@server.example.com 2>&1 | grep 'kex: algorithm'

What a yes proves, and what it does not

Suppose the check comes back positive: X25519MLKEM768, or mlkem768x25519-sha256 for SSH. That is genuinely good news, and it is worth being precise about its edges. It proves that the secret key for this one connection, between these two endpoints, was agreed with a method designed to resist a future quantum computer. Anyone who recorded that conversation today should not be able to unlock it later. That is exactly the protection against record-now, decrypt-later collection.

It does not prove who the server is in a post-quantum way. The server still proves its identity with a certificate and a classical signature, typically based on Rivest-Shamir-Adleman (RSA) or elliptic curves. That is a deliberate choice for now: forging an identity requires a quantum computer at the moment of the connection, while breaking recorded key exchange can happen at any time in the future. Microsoft's own walkthrough of post-quantum TLS on Windows makes the same point: the key exchange is post-quantum, the authentication is classical, by design for this stage.

It does not cover the next hop either. Many websites sit behind a content delivery network or a reverse proxy, a server that receives your connection and opens a separate connection to the real application behind it. Your check only sees the first connection. And it says nothing about older connections that use TLS 1.2, which will never carry these new groups. Microsoft states plainly that TLS 1.2 and earlier do not and will not support post-quantum key exchange.

Finally, a yes today says nothing about yesterday. Traffic recorded before a server or client was upgraded was protected only by the classical exchange in use at the time. Upgrading protects new conversations from the moment it happens; it cannot reach back and re-protect what was already sent. That is one more reason the date a path became hybrid is worth writing down.

The front door and the back door

The gap between the first hop and the hops behind it is not hypothetical. Cloudflare publishes what it measures. In its 2025 review it reported that the share of human web traffic reaching it with post-quantum key exchange grew from 29 percent at the start of the year to 52 percent in early December, helped by Apple's September releases: within four days of iOS 26 shipping, post-quantum requests from iOS devices jumped from under 2 percent to 11 percent.

Behind the edge the picture is very different. In its 2025 state-of-the-internet report, Cloudflare counted roughly half of clients and 39 percent of public web servers able to use X25519MLKEM768, but only 3.7 percent of origins, the customers' own servers that Cloudflare connects to when it needs content it has not cached. The visitor's connection to the edge, the front door, can be post-quantum while the connection from the edge to the origin, the back door, is still classical. Recorded traffic on that back connection would carry the same data.

The lesson generalises beyond one company. Front doors are run by a handful of large organisations with strong reasons to upgrade quickly. Back doors are run by everyone else: internal services, partner integrations, older appliances. Progress on the front door is real, but it should never be read as progress on the whole path.

Inside an organisation the same pattern repeats. Public websites tend to sit behind modern gateways that were upgraded early. Connections between internal services, to partners, to managed databases and to older equipment are where classical exchange lingers, often because nobody owns the question. Those internal paths are also where some of the most sensitive data travels, which is why the per-connection record matters more there than anywhere else.

What this means for AI agents and the people who run them

An AI agent is a program that uses a large language model to decide what to do and then acts, by calling tools, application programming interfaces (APIs) and other services. Each of those calls opens or reuses a network connection, and each connection runs through some stack. The agent's calls to its model provider, its tool calls over the Model Context Protocol (MCP), the standard way agents discover and call tools, and its calls to internal databases may each use a different library, written in a different language, deployed on a different date.

That makes agents a sharp example of the per-stack rule. A team can sit in a browser that shows post-quantum protection while the agent they are building talks to its tools through a runtime that has never heard of ML-KEM. The conversation between the agent and its tools often carries exactly the data most worth recording: retrieved documents, customer records, the reasoning behind decisions. If that traffic is worth keeping secret for years, its key exchange is the part that needs checking first.

Hosted services add a twist. When an agent calls a model or a tool run by another company, the server side of that connection belongs to the provider. The agent's team controls only what its own client offers. The right question for a provider is concrete: does your endpoint select X25519MLKEM768 when it is offered, and from which date? A provider that can answer with a group name and a date is easier to trust than one that answers with the word 'quantum-safe'.

The practical habits are simple. For each agent, list its outbound connections and the stack each one uses. Prefer runtimes whose defaults already include the hybrid group: current OpenSSL, Go, Java 27 and the major browsers' libraries. Where a component is off by default, such as Windows Schannel, decide deliberately whether to enable it, test it on paths you control, and write the decision down. Record the negotiated group as a routine metric, the way teams already record latency and error rates, so that a quiet fallback to classical exchange shows up on a dashboard instead of in an audit years later. And when an AI coding assistant writes connection code, check that it does not pin an old, classical-only list of groups.

1. List every outbound connection an agent makes and the TLS or SSH stack behind it.
2. Check each path once with a tool that reports the negotiated group.
3. Enable the hybrid group where it is off by default, starting with paths you control at both ends.
4. Log the negotiated group per connection and alert on unexpected classical results.
5. Treat the edge, the proxy and the origin as separate hops, each with its own answer.

Glossary

ML-KEM

Module-Lattice-Based Key-Encapsulation Mechanism, the FIPS 203 post-quantum standard for agreeing a shared secret.

X25519MLKEM768

The hybrid TLS 1.3 key-exchange group that combines classical X25519 with ML-KEM-768; codepoint 0x11EC.

Handshake

The short opening exchange in which two machines agree how to protect a connection and derive its secret keys.

ClientHello

The first handshake message, in which the client lists the methods it supports and sends a key share.

Stack

The library and settings a program uses to run TLS or SSH; different programs on one computer often use different stacks.

Default

What software does when nobody changes a setting, and therefore what most installations actually do.

Record-now, decrypt-later

Collecting encrypted traffic today in the hope of breaking its key exchange with a future quantum computer.

Origin server

The organisation's own server that sits behind a content delivery network or proxy and serves the real content.

Schannel

The Windows component that provides TLS to many Windows services and applications.

Further reading

1. A new path for Kyber on the web (Google Online Security Blog, 2024)
2. Prepare your network for quantum-secure encryption in TLS (Apple Support)
3. OpenSSH Post-Quantum Cryptography
4. TLS supported groups in Windows 11 24H2 and later (Microsoft Learn)
5. State of the post-quantum Internet in 2025 (Cloudflare)
6. The 2025 Cloudflare Radar Year in Review (Cloudflare)