Turning On Hybrid Post-Quantum Key Exchange in Schannel

Windows can now protect TLS connections with a post-quantum key exchange, but it will not do so on its own. Schannel, the component that carries out Transport Layer Security (TLS) for Windows and every program built on it, supports hybrid groups that pair an elliptic-curve exchange of the familiar kind with ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism standardised by NIST, and Microsoft ships them switched off. Turning them on is one command or one policy setting. Turning them on well is a small engineering project: knowing which connections can benefit at all, choosing a group and its position in the list, proving from outside that the group was actually negotiated, rolling out in rings with a way back, and being honest about what the change leaves exactly as it was.

What general availability changed, and what it did not

On 14 July 2026, a Microsoft Tech Community post on the post-quantum cryptography blog announced that Schannel is generally available with post-quantum support, with hybrid TLS using ML-KEM key exchange groups available in Windows 11 and Windows Server 2025. The same post is careful about the default: the post-quantum groups are not enabled, so administrators must set them up. Microsoft's reference page for TLS supported groups says the same thing in table form, and it records a small renaming that matters when reading documentation and tools: Microsoft now says supported groups where older pages, cmdlets and policy names still say elliptic curves, since ML-KEM is not a curve at all.

That reference lists the groups Schannel enables by default, in order: curve25519, then the NIST curves P-256 and P-384. It lists six post-quantum groups that are supported but disabled: three hybrids, x25519_mlkem768, secp256r1_mlkem768 and secp384r1_mlkem1024, and three pure ML-KEM groups, mlkem512, mlkem768 and mlkem1024. Every one of the six is marked as TLS 1.3 only. The page also gives minimum builds, for example 26100.8514 for Windows 11 versions 24H2 and 25H2, so the first fact to check on any host is its build.

What did not change is everything outside key exchange. The Tech Community post states that in its walkthrough the key exchange used post-quantum cryptography while server authentication still used a classical certificate, by design for now, because recorded traffic decrypted later is the more urgent risk and certificate migration is a separate, slower ecosystem change.

First measure which connections can benefit

A hybrid group can only be negotiated in TLS 1.3. Microsoft's post is blunt that versions before TLS 1.3 have no post-quantum key exchange today and are not going to gain one. So before enabling anything, the useful number is the share of a host's Schannel connections that already use TLS 1.3, and the useful list is the peers that do not. Schannel's success event, 36880, records the protocol version of each completed handshake when success logging is enabled, which makes a short sampling window enough to answer the question per host and per peer.

Two further filters narrow the benefit. The peer must also support a hybrid group, which is common among large web services and modern TLS libraries but far from universal on internal systems. And the program must not have pinned its own TLS settings. Microsoft's post calls code that hard-codes protocol versions and cipher suites an anti-pattern that will not necessarily negotiate a post-quantum connection, and notes that in .NET the CipherSuitesPolicy type is not supported on Windows at all, because suites there are governed by the operating system. The encouraging corollary is that a server written without TLS assertions, such as the minimal Kestrel example in that post, picks up the hybrid group from Schannel with no code change.

Choosing the group and its position

For most estates the natural first choice is x25519_mlkem768, the hybrid of curve25519 with ML-KEM-768. It is the group that Microsoft's walkthrough enables, and the same group that OpenSSL 3.5 and current browsers prefer, so it is the one most peers will recognise. The NIST-curve hybrids, secp256r1_mlkem768 and secp384r1_mlkem1024, exist for environments whose policy requires NIST curves. The pure ML-KEM groups drop the classical half entirely; that is a separate decision about trusting ML-KEM alone, not a default. Microsoft's table marks none of the six as available in the legacy FIPS mode, and its page adds that the legacy FIPS mode setting is no longer recommended nor required for FIPS approval.

