AADSTS1002016: Client uses TLS 1.0, 1.1 or 3DES (fix)

What does AADSTS1002016 mean?

Microsoft’s error code reference doesn’t list AADSTS1002016 (checked 30 October 2026). The wording below comes from user reports.

A user on Microsoft Q&A posted this message from a VB.NET desktop app using MSAL.NET:

AADSTS1002016: You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD.

TheWindowsClub quotes the same text.

The message matches Microsoft’s documented TLS change. Microsoft’s TLS 1.2 guidance for Entra says Entra stops supporting TLS 1.1, TLS 1.0 and the 3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The dates on that page:

Instance	Deprecation date	Status
U.S. government	31 March 2021	Completed
Public	31 January 2022	Completed
Operated by 21Vianet in China	31 January 2025	Ongoing

The page we opened doesn’t quote AADSTS1002016 itself. Our reading: this is the error Entra returns to a client that still negotiates one of the retired protocols.

In the lab, you no longer get this far. On 30 October 2026 a lab run sent a token request to login.microsoftonline.com with the client pinned to TLS 1.0. The connection was reset during the TLS handshake (ECONNRESET), with no HTTP response and no AADSTS code. So on the public cloud today, a TLS 1.0 client fails before Entra can answer, and the symptom is a connection error in your application, not this error code. Treat AADSTS1002016 as a code from the deprecation window, or from an instance that still accepts the old protocol long enough to reply.

Is it an attack?

No. The client is old or badly configured. Microsoft’s page names components that may be affected: Microsoft Entra Connect, Microsoft Graph PowerShell, application proxy connectors, PTA agents, legacy browsers and apps integrated with Entra ID.

Pattern	Likely meaning
A PowerShell script or .NET Framework app fails	Our reading: the .NET Framework runtime isn’t using TLS 1.2. The Q&A user fixed it by forcing TLS 1.2 in code.
A server older than Windows Server 2012 R2 fails	Microsoft says only Windows 8.1, Windows Server 2012 R2 and later support TLS 1.2 natively over WinHTTP. Earlier versions need an update and registry values.
One old browser or device fails	Microsoft lists browsers without TLS 1.2, such as Internet Explorer 8 to 10 on Windows 7.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table AADSTS1002016 is logged in. Check all three:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "1002016"
| summarize Rows = count(), LastSeen = max(TimeGenerated), IPs = make_set(IPAddress, 20) by SourceTable, AppId, UserAgent

Microsoft documents a second signal: “For clients or apps that sign in over legacy TLS, Microsoft Entra ID marks the Legacy TLS field in Additional Details with True.” Its page gives a query per table. This version runs it over all three at once and adds the result code (our adaptation of Microsoft’s query):

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProcessingDetails has "Legacy TLS" and AuthenticationProcessingDetails has "True"
| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)
| mv-apply JsonAuthProcDetails on (
    where JsonAuthProcDetails.key startswith "Legacy TLS"
    | project HasLegacyTls = JsonAuthProcDetails.value
  )
| where HasLegacyTls == true
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName, ServicePrincipalName, UserAgent, ResultType
| sort by Rows desc

UserAgent often names the client, for example a PowerShell or .NET version. Our reading: if this returns nothing but the first query does, the failed rows don’t carry the Legacy TLS flag.

How do I fix AADSTS1002016?

For the user: update the app or browser. If it’s a company tool, report the error and the tool name to IT.

For developers: make the client use TLS 1.2.

• Microsoft says “.NET Framework 4.6.2 and later versions support TLS 1.2” once the registry is set, and that 4.6 and earlier need an update.
• The Q&A user fixed a .NET Framework app with one line before calling MSAL: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12.
• In Windows PowerShell 5.1, the same .NET setting is (our translation of that line):

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Setting it in code fixes one process. The registry settings below fix the machine.

For admins: on the affected Windows machine, set the values Microsoft lists. These two make .NET Framework use the OS’s TLS versions and strong cryptography:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727',
  'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
  'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727',
  'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
)
foreach ($p in $paths) {
  if (-not (Test-Path $p)) { New-Item -Path $p -Force | Out-Null }
  New-ItemProperty -Path $p -Name SystemDefaultTlsVersions -Value 1 -PropertyType DWord -Force | Out-Null
  New-ItemProperty -Path $p -Name SchUseStrongCrypto -Value 1 -PropertyType DWord -Force | Out-Null
}

The script is ours; the keys and values are from Microsoft’s page. Restart the app or service afterwards. Microsoft also lists the SCHANNEL TLS 1.2\Client and TLS 1.2\Server keys (Enabled = 1, DisabledByDefault = 0). Windows 8.1, Windows Server 2012 R2 and later support TLS 1.2 natively over WinHTTP. Earlier versions need update 3140245.

Then run the second query again to find any other clients still on legacy TLS.