Settings That Decide Every Connection: Protocols, Cipher Suites and Groups on Windows

Every protected connection begins with a few hundredths of a second of negotiation in which two computers agree how they will talk. On a Windows machine, a set of lists kept by the operating system decides what one side is even allowed to put on the table, for every program that relies on the built-in Transport Layer Security (TLS) provider, called Schannel. Those lists are rarely looked at until something breaks: a payment terminal that suddenly cannot connect, a monitoring tool that fails a compliance scan, an AI agent that works on one server and not another. This guide teaches a newcomer to read those lists with read-only commands, explains the three layers that can each shorten them, shows why a long list on the screen does not mean every item is used, and closes with what it means for AI agents whose code may quietly override the machine, or be overridden by it.

Three things every connection has to agree

Imagine two people from different countries meeting to sign a contract. Before they discuss a single clause, they have to settle three things: which language they will speak, which method they will use to seal and check the pages, and how they will privately agree on a code word nobody else can overhear. If they cannot agree on all three, the meeting ends before it starts.

A TLS connection settles the same three questions in its opening moment. The first is the protocol version: which edition of TLS both sides will speak, today usually TLS 1.2 or TLS 1.3. The second is the cipher suite, a named bundle of algorithms that fixes how the conversation will be encrypted and checked for tampering. The third is the group, the mathematical method the two sides use to agree on a fresh shared secret without ever sending it across the network. Older documents call the groups 'elliptic curves', because for many years every group was one; Microsoft has renamed the setting 'supported groups' now that newer, post-quantum methods that are not curves at all have joined the list.

On a Windows machine each of these three answers comes from its own list, kept in its own place and read with its own tool. That separation is the first thing to understand, because people often look at one list and assume they have seen the whole picture. A server can have a modern cipher suite list and still allow an old protocol version, or the other way round.

The separation also explains a common pattern in security reports. A scanner probes a server from outside, notices that it still accepts an old protocol version, and flags it. Someone checks the cipher suite list, finds only modern entries, and closes the finding as a false alarm. Both observations were accurate; they were simply answers to different questions. Reading all three lists, and knowing which one a finding refers to, avoids that kind of crossed wire.

None of this needs any cryptography to follow. Reading the lists is like reading the menu at the door of a restaurant: you do not need to know how each dish is cooked to see what is on offer, in what order it is recommended, and what has been crossed out. The rest of this guide is about reading that menu accurately, and about understanding who is allowed to write on it.

Three layers decide, and the narrowest one wins

Who writes on those lists? Three different layers, and understanding their order removes most of the confusion people meet when a connection behaves unexpectedly.

The first layer is Windows itself. Each release of Windows arrives with a built-in set of protocol versions switched on, a default order of cipher suites and a default order of groups. Microsoft publishes these defaults release by release, so two machines on different Windows versions can start from different lists. Nobody has to do anything for this layer to apply; it is simply what a freshly installed machine does.

The second layer is the machine's policy, set by whoever administers the computer. In a company this is usually Group Policy, the central system that pushes settings to many Windows machines at once, or a device management service. Microsoft documents a Group Policy setting called SSL Cipher Suite Order and another called ECC Curve Order, plus PowerShell commands that can enable or disable individual entries. Protocol versions are controlled through per-version registry values. Whatever this layer sets replaces the Windows defaults: Microsoft's documentation states that when a priority list is configured, cipher suites not in that list will not be used.

The third layer is the application. A program that calls Schannel can pass its own restrictions, for example refusing anything older than TLS 1.2. But Microsoft is explicit about the limit of this power: a program can restrict the set of protocol versions the machine allows, but it cannot expand it. Think of a series of sieves stacked one above another. Windows pours in everything it supports, the machine's policy holds some of it back, the application holds back more, and only what passes through all three can be offered to the other side.

The useful rule of thumb follows directly. The narrowest layer wins, and no lower layer can put back what a higher one removed. If the machine has switched off an old protocol version, no program on it can switch that version back on for itself through Schannel. If a program has restricted itself to one version, a generous machine policy will not loosen it. When a connection fails, the question is therefore never just 'what is the setting?' but 'which of the three sieves held it back?'

Reading the protocol versions

