Windows macOS ML-KEM support remote access: what works

Windows and macOS ML-KEM support for remote access means that the operating system can negotiate a hybrid key exchange, which combines classical elliptic-curve Diffie-Hellman with ML-KEM from FIPS 203, when it sets up encrypted sessions. Whether a remote user’s tunnel into OT and critical infrastructure is actually quantum safe depends on which software stack sets up that tunnel.

The difference matters most where industrial networks are concerned. Traffic between engineering workstations and control networks often stays sensitive for decades, which makes it a good target for “harvest now, decrypt later” collection. This article covers what the operating systems actually provide, where that support stops, and how to verify and enforce it.

Do Windows 11 and macOS support hybrid ML-KEM key exchange natively?

Yes, both platforms now ship ML-KEM cryptography. But support at the cryptographic library level is not the same as every protocol on the machine using it. On Windows the starting point is the platform’s crypto APIs. On current macOS releases it is the system TLS stack.

The algorithm underneath is the same on both. In August 2024 the U.S. Secretary of Commerce approved three Federal Information Processing Standards for post-quantum cryptography, including FIPS 203: ML-KEM. For Windows, NIST’s National Cybersecurity Center of Excellence notes that post-quantum cryptography APIs have been made generally available on Microsoft platforms. Having the APIs available means applications and system components can use ML-KEM. It does not mean that every TLS, IKEv2 or RDP session already negotiates it.

On macOS, Apple turned on hybrid post-quantum key exchange in its system networking TLS stack starting with the 2025 OS generation (macOS 26). Apps that use the system networking frameworks get it without any code changes. Apps that bring their own TLS library do not. Check Apple’s platform security documentation for the exact frameworks and versions in your fleet. Don’t assume coverage based on the OS version alone.

Why the standards status changed in 2026

Until recently, hybrid groups were Internet-Drafts. In its 2025 guidelines, NCSC-NL still noted that these algorithms are relatively new and are not yet part of the TLS standards. That changed in August 2026, when RFC 10024 was published as a Standards Track document, defining three hybrid key agreement mechanisms for TLS 1.3 (X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024). According to its authors, the aim of the hybrid approach is to “provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols” (Kwiatkowski, Kampanakis, Westerbaan and Stebila, RFC 10024).

Which TLS groups do Windows and macOS offer by default, such as X25519MLKEM768?

Where hybrid support is turned on, the group offered first is X25519MLKEM768, the hybrid listed as Recommended in the IANA TLS Supported Groups registry. Classical groups such as X25519 and secp256r1 stay in the list as a fallback, so a default client is hybrid-preferring, not hybrid-only.

TLS 1.3, now specified in RFC 9846, negotiates these groups through two extensions. ML-KEM key establishment is defined via the existing supported_groups Section 4.3.7 of [RFC9846] and key_share Section 4.3.8 of [RFC9846] extensions. The registry entries come from RFC 10024:

Statistic (RFC 10024, August 2026): with X25519MLKEM768, the size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519).

Statistic (RFC 10024, August 2026): the size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).

NCSC-NL notes that these hybrids, and “X25519MLKEM768 in particular, are increasingly used on the internet and supported by TLS libraries” (NCSC-NL TLS Security Guidelines 2025-05). The agency rates all three hybrid groups as “good” and plain ECDHE as only “sufficient”.

Does built-in operating system ML-KEM support make a remote access VPN client quantum safe?

No, not by itself. OS support protects only the sessions that go through the OS’s own TLS or crypto stack. A VPN tunnel is quantum safe only if its own key exchange negotiates a post-quantum or hybrid secret with the gateway.

There are three common gaps on remote access paths:

• The tunnel protocol is not TLS. Built-in IKEv2/IPsec clients and many third-party clients run their own key exchange. Hybrid support in TLS 1.3 tells you nothing about IKEv2. RFC 10024 itself warns that its security analysis relies crucially on the TLS 1.3 message transcript, and one cannot assume a similar hybridization is secure in other protocols.
• The client bundles its own crypto library. Many VPN clients link their own TLS implementation and ignore OS settings completely.
• The gateway does not accept the group. A client offering X25519MLKEM768 falls back to classical X25519 if the concentrator only knows classical groups.

