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

Canonical: https://brambrinkmeier.com/entra/aadsts/1002016/
By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/1002016.json

**Short answer:** AADSTS1002016 means the client connected to Entra with TLS 1.0, TLS 1.1 or the 3DES cipher, which Entra no longer accepts. Microsoft doesn't list the code; a user reports it from an older .NET app. Microsoft retired legacy TLS for public Entra instances on 31 January 2022. It is a client configuration error with low attack value. Enable TLS 1.2.

**Fix:** Developer: make the client use TLS 1.2. In .NET Framework or Windows PowerShell 5.1, set `ServicePointManager.SecurityProtocol` to `Tls12` before calling MSAL. Admin: set the .NET Framework strong-crypto registry values and restart the app. User: update the app or browser, or report it to IT.

| Field | Value |
|---|---|
| Code | AADSTS1002016 |
| Category | App configuration |
| Type | Configuration error |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | No (checked 2026-10-30) |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS1002016 mean?

Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) 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](https://learn.microsoft.com/troubleshoot/azure/active-directory/enable-support-tls-environment) 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:

```kusto
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):

```kusto
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):

```powershell
[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:

```powershell
$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.

## Evidence

Not in Microsoft's error reference and not reproduced in the lab; built from lab results, other Microsoft pages and user reports, which the page names.

Lab-run rows naming this code (7; full list at https://brambrinkmeier.com/lab-runs.json):

| Date | Scenario | Expected | Got | Message (first line) |
|---|---|---|---|---|
| 2026-10-30 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-30 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-30 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-30 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-30 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-31 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |
| 2026-10-31 | Token request over TLS 1.0 | 1002016 |  | no response: ECONNRESET |

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/entra/identity-platform/reference-error-codes)
2. [AADSTS1002016: You are using TLS version 1.0, 1.1 and/or 3DES cipher (Microsoft Q&A)](https://learn.microsoft.com/en-us/answers/a/1193635)
3. [Enable TLS 1.2 support in your environment (Microsoft Entra TLS 1.0 and 1.1 deprecation)](https://learn.microsoft.com/troubleshoot/azure/active-directory/enable-support-tls-environment)
4. [AADSTS1002016: You are using TLS version 1.0, 1.1 or 3DES cipher (TheWindowsClub)](https://thewindowsclub.com/aadsts1002016-you-are-using-tls-version-1-0-1-1-3des-cipher)
5. [SigninLogs table reference (Azure Monitor)](https://docs.azure.cn/en-us/azure-monitor/reference/tables/SigninLogs)

## Related codes

[AADSTS7000218](https://brambrinkmeier.com/entra/aadsts/7000218/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/), [AADSTS90002](https://brambrinkmeier.com/entra/aadsts/90002/), [AADSTS9002313](https://brambrinkmeier.com/entra/aadsts/9002313/)

## License and citation

CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.

Cite as: Bram Brinkmeier, "AADSTS1002016: Client uses TLS 1.0, 1.1 or 3DES (fix)", https://brambrinkmeier.com/entra/aadsts/1002016/ (CC BY 4.0), last updated 2026-10-30.