Start with the simplest of the three lists, the protocol versions, because it changes least often and has the clearest history. Microsoft maintains a table showing which versions of TLS each release of Windows supports and switches on by default, separately for the client side of a connection and the server side.

The headline in that table is TLS 1.3. Microsoft states that TLS 1.3 is supported starting with Windows 11 and Windows Server 2022, and the table shows it switched on by default, for both clients and servers, in those releases and in Windows Server 2025. Every version of Windows 10 is listed as not supporting it, and Microsoft adds a blunt warning that enabling TLS 1.3 on earlier versions of Windows is not a safe configuration. So for any program relying on Schannel, the newest protocol is a property of the operating system it happens to run on, not of the program.

At the other end of the table sit TLS 1.0 and 1.1, the oldest versions still found in the wild. In March 2021 the Internet Engineering Task Force (IETF), the body that publishes internet standards, formally deprecated both in RFC 8996, where RFC stands for Request for Comments, the name of its standards documents. Microsoft followed with a staged retirement: starting with Windows 11 and Windows Server preview releases in 2024, both versions are disabled by default, on clients and servers alike, while releases already in the market are left as they were. Microsoft also notes that its Microsoft 365 products and the WinHTTP and WinINet web libraries had already stopped using them, and that the first response to an application that breaks should be to look for a newer version of it.

To see what a particular machine does, the registry is the place to look, and looking changes nothing. Under a key named Protocols inside the Schannel section of the registry, each version can have a Client and a Server subkey containing a value named Enabled, set to 1 for on or 0 for off. The important detail for a reader is what an empty key means: if there is no entry for a version, the machine is simply using the built-in default for its release. On the Windows 11 computer examined for this guide, the Protocols key held a single explicit entry, switching the TLS 1.2 client on; every other version was running on defaults. Reading a machine therefore means combining two sources: the published table for its release, and whatever explicit entries an administrator has added on top.

Reading the cipher suite list

The cipher suite list is longer and looks more intimidating, but Windows includes a command that prints it in order. Get-TlsCipherSuite, part of the TLS module in Windows PowerShell, returns the ordered collection of cipher suites the computer can use for TLS. It only reads; nothing on the machine changes when you run it. Its companion, Get-TlsEccCurve, prints the ordered list of groups. Running both on the Windows 11 computer examined for this guide returned 28 cipher suites and three groups: curve25519, NistP256 and NistP384, which matches the default group order Microsoft publishes for Windows 11 version 24H2 and later.

The order matters. When the computer acts as a client, it offers its suites in this order, and when it acts as a server it uses the order to choose among the client's offers. On the examined machine, as in Microsoft's published default, the first two entries were TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256, the two suites used by TLS 1.3, followed by a long run of suites for TLS 1.2.

The names look like code, but they can be read like a label on a packet once you know where the parts go. A TLS 1.2 suite such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 reads from left to right as: the protocol family, then the way the shared secret is agreed (ECDHE), then the way the server proves who it is (RSA), then the word WITH, then the encryption (AES with a 256-bit key in a mode called GCM), then the hash function used inside the protocol (SHA-384). TLS 1.3 suite names are shorter, because that version moved the secret-agreement choice into the groups list and leaves the identity proof to the server's certificate, so its suite names only describe the encryption and the hash.

You do not need to judge the strength of each algorithm to get value from this. Reading the list tells you three practical things: which suites a Schannel program on this machine can possibly use, which it will prefer, and whether the list has been customised away from the published default. That last check is simple to do by comparing the output with Microsoft's table for the same Windows release, and it often reveals more about a machine's history than any document does.

# Cipher suites, in the order this machine prefers them
Get-TlsCipherSuite | Format-Table Name

# Supported groups (key-agreement methods), in order
Get-TlsEccCurve

# Explicit protocol-version entries (none listed = built-in defaults)
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Recurse

On the list is not the same as will be used

Here is the trap that catches experienced people as well as beginners. It is natural to read the cipher suite list as 'everything this machine will use'. It is not, and Microsoft's own documentation shows why in at least three ways.