One way to avoid depending on the endpoint’s TLS stack is to encrypt the remote access path at the network layer with a dedicated client. Quantum Network’s QPN takes this approach: its software client for current Windows and macOS uses a hybrid key agreement in which ML-KEM (FIPS 203) is combined with a classical exchange into one session key, renewed every two minutes. The client needs no incoming firewall ports. Because encryption happens at Layer 3, applications above it travel inside the tunnel no matter which TLS groups they negotiate themselves.

How can administrators enforce post-quantum key exchange on managed Windows and macOS endpoints?

The reliable place to enforce this is the gateway, not the endpoint. Configure the server side to accept only hybrid groups, then use endpoint management to make sure every client is able to offer them.

Step 1: measure before you enforce

Turn on handshake logging on the remote access gateway and record the negotiated group or key exchange method for each session. That gives you a real inventory: which users, OS builds and client versions already negotiate X25519MLKEM768, and which fall back to classical groups. NIST’s NCCoE describes a cryptographic inventory as the way to identify where and how cryptography is being used so that cryptographic risks can be managed, policies can be applied consistently.

Step 2: control the endpoint baseline

• Minimum OS versions: use your MDM or Intune-style compliance policies to block remote access from Windows and macOS builds that come before hybrid support.
• Client versions: pin the VPN client to a release that implements a hybrid key exchange, and block older installers.
• Windows TLS group order: on Windows, the TLS curve order can be managed through Group Policy (SSL Configuration Settings) and the TLS PowerShell cmdlets. Check on your specific build whether hybrid groups appear in that list before relying on it.
• macOS: configuration profiles control networking and VPN payloads, but individual TLS groups for system frameworks are mostly vendor-controlled. Enforcing at the server side matters more here.

Step 3: require hybrid at the gateway

Once the logs show near-complete hybrid negotiation, remove classical-only groups from the gateway’s accepted list. Prefer X25519MLKEM768 unless a validation requirement points to SecP256r1MLKEM768. RFC 10024 explains that for X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret, so the ML-KEM part comes first in the key derivation.

Timing is guided by NIST IR 8547, which sets a transition timeline for quantum-vulnerable algorithms. A paper presented at NIST’s KEM workshop sums up the impact as the 2030 deprecation date for ECC, and expects most industries to adopt hybrids.

What happens when an older Windows or macOS client connects to a gateway that requires hybrid ML-KEM?

If the client offers no hybrid group, the TLS 1.3 handshake fails and the user cannot connect. There is no silent downgrade when the gateway is configured as hybrid-only. That is the intended security outcome, but it becomes a support issue if you skip the measurement phase.

The last row matters for clients that were early adopters. RFC 10024 records that experimental code points for pre-standard versions of Kyber768 were added to the registry as X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498), and the document obsoletes these entries.

Watch the network path too

Larger handshakes can break older middleboxes. An IETF draft notes that large client key shares are known to cause interoperability problems with non-compliant or buggy legacy TLS implementations, as well as with middleboxes. This is common on OT networks, where old inspection devices and small MTUs on cellular or satellite backhaul still exist. Performance costs are modest on good links.

Statistic (NIST Fifth PQC Standardization Conference, 2024): the time-to-last-byte increase stays below 5% for high-bandwidth, stable networks. Test lossy field links separately before switching to hybrid-only.

What does this mean for OT and critical infrastructure remote access?

Think of OS-level ML-KEM as a useful baseline for browsers and management tools, not as the control that protects remote engineering sessions into plants and substations. Make sure the tunnel itself negotiates a hybrid key exchange, prove that with gateway logs, and enforce it only once every client can comply.

In practice, keep a short list per remote access path: which protocol sets up the tunnel, which crypto library it uses, which key exchange the gateway logs, and which certificate algorithm authenticates the session. Paths where any answer is “classical” or “unknown” are where harvest-now, decrypt-later exposure remains. Review that list again whenever Windows or macOS feature updates change the default TLS behaviour.