Position matters twice. As a client, Schannel offers its groups in order and, as Microsoft's post explains, pre-computes a key share only for its top choice; the fallback groups are listed but not pre-computed, so if a server accepts only one of the fallbacks, the server must ask for it in a HelloRetryRequest and the handshake costs an extra round trip. A hybrid group at position 0 therefore gives the best result with peers that support it and a small latency cost with peers that do not. As a server, the TLS 1.3 standard, RFC 8446, leaves the choice to the server, and most servers walk their own preference list; Schannel's order decides what it picks from what the client offered. That is why the post singles out the position argument as important: without it, the hybrid may be enabled but rarely chosen. The hybrid's client key share is also larger, 1,216 bytes (a 32-byte X25519 key plus a 1,184-byte ML-KEM-768 key), which is why a test ring should watch for network devices that mishandle a larger first message. Schannel itself has room for it: its documented default limit for handshake messages a server accepts without client authentication is 0x4000 bytes, far above the size of a hybrid first message.

The asymmetry also suggests an order. Enabling the hybrid on a server costs nothing for clients that do not offer it: the server simply picks a classical group from what they sent. Enabling it at the top of a client's list, by contrast, adds a retry with every server that lacks it. Servers first, then clients, lets each client ring arrive at a population of servers that can already answer in one round trip, and it puts the latency cost, if any, where it can be measured on a small number of hosts.

Three levers, one source of truth

Microsoft describes three ways to configure Schannel, the registry, Group Policy and PowerShell cmdlets, and notes that all of them ultimately update the registry. For groups, the practical levers are two. The TLS PowerShell module's Enable-TlsEccCurve adds a group to the local list; its Position parameter inserts the group ahead of existing entries, with 0 meaning the top. Get-TlsEccCurve reads the list back, and Disable-TlsEccCurve removes a group. In Microsoft's walkthrough, enabling X25519_MLKEM768 at position 0 produced the list x25519_mlkem768, curve25519, NistP256, NistP384.

For managed machines the lever is policy. Group Policy's ECC Curve Order setting, under Computer Configuration, Administrative Templates, Network, SSL Configuration Settings, takes the priority list of all groups you want enabled, and Microsoft's TLS management guidance says new curve priority lists become active on the next reboot. Mobile Device Management offers the same control through the ConfigureEllipticCurveCryptography policy on Windows 11 version 24H2 and later, which maps to the same Group Policy setting. The consequence of a list-based policy is easy to miss: anything not in the list is off, so the policy must name the classical groups as well as the hybrid, or every peer without hybrid support will fail. On a policy-managed machine, a cmdlet change is a lab convenience, not the source of truth.

Knowing which lever owns a host is therefore the first step of any change. Microsoft's device management reference names the registry location that the policy setting writes, HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002, so a read-only look at that key tells you whether a policy list exists before anyone runs a cmdlet. If it does, the change belongs in the policy, with its reboot, and the policy's list must be reviewed in full, because it may also carry an older cipher suite order written years ago for another reason.

Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0
Get-TlsEccCurve
# rollback on the same host
Disable-TlsEccCurve -Name "X25519_MLKEM768"

Proving it from the other side

A setting read back from the machine proves that the setting exists, not that any connection used it. The proof has to come from a peer that can report which group was negotiated. For a Schannel server, Microsoft's post shows two such peers: a browser's developer tools, whose Security panel showed TLS 1.3 with X25519MLKEM768, and OpenSSL's s_client with the -tls1_3 and -brief options, which prints a line such as "Negotiated TLS1.3 group: X25519MLKEM768". OpenSSL 3.5 or later is needed, since that release added ML-KEM.

For a Schannel client, turn the test around: point it at a test server that accepts nothing but the hybrid group. If the client connects, it offered the hybrid. If it does not, it did not. In October 2026, with Schannel's default groups on Windows 11 version 26H2, Windows curl.exe (which uses Schannel) against an OpenSSL 3.5.9 test server limited to X25519MLKEM768 failed with SEC_E_ILLEGAL_MESSAGE and a received alert 40, logged as event 36887, while OpenSSL's own client connected to the same server and reported X25519MLKEM768. That failure is the expected baseline before the change and the success is the expected result after it, which makes a hybrid-only test endpoint a simple, repeatable probe for every client ring.

It is tempting to look for the group in Schannel's own success event, but in the October 2026 inspection, event 36880 recorded the protocol, cipher suite, an exchange strength and certificate names, with no field naming the group. Verify from the peer rather than inferring from that event.

