Microsoft’s July 14, 2026 security updates make hybrid post-quantum TLS key exchange available in the production Windows Schannel stack, giving Windows 11 and Windows Server 2025 administrators three configurable ML-KEM groups. The capability is disabled by default, works only with TLS 1.3, and requires both ends of a connection to support a compatible group.
The production rollout reaches Windows 11 versions 24H2 and 25H2 through KB5101650, which installs OS builds 26100.8875 and 26200.8875. Windows 11 version 26H1 receives KB5101649, while Windows Server 2025 receives KB5099536, build 26100.33158. Microsoft’s support documentation confirms that the Server update adds hybrid post-quantum key exchange to TLS 1.3, alongside composite cryptographic formats combining conventional and post-quantum algorithms.
As detailed by Microsoft’s Security blog and highlighted by Tech Times, the important change is not simply that Windows can perform ML-KEM operations. Microsoft already made post-quantum primitives available through Windows cryptography APIs in late 2025. Schannel can now negotiate them during real TLS handshakes for applications and services that use Windows’ native TLS provider.
Schannel is the Windows Security Support Provider responsible for SSL and TLS in operating-system components and applications built on interfaces such as WinHTTP and WinINet. Adding ML-KEM here allows compatible software to inherit post-quantum key exchange without each developer implementing a separate cryptographic library.
That does not mean every Windows browser or network application automatically uses the feature. Applications that ship their own TLS stack can make independent choices about supported groups, negotiation order and rollout timing. Administrators therefore need to identify which workloads actually use Schannel rather than assuming that enabling a Windows policy will transform every encrypted connection on a machine.
Microsoft currently exposes three hybrid groups:
ML-KEM is the standardized successor to CRYSTALS-Kyber and is defined by NIST in FIPS 203. Its security is based on lattice problems rather than the integer factorization and discrete-logarithm problems underlying RSA and elliptic-curve cryptography, which are vulnerable in principle to sufficiently capable quantum computers running Shor’s algorithm.
Microsoft’s supported-groups documentation lists all three ML-KEM combinations as TLS 1.3-only and not enabled in the default Schannel priority order. The existing defaults remain
For administrators, the relevant July package on Windows 11 24H2 and 25H2 is therefore KB5101650, not KB5089573. Devices that skipped the optional May and June previews receive their accumulated changes through July’s mandatory security release.
Installing the current cumulative update supplies the Schannel implementation but does not insert the hybrid groups into the active negotiation order. Microsoft provides two documented configuration routes: the ECC Curve Order Group Policy setting and the Windows TLS PowerShell cmdlets. The Group Policy path remains under Computer Configuration, Administrative Templates, Network, and SSL Configuration Settings, even though Microsoft now describes the values more broadly as “Supported Groups.”
That deliberate opt-in gives enterprise teams room to test several consequences before enabling the groups widely. Hybrid handshakes carry larger keys and ciphertexts than conventional X25519 or P-256 exchanges, increasing the amount of data sent during connection establishment. The computational cost is generally manageable on modern systems, but larger handshake messages can expose assumptions in proxies, inspection products, load balancers and older TLS implementations.
A sensible deployment starts with controlled client and server populations, packet captures and Schannel event logging. Teams should verify that the intended hybrid group was negotiated rather than merely confirming that the connection succeeded. A successful TLS connection may have fallen back to a conventional group because the peer did not advertise ML-KEM support.
That makes TLS modernization the first practical step in many environments. Administrators need to inventory servers, reverse proxies, VPN products, inspection appliances, management agents and internally developed applications that still depend on TLS 1.2. The Windows policy alone cannot upgrade the protocol selected by an incompatible peer.
Legacy interoperability also complicates enforcement. Leaving conventional groups in the configured list allows connections to older systems to continue, but it also means those sessions receive no ML-KEM protection. Removing conventional groups too quickly could instead break access to services that have not been upgraded.
Security teams will consequently need to distinguish three states that can otherwise look identical to users: hybrid TLS 1.3, conventional TLS 1.3 and TLS 1.2. Only the first addresses the post-quantum key-exchange objective delivered by this Windows change.
The motivation is the harvest now, decrypt later threat model. An adversary can retain encrypted traffic captured today and attempt to decrypt it years later if cryptographically relevant quantum hardware becomes available. Data with a long confidentiality lifetime—government communications, health information, legal records and valuable intellectual property—is therefore the priority for migration even though no public quantum computer can currently break production RSA or elliptic-curve keys.
ML-DSA, standardized in FIPS 204, handles digital signatures rather than session-key establishment. It addresses a different part of the cryptographic estate, including certificate authorities and certificate-based authentication, while ML-KEM protects the agreement used to create encryption keys.
These migrations should not be treated as interchangeable. Enabling an ML-KEM TLS group does not replace an organization’s RSA or ECDSA certificate hierarchy, and deploying ML-DSA certificates does not automatically make TLS sessions resistant to future quantum decryption. Administrators must track key establishment, authentication and signing as separate workstreams.
For most Windows shops, July’s release is best viewed as the start of a deployment phase rather than the completion of one. Patch Windows 11 and Windows Server 2025, confirm TLS 1.3 coverage, identify Schannel-dependent workloads, enable the hybrid groups in a test policy, and verify the negotiated handshake before expanding the scope.
Microsoft has now put post-quantum key exchange inside the Windows protocol stack. The remaining obstacle is no longer access to an ML-KEM implementation, but whether each organization can modernize its TLS estate without mistaking an installed update for an active defense.
The production rollout reaches Windows 11 versions 24H2 and 25H2 through KB5101650, which installs OS builds 26100.8875 and 26200.8875. Windows 11 version 26H1 receives KB5101649, while Windows Server 2025 receives KB5099536, build 26100.33158. Microsoft’s support documentation confirms that the Server update adds hybrid post-quantum key exchange to TLS 1.3, alongside composite cryptographic formats combining conventional and post-quantum algorithms.
As detailed by Microsoft’s Security blog and highlighted by Tech Times, the important change is not simply that Windows can perform ML-KEM operations. Microsoft already made post-quantum primitives available through Windows cryptography APIs in late 2025. Schannel can now negotiate them during real TLS handshakes for applications and services that use Windows’ native TLS provider.
Schannel Turns an Algorithm Into Deployable Infrastructure
Schannel is the Windows Security Support Provider responsible for SSL and TLS in operating-system components and applications built on interfaces such as WinHTTP and WinINet. Adding ML-KEM here allows compatible software to inherit post-quantum key exchange without each developer implementing a separate cryptographic library.That does not mean every Windows browser or network application automatically uses the feature. Applications that ship their own TLS stack can make independent choices about supported groups, negotiation order and rollout timing. Administrators therefore need to identify which workloads actually use Schannel rather than assuming that enabling a Windows policy will transform every encrypted connection on a machine.
Microsoft currently exposes three hybrid groups:
x25519_mlkem768combines X25519 with ML-KEM-768.secp256r1_mlkem768combines NIST P-256 with ML-KEM-768.secp384r1_mlkem1024combines NIST P-384 with ML-KEM-1024.
ML-KEM is the standardized successor to CRYSTALS-Kyber and is defined by NIST in FIPS 203. Its security is based on lattice problems rather than the integer factorization and discrete-logarithm problems underlying RSA and elliptic-curve cryptography, which are vulnerable in principle to sufficiently capable quantum computers running Shor’s algorithm.
Microsoft’s supported-groups documentation lists all three ML-KEM combinations as TLS 1.3-only and not enabled in the default Schannel priority order. The existing defaults remain
curve25519, nistP256 and nistP384.July’s Patch Is the Delivery Vehicle, Not the On Switch
The update chronology is more complicated than the headline suggests. Microsoft exposed the client capability in earlier 2026 preview builds, including the May 26 KB5089573 preview for Windows 11 24H2 and 25H2. The July 14 cumulative security update supersedes those previews and brings the underlying changes to normally serviced production machines.For administrators, the relevant July package on Windows 11 24H2 and 25H2 is therefore KB5101650, not KB5089573. Devices that skipped the optional May and June previews receive their accumulated changes through July’s mandatory security release.
Installing the current cumulative update supplies the Schannel implementation but does not insert the hybrid groups into the active negotiation order. Microsoft provides two documented configuration routes: the ECC Curve Order Group Policy setting and the Windows TLS PowerShell cmdlets. The Group Policy path remains under Computer Configuration, Administrative Templates, Network, and SSL Configuration Settings, even though Microsoft now describes the values more broadly as “Supported Groups.”
That deliberate opt-in gives enterprise teams room to test several consequences before enabling the groups widely. Hybrid handshakes carry larger keys and ciphertexts than conventional X25519 or P-256 exchanges, increasing the amount of data sent during connection establishment. The computational cost is generally manageable on modern systems, but larger handshake messages can expose assumptions in proxies, inspection products, load balancers and older TLS implementations.
A sensible deployment starts with controlled client and server populations, packet captures and Schannel event logging. Teams should verify that the intended hybrid group was negotiated rather than merely confirming that the connection succeeded. A successful TLS connection may have fallen back to a conventional group because the peer did not advertise ML-KEM support.
TLS 1.2 Becomes the Immediate Blocker
The most consequential limitation is absolute: these groups do not operate over TLS 1.2. An organization can install every July update and correctly configure the supported-group order, yet gain no post-quantum protection on sessions that continue to negotiate TLS 1.2.That makes TLS modernization the first practical step in many environments. Administrators need to inventory servers, reverse proxies, VPN products, inspection appliances, management agents and internally developed applications that still depend on TLS 1.2. The Windows policy alone cannot upgrade the protocol selected by an incompatible peer.
Legacy interoperability also complicates enforcement. Leaving conventional groups in the configured list allows connections to older systems to continue, but it also means those sessions receive no ML-KEM protection. Removing conventional groups too quickly could instead break access to services that have not been upgraded.
Security teams will consequently need to distinguish three states that can otherwise look identical to users: hybrid TLS 1.3, conventional TLS 1.3 and TLS 1.2. Only the first addresses the post-quantum key-exchange objective delivered by this Windows change.
The motivation is the harvest now, decrypt later threat model. An adversary can retain encrypted traffic captured today and attempt to decrypt it years later if cryptographically relevant quantum hardware becomes available. Data with a long confidentiality lifetime—government communications, health information, legal records and valuable intellectual property—is therefore the priority for migration even though no public quantum computer can currently break production RSA or elliptic-curve keys.
Windows PKI Is Moving on a Separate Track
Microsoft is also extending post-quantum support beyond TLS key establishment. Its June security announcement said Active Directory Certificate Services support for issuing ML-DSA certificates on Windows Server 2025 became generally available in May 2026.ML-DSA, standardized in FIPS 204, handles digital signatures rather than session-key establishment. It addresses a different part of the cryptographic estate, including certificate authorities and certificate-based authentication, while ML-KEM protects the agreement used to create encryption keys.
These migrations should not be treated as interchangeable. Enabling an ML-KEM TLS group does not replace an organization’s RSA or ECDSA certificate hierarchy, and deploying ML-DSA certificates does not automatically make TLS sessions resistant to future quantum decryption. Administrators must track key establishment, authentication and signing as separate workstreams.
For most Windows shops, July’s release is best viewed as the start of a deployment phase rather than the completion of one. Patch Windows 11 and Windows Server 2025, confirm TLS 1.3 coverage, identify Schannel-dependent workloads, enable the hybrid groups in a test policy, and verify the negotiated handshake before expanding the scope.
Microsoft has now put post-quantum key exchange inside the Windows protocol stack. The remaining obstacle is no longer access to an ML-KEM implementation, but whether each organization can modernize its TLS estate without mistaking an installed update for an active defense.
References
- Primary source: Tech Times
Published: 2026-07-15T13:48:12+00:00
Post-Quantum Cryptography Comes to Windows TLS: Three ML-KEM Groups Now Configurable
Post-quantum cryptography comes to Windows TLS with Microsoft’s July 14 Patch Tuesday update, which ships three ML-KEM hybrid key-exchange groups into Schannel for Windows 11 and Windows Server 2025 — enabling quantum-resistant connections for the first time at the OS protocol layer. Configuration
www.techtimes.com
- Official source: learn.microsoft.com
TLS Supported Groups in Windows 11 versions 24H2, Windows Server 2025, and later - Win32 apps | Microsoft Learn
Supported groups enabled in Windows 11 versions 24H2 and later.learn.microsoft.com - Official source: techcommunity.microsoft.com
