Microsoft’s July 14, 2026 security update shipped hybrid post-quantum key exchange directly into the Windows TLS stack for the first time. Three new cryptographic groups make Windows 11 and Windows Server 2025 capable of establishing quantum-resistant connections—but none of them are enabled by default, and every session that still negotiates TLS 1.2 receives no protection from this patch.

The Delivery: KB5101650 and What It Installed

The capability lands via the July cumulative update. Windows 11 versions 24H2 and 25H2 receive KB5101650, which bumps OS builds to 26100.8875 and 26200.8875 respectively. Windows 11 version 26H1 gets KB5101649, while Windows Server 2025 gets KB5099536 (build 26100.33158). These updates supersede earlier May and June preview builds (like KB5089573 for 24H2/25H2) that had already exposed the client-side capability to early testers.

The update adds three hybrid key-exchange groups to Schannel, the Windows Security Support Provider that handles SSL/TLS for most system components and applications built on WinHTTP, WinINet, or the .NET networking stack. The groups are:

  • x25519_mlkem768 – X25519 paired with ML-KEM-768 (NIST security level 3)
  • secp256r1_mlkem768 – NIST P-256 paired with ML-KEM-768
  • secp384r1_mlkem1024 – NIST P-384 paired with ML-KEM-1024 (NIST security level 5, aligned with NSA CNSA 2.0)

These are hybrid exchanges: a classical elliptic-curve agreement runs alongside a post-quantum key-encapsulation mechanism (ML-KEM, standardized in FIPS 203, the successor to CRYSTALS-Kyber). If either algorithm survives a future quantum attack, the session remains secure. But the hybrid handshake is available only under TLS 1.3—there is no route to quantum resistance on a TLS 1.2 connection, no matter how carefully you configure the group order.

What It Means for You

Home Users

If you use a personal Windows 11 PC for web browsing, email, and streaming, the July patch alone changes nothing for your everyday security. Browsers like Chrome and Edge bring their own TLS stacks and have their own post-quantum roadmaps; enabling Schannel groups won’t affect them. Microsoft still defaults to classical curve25519, nistP256, and nistP384, so your device will keep negotiating connections exactly as before unless you—or a group policy pushed by your organization—explicitly enable the new groups. For now, no action is required, and none of your current connections have been broken.

If you self-host a service on a Windows machine (a game server, a personal website, a remote-desktop gateway), this update matters more. You can choose to activate the hybrid groups on your server, but only after confirming that your clients support TLS 1.3 and are capable of negotiating one of the listed groups. Many home‑router VPNs and older appliances still use TLS 1.2, so enabling the groups without testing could cause handshake failures or silent fallback to classical security.

IT Administrators and Security Teams

The real lift falls on you. Installing KB5101650 (or the equivalent update for your OS) gives Windows the code it needs; activating it is a separate configuration exercise. Microsoft provides two management paths:

  1. Group Policy – Under Computer Configuration \ Administrative Templates \ Network \ SSL Configuration Settings, the “ECC Curve Order” setting now lists the three ML-KEM hybrid groups alongside the existing curves. Move the desired groups into the preferred order.
  2. PowerShell – Use the Enable-TlsEccCurve, Disable-TlsEccCurve, and related cmdlets from the TLS module to script the preferred list.

You must also audit your fleet for TLS 1.3 readiness. Every server, reverse proxy, load balancer, inspection appliance, VPN endpoint, and internal application that terminates TLS will need to support TLS 1.3 before the new groups can be negotiated. Running a packet capture and examining the supported_versions extension in ClientHello messages is a good first step. Microsoft’s documentation emphasizes that x25519_mlkem768 is the recommended choice for most enterprise and web workloads, with secp384r1_mlkem1024 reserved for environments that must meet CNSA 2.0 requirements.

Once enabled, connections will use the hybrid group only if both ends support it; otherwise, they will silently fall back to a classical curve. That soft‑landing design avoids breaking interoperability, but it also means you need to verify that negotiated sessions actually selected the hybrid group. Schannel event logging (event IDs 36880/36881) can help confirm that the handshake used ML-KEM. Organizations should test with a controlled set of clients and servers, monitor for performance regressions (the ML-KEM‑768 public key and ciphertext are roughly 1.2 KB each, adding about 2.3 KB to the handshake), and expand gradually.