First, some entries are listed but only used on request. Microsoft's Windows 11 table includes two suites whose names contain the word NULL, meaning they provide integrity checking without encryption, and marks them 'only used when application explicitly requests'. The same page lists a family of suites based on pre-shared keys, a secret both sides were given in advance, and states that none of them is used unless an application asks for that mode. Both families appeared in the list printed on the examined machine. Seeing them there is not a sign that the machine encrypts nothing; it is a sign that a program would have to go out of its way to use them.

Second, some things are supported but deliberately left off the list. Microsoft's page on supported groups for Windows 11 version 24H2 and later names a set of post-quantum groups based on ML-KEM, the new standard for agreeing secrets in a way designed to resist future quantum computers, plus some older curves, all marked as supported but not enabled by default. They do not appear in Get-TlsEccCurve's output until an administrator adds them. The capability is in the operating system; the list decides whether any connection can use it.

Third, the published default is a starting point, not a promise about any particular machine. Microsoft's table of default cipher suites for Windows 11 includes two suites whose names begin TLS_DHE_RSA. On the Windows 11 machine examined for this guide, neither appeared in the cmdlet's output. Whatever the reason, whether a policy, an update or an earlier change, the lesson is the same: a document tells you what a machine was shipped to do, and the command tells you what this machine is set to do now.

Put together, these three cases give a simple discipline for reading any report about a Windows machine's TLS. For each entry, ask whether it is on the list, whether it is used without a special request, and whether the list itself matches what Microsoft publishes for that release. An entry that is listed but only used on request is not a finding. A capability that is supported but not listed is not available to any connection yet. And a list that differs from the published default is a prompt to find out who changed it and why, which is often the most useful discovery of all.

Enabled, offered first, negotiated: three different questions

Even a perfectly read list only tells you half of any story, because a connection has two ends. It helps to separate three questions that people often blur together.

The first question is whether something is enabled: is it allowed at all on this machine, after all three layers have done their narrowing? The second is whether it is offered first: when this machine starts a connection, does that item come at the top of its list of preferences? The third is whether it was negotiated: on one specific connection, to one specific server, is that what the two sides actually ended up using?

Only the third question is a fact about a connection, and it depends on the other side as much as on this one. When a Windows 11 machine connects to a server, it offers its versions, suites and groups in its preferred order. The server compares those offers with its own lists and picks. Microsoft notes that the highest TLS version both sides support is always preferred, so if the server has never been upgraded beyond TLS 1.2, the connection settles on TLS 1.2, however modern the client's settings are. The same happens with suites and groups: the client proposes, the server chooses from what both have in common.

Here is a concrete case. A company runs a modern Windows 11 laptop fleet and an internal reporting server installed several years ago. The laptops have TLS 1.3 enabled and offered first, so a dashboard might proudly report 'TLS 1.3 everywhere'. Yet every connection from a laptop to that reporting server negotiates TLS 1.2, because that is the newest version the server speaks. Nothing is misconfigured on the laptops, and nothing on them will ever reveal the gap by itself. Only a record of what each connection actually negotiated shows it.

That is why a sentence like 'our servers use TLS 1.3' needs care. It may mean that TLS 1.3 is enabled on them, or that it is preferred, or that a test connection from one particular client negotiated it. Each is useful and each is different. The most trustworthy evidence is the third kind, gathered from real connections: server logs that record the negotiated version and suite, a monitoring probe that reports what it agreed with each server, or a test from a second, independent TLS tool. When the reported result disagrees with the lists, the explanation is almost always on the other end.

Why a change can take a while to show

One more practical surprise trips up people reading these settings: the lists on the screen and the behaviour of a running program can disagree for a while after a change, without anything being broken.

Microsoft documents two reasons. For the cipher suite order and the group order, changes take effect on the next boot of the machine; until then, the previous order stays in force. For protocol versions, changes apply to new credential handles, the internal object a program creates when it first sets up Schannel. Programs and services usually create that object once and reuse it for many connections, for speed, so Microsoft notes that a program or service may need to be restarted before it picks up the new settings.

This has an awkward consequence in larger environments. Two servers built from the same image, given the same policy on the same afternoon, can behave differently for days if one has been restarted and the other has not. A reader who compares the two and finds that their lists match while their connections differ should look at uptime before looking anywhere else.

