Learn about the upcoming changes in Schannel protocol defaults and how to remove dependencies on legacy TLS versions or keep them enabled for compatibility.
Transport Layer Security (TLS) is the most common internet protocol for setting up an encrypted channel of communication between a client and server. TLS 1.0 dates back to 1999 and, over time, several security weaknesses have been found in this protocol version. TLS 1.1 was published in 2006 and made some security improvements, but never saw broad adoption. These versions have long been surpassed by TLS 1.2 and TLS 1.3, and TLS implementations try to negotiate connections using the highest protocol version available.
Over the past several years, internet standards and regulatory bodies have deprecated or disallowed TLS versions 1.0 and 1.1, due to a variety of security issues. We have been tracking TLS protocol usage for several years and believe TLS 1.0 and TLS 1.1 usage data are low enough to act.
To increase the security posture of Windows customers and encourage modern protocol adoption, TLS versions 1.0 and 1.1 will soon be disabled by default in the operating system, starting with Windows 11 Insider Preview builds in September 2023 and future Windows OS releases. This change applies to both client and server, but it will not impact any in-market OS versions. There is an option to re-enable TLS 1.0 or TLS 1.1 for users who need to maintain compatibility.
Applications that start failing when TLS 1.0 and TLS 1.1 are disabled can be identified by Event 36871 in the Windows Event Log.
A fatal error occurred while creating a TLS <client/server> credential. The internal error state is 10013. The SSPI client process is <process ID>.
Guidance for users and IT admins
The impact of this change depends largely on the Windows applications using TLS. For example, TLS 1.0 and TLS 1.1 have already been disabled by Microsoft 365 products as well as WinHTTP and WinINet API surfaces. Most newer versions of applications support TLS 1.2 or higher protocol versions. Therefore, if an application starts failing after this change, the first step is to look for a newer version of the application that has TLS 1.2 or TLS 1.3 support.
It's recommended to use the system default settings for the best balance of security and performance. If organizations limit TLS cipher suites using Group Policy or PowerShell cmdlets, they should also verify that cipher suites needed for TLS 1.3 and TLS 1.2 are enabled.
If there are no alternatives available and TLS 1.0 or TLS 1.1 is needed, the protocol versions can be re-enabled with a system registry setting. To override a system default and set a (D)TLS or SSL protocol version to the Enabled state, create a DWORD registry value named "Enabled" with an entry value of "1" under the corresponding version-specific subkey. Examples of TLS 1.0 subkeys are as follows:
Note: Re-enabling TLS 1.0 or TLS 1.1 on machines should only be done as a last resort, and as a temporary solution until incompatible applications can be updated or replaced. Support for these legacy TLS versions may be removed completely in the future.
Guidance for SSPI application developers
Although most applications and services use Schannel via HTTP and .NET APIs, some call the Security Support Provider Interface (SSPI) directly. Historically, SSPI callers implementing TLS clients and servers would pass the SCHANNEL_CRED structure when calling AcquireCredentialsHandle(). This allowed the hard coding of legacy TLS versions and prevented apps from using new TLS versions. With TLS 1.0 and TLS 1.1 disabled by default, an SSPI application that only allows these versions will fail to connect.
SCHANNEL_CRED was deprecated in Windows 10, and SSPI callers should specify their preferences using SCH_CREDENTIALS instead. Applications using this new structure will be able to negotiate TLS 1.3 and later protocol versions. When updating code to switch from SCHANNEL_CRED to SCH_CREDENTIALS, implementers should test their TLS client or server against a TLS 1.3 peer and ensure that the code correctly handles SEC_I_RENEGOTIATE returned from DecryptMessage().
We have tested this change against top Windows applications, and found that the following versions rely on TLS 1.0 or TLS 1.1 and are expected to be broken.
Note: This is not an exhaustive list. All systems and organizations should test the disablement using the steps described above and observe any failures. Please reach out directly to the application owner, as they often have an updated version or mitigation available.