Don’t overlook certificates. The hybrid key exchange protects the session key, but your existing RSA or ECDSA server certificates remain vulnerable to future quantum forgery. Microsoft has separate workstreams for that: Active Directory Certificate Services support for ML-DSA certificates reached general availability on Windows Server 2025 in May 2026. Those signature algorithms handle authentication and code signing. Plan to run a parallel certificate authority before migrating to post‑quantum certificates; in‑place upgrades aren’t supported.

Developers

If your application uses Windows’ built‑in TLS (via WinHTTP, WinINet, .NET’s SslStream with Schannel, or the SCHANNEL_CRED API), the new groups become available once the system is configured by an administrator. Your code doesn’t need to change—Schannel handles the negotiation. If you ship your own TLS library (OpenSSL, BoringSSL, SChannel‑replacement stacks), you’ll need to follow your library’s own post‑quantum roadmap and implement ML-KEM support independently. The Windows Schannel update doesn’t reach those connections.

How We Got Here

The update is the culmination of a three‑year march driven by the “harvest now, decrypt later” threat. Adversaries can archive encrypted traffic today and wait for a cryptographically relevant quantum computer to break the key exchange that protects it. Data with long confidentiality lifespans—government communications, medical records, financial contracts—is already at risk under purely classical encryption.

Microsoft first made ML-KEM available as a cryptographic API primitive in November 2025, allowing developers to experiment. The July Schannel release shifts the capability from the developer’s toolkit to the protocol layer, where actual network traffic runs. The move aligns with regulatory pressure: the NSA’s CNSA 2.0 mandates post‑quantum algorithms for national security systems by 2027, a June 2026 federal executive order sets deadlines of 2030 for key establishment and 2031 for digital signatures on high‑value civilian systems, and NIST’s IR 8547 deprecates RSA‑2048 and ECC P‑256 for all new federal systems after 2030, disallowing them entirely in 2035. Microsoft’s own internal goal targets practical post‑quantum readiness across its ecosystem by 2029.

What to Do Now

  1. Patch immediately. All supported Windows 11 and Windows Server 2025 devices should receive the July 2026 cumulative update through normal Windows Update channels. Confirm the relevant KB is installed.
  2. Inventory your TLS 1.3 status. Use network scanners or Schannel logs to identify servers and applications still relying on TLS 1.2. Prioritize migration for any service that handles sensitive, long‑lived data.
  3. Design a pilot. Choose a small set of Schannel‑reliant clients and servers, enable the preferred hybrid group (e.g., x25519_mlkem768) via Group Policy or PowerShell, and capture handshake traces to verify that the hybrid group is actually negotiated.
  4. Monitor for breakage. Some middleboxes, firewalls, or older TLS implementations may trip over the larger handshake messages. Plan a rollback path (simply remove the ML-KEM groups from the preferred order) until the root cause is addressed.
  5. Document your configuration. Both the group list and the TLS version requirement need to be part of your security baseline so that future audits can confirm which sessions truly gained quantum-resistant protection.
  6. Start the certificate conversation. Even if you aren’t ready to deploy ML-DSA today, understand that hybrid key exchange alone does not secure long‑lived authentication. Begin planning for a parallel certificate authority infrastructure.

Outlook

Microsoft has moved post‑quantum cryptography from a research topic to a production service inside Windows. The next milestone will likely be a default‑enabled state, perhaps in an upcoming Windows 11 feature release, once the ecosystem has enough TLS 1.3 coverage and the performance profile of the hybrid handshake is better understood. The larger challenge—the one that no single OS update can solve—remains the sprawling inventory of TLS 1.2 endpoints that keep coming back online every morning. Every week that passes before those systems are upgraded is another week that harvest‑now‑decrypt‑later attackers can add to their archives. The July patch gives you the tool; the timeline for actually deploying it is up to you.