There is also a warning worth repeating for anyone who finds the default cipher order stored in the registry. Microsoft states that editing the registry values for the default priority order is not supported and may be reset by servicing updates; the supported routes are Group Policy, device management or the TLS commands. And for Group Policy specifically, the ordered list of suites is limited to 1,023 characters, a limit that becomes real when long suite names are pasted in. None of this is a recipe for changing a machine. It is what a careful reader needs to know so that a mismatch between a freshly read list and a still-running service is interpreted correctly rather than chased as a fault.

AI agents: overriding the machine, or overridden by it

An artificial intelligence (AI) agent is software in which a large language model (LLM) plans each step and then carries it out through network calls to models, tools and data sources. On Windows, an agent built on .NET or PowerShell makes those calls through Schannel, which means every list in this guide applies to it. That brings two risks that point in opposite directions, and both are worth knowing.

The first is an agent that quietly overrides the machine downward. Microsoft's guidance for the .NET Framework warns that when an application explicitly sets a protocol version, it opts out of the operating system's defaults, and that pinning an older version rules out TLS 1.3 connections altogether. A line copied years ago from a troubleshooting forum, forcing TLS 1.2, can therefore keep an agent on TLS 1.2 long after the machine underneath it has moved on. The same guidance warns against a setting named SslProtocols.Default, which, despite its name, selects the obsolete SSL 3.0 and TLS 1.0. For modern .NET, Microsoft recommends leaving the protocol choice to the operating system, and notes that on Windows a .NET program cannot even choose its own cipher suites: the class that would allow it is not supported there, so the machine's list is the agent's list.

The second risk is an agent that is quietly overridden by the machine. When a security team narrows the machine's lists, every Schannel agent on that machine is narrowed too, including one that talks to an older internal tool server still limited to old settings. The agent's code has not changed, yet its calls start failing. Neither risk is exotic; both come straight from the three-sieve rule.

The same reasoning applies when the roles are reversed. Many teams host their own tool servers on Windows, for example an internal service built on .NET and published through IIS that agents call to look up orders or file tickets. Then the server's lists decide what every calling agent can negotiate, whatever language those agents are written in. A tool server left on an older Windows release caps every agent that talks to it at that release's best version.

For teams that run agents, a handful of habits turn all of this into routine. They also give a leader a clear answer when asked whether an agent's connections meet the organisation's TLS standard: not 'the server is configured correctly', but 'here is what each connection negotiated'.

1. Let the operating system choose the TLS version; search agent code and configuration for hard-coded versions and remove them.
2. Record which Windows release each agent host runs, because that release decides whether TLS 1.3 is available at all.
3. Read the host's lists with Get-TlsCipherSuite and Get-TlsEccCurve once per server image, and compare them with the published defaults.
4. Log the negotiated version and suite for each outbound connection, so failures after a policy change are diagnosed in minutes.
5. Before narrowing a machine's lists, inventory the older tool servers its agents still call.

Glossary

Protocol version

The edition of TLS two computers agree to speak, such as TLS 1.2 or TLS 1.3.

Cipher suite

A named bundle of algorithms that fixes how a TLS conversation is encrypted and checked for tampering.

Supported group

The method two computers use to agree a shared secret; older Windows settings call these elliptic curves.

Group Policy

The Windows system for pushing the same settings to many computers from a central place.

Credential handle

The internal object a program creates when it first sets up Schannel and usually reuses for many connections.

RFC 8996

The 2021 internet standards document that formally deprecated TLS 1.0 and TLS 1.1.

ML-KEM

A newly standardised method for agreeing a shared secret that is designed to resist future quantum computers; Windows supports it as a group that is off by default.

Negotiated

What two computers actually agreed to use on one specific connection, as opposed to what each side merely allows.

Further reading

1. Protocols in TLS/SSL (Schannel SSP) (Microsoft Learn)
2. TLS Cipher Suites in Windows 11 (Microsoft Learn)
3. TLS Supported Groups in Windows 11 24H2 and later (Microsoft Learn)
4. Manage Transport Layer Security (TLS) in Windows Server (Microsoft Learn)
5. TLS 1.0 and TLS 1.1 deprecation in Windows (Microsoft Learn)
6. Transport Layer Security (TLS) best practices with .NET Framework (Microsoft Learn)
7. RFC 8996: Deprecating TLS 1.0 and TLS 1.1 (IETF)