Windows Adds Post-Quantum TLS: Off by Default
Windows 11 and Server 2025 now support hybrid ML-KEM in Schannel, but only TLS 1.3 connections benefit, and admins must enable it.
Microsoft’s July 14 Patch Tuesday buried its most consequential change in the fine print. Alongside the usual pile of CVE fixes, Windows 11 and Windows Server 2025 quietly picked up hybrid post-quantum key exchange in Schannel, the TLS stack that handles encryption for nearly everything on the OS that isn’t bundling its own crypto library. That’s a bigger deal than it sounds, and also a smaller one than the headlines suggest. Both things are true at once, which is the usual state of PQC news.
What actually shipped
Three hybrid key-exchange groups are now available in Schannel, each pairing a classical elliptic-curve algorithm with NIST’s ML-KEM (FIPS 203): X25519_MLKEM768, SecP256r1_MLKEM768, and SecP384r1_MLKEM1024. The first is Microsoft’s recommended default for most enterprise and web traffic. The last one, pairing P-384 with ML-KEM at security level 5, exists to satisfy NSA’s CNSA 2.0 requirements for national security systems.
You’ll find this in KB5089573 for Windows 11 24H2 and 25H2, KB5095091 for 26H1, and KB5099536 for Windows Server 2025. A separate update, KB5095093, adds composite PQC support to the Windows cryptography APIs and certificate stack, which matters if you’re also touching ADCS. Microsoft got ML-DSA certificate issuance to general availability back in May, so the signing side and the key-exchange side are both live now, just not connected to each other by default.
“Hybrid” here means what it usually means in this space: the client offers both the classical curve and ML-KEM, and an attacker has to break both to read anything. If it talks to a server that doesn’t support ML-KEM yet, the handshake just falls back to the classical component and nobody notices. That’s the right way to ship this, and it’s the same approach Chrome, Cloudflare, and OpenSSH have already taken.
Why Schannel is the part worth paying attention to
Microsoft put ML-KEM into a cryptographic API back in November. Nobody except a handful of developers cared, because an API is only as useful as the number of people who go implement it. Schannel is different. It’s the TLS provider underneath most things that don’t ship their own stack: Windows services, a lot of enterprise software, domain authentication traffic, and any browser that leans on the OS for its crypto instead of carrying something like BoringSSL. Push post-quantum support into Schannel and the upgrade path runs through Windows Update instead of through a thousand separate application backlogs. That’s the actual news here, not the algorithm.
The catch: it’s off, and TLS 1.2 gets nothing
Here’s where the caveats start piling up. None of the three ML-KEM groups are enabled by default. An administrator has to turn them on through Group Policy, Intune, or the TLS PowerShell cmdlets, the same mechanisms already used for ordering elliptic-curve preferences. That’s a reasonable choice. Nobody wants a security default flipped mid-patch-cycle without warning.
The bigger problem is that hybrid key exchange only negotiates over TLS 1.3. If a server or client hasn’t finished moving off TLS 1.2, this update does exactly nothing for it, no matter how carefully you configure the policy. And the organizations most likely to be sitting on harvest-now-decrypt-later risk, banks, hospitals, defense contractors, tend to be exactly the ones with the oldest TLS 1.2 dependencies still wired into some vendor system nobody wants to touch. For a lot of shops, the PQC rollout and the long-overdue TLS 1.3 migration just became the same project, whether IT planned it that way or not.
The size tax, and why it’s bandwidth, not CPU
ML-KEM-768 public keys run 1,184 bytes against X25519’s 32, and the ciphertext adds another 1,088 bytes on top. A hybrid handshake costs roughly 2.27 KB more than a classical-only one. For most web and enterprise traffic that’s noise. For latency-sensitive environments, financial trading systems in particular, it’s measurable: one study clocked connection setup rising from about 24.7ms to 30.4ms, a 23% jump, driven entirely by the extra bytes crossing the wire rather than added computation. ML-KEM is actually faster than X25519 on the CPU side, so whatever budget line you’re worried about, it isn’t compute cycles.
What to actually do with this
If you’re on Windows 11 or Server 2025, go check whether you’re on TLS 1.3 across the board before you bother enabling anything. That’s the blocking dependency, and it’s the boring inventory work nobody wants to do first. Once you’re clear of TLS 1.2, turning on X25519_MLKEM768 is low-risk given the automatic fallback, and it starts closing the harvest-now-decrypt-later window on session traffic today rather than in 2029.
The regulatory backdrop isn’t subtle about the timeline either. NSA wants new national security systems on CNSA 2.0 by 2027. The executive order signed in June sets 2030 and 2031 deadlines for federal civilian systems. Microsoft’s own internal target for getting Windows, Azure, and its PKI fully quantum-safe is 2029. None of those dates require you to do anything today, and all of them require you to have started well before they arrive. A Patch Tuesday update that puts working ML-KEM in front of administrators, disabled but one policy setting away from live, is about as concrete as “start now” gets.