# Schannel server: which group did it pick?
openssl s_client -connect server.example:443 -servername server.example -tls1_3 -brief
# Schannel client: a test server that accepts only the hybrid group
openssl s_server -accept 8443 -cert cert.pem -key key.pem -tls1_3 -groups X25519MLKEM768 -www

Rings, watch signals and the way back

Roll the change out the way any protocol change should go. Begin with a lab pair, a Schannel client and server you control, and confirm both directions with the probes above. Move to a canary ring of real hosts that includes at least one host running automated or AI agent workloads, enabled with the cmdlet so that rollback needs no reboot. Watch three signals: new fatal alert events (36887 and 36888) against peers that previously worked; connection latency, since a hybrid at the top of a client's list costs a round trip with every peer that lacks it; and failures that cluster behind particular network devices, the classic sign of equipment that mishandles a larger first message. The success measure is the share of TLS 1.3 connections that report the hybrid group rising without new failures.

The broad ring then moves through Group Policy or device management, with a full group list and a reboot plan. Rollback depends on the lever. On a cmdlet-managed host, Disable-TlsEccCurve removes the group. On a policy-managed host, the hybrid is removed from the policy list, which, like the original change, takes effect after the next reboot. Either way, record the previous list before changing it, and repeat the same probe after rolling back, because a rollback is a change too.

What stays classical after the switch

Enabling a hybrid group is a real improvement with clear edges, and stating those edges is part of doing it honestly. A practitioner reporting "post-quantum TLS enabled" should be able to say exactly which of these still apply on that host.

• Certificates and signatures: server and client authentication still use classical certificates, by design for now.
• TLS 1.2 and older: they cannot negotiate a post-quantum group, so every connection that falls back stays classical.
• Other TLS stacks on the same host: browsers, Python, Java, Node.js and Git's OpenSSL follow their own settings, not Schannel's.
• Traffic already recorded: switching on hybrid key exchange protects future sessions only, not sessions captured earlier.
• Peers without hybrid support: the connection silently uses a classical group, which is correct behaviour but means coverage must be measured, not assumed.

AI agents: hybrid channels without touching agent code

For AI agents on Windows the attraction is direct. An agent host built on .NET, whose HttpClient calls model endpoints and tool servers through Schannel, and a tool server built on Kestrel, both inherit the hybrid group once it is enabled and the peer supports it, with no change to agent code, provided the code does not pin TLS settings. Agent traffic is also among the traffic most worth protecting against later decryption: prompts, retrieved documents and tool results can carry credentials, personal data and business plans whose sensitivity outlives the session.

The same agent may, however, run tools in Python or Node.js, call out through a browser engine, or hand work to a container with its own OpenSSL, and none of those follow Schannel. The practical answer is an inventory per runtime rather than per machine: for each agent, list the stacks its traffic actually uses and verify each one with a probe. Add one review rule to agent code and to coding-assistant suggestions alike: do not hard-code TLS protocol versions, suites or groups, because pinned settings are the one thing that keeps a Schannel-based agent from inheriting the upgrade. For a leader, the decision is a short list: which hosts are on qualifying builds, what share of their traffic is TLS 1.3, which agent runtimes bypass Schannel, and who owns the probe that proves the result.

Glossary

ML-KEM

Module-Lattice-Based Key-Encapsulation Mechanism, the NIST post-quantum standard for establishing a shared secret.

Hybrid group

A TLS key exchange that combines a classical elliptic-curve exchange with ML-KEM, so both must be broken to recover the key.

Supported groups

The TLS parameter, formerly called elliptic curves, that lists the key exchange methods a side is willing to use.

Key share

The public value a TLS 1.3 client sends in its first message for the group it expects the server to choose.

HelloRetryRequest

A TLS 1.3 server reply asking the client to retry with a different group, which costs an extra round trip.

ECC Curve Order

The Group Policy setting that defines the full, ordered list of groups Schannel may use.

Harvest now, decrypt later

Recording encrypted traffic today in the hope of decrypting it once a capable quantum computer exists.

Further reading

1. ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography (Microsoft Tech Community, 14 July 2026)
2. TLS Supported Groups in Windows 11 versions 24H2, Windows Server 2025, and later (Microsoft Learn)
3. Enable-TlsEccCurve (Microsoft Learn)
4. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (IETF)