AADSTS error codes: what they mean, grouped by cause

AADSTS error codes are the numbers Microsoft Entra ID puts on a failed sign-in, and there are a lot of them: the Microsoft Learn reference lists well over 300. Looking one up rarely helps on its own, because the same failure can surface under three different codes and the description is written for the developer of the app, not the administrator of the tenant. This page groups the codes you will actually meet by cause, gives the first check for each group, and says where the sign-in log answers the question faster than any lookup tool.

Most of these failures end in Entra’s policy engine or at the tenant boundary, so this hub sits under the Conditional Access policy failure modes guide, and it is the landing page for the AADSTS spokes that follow over the next few weeks. Every Microsoft fact below was checked against Microsoft Learn on 31 October 2026. I have not run these failures in production; my tenant is a lab with no enrolled devices, so what follows is the documentation, read carefully, plus where I would expect it to bite.

How to read AADSTS error codes before you look them up

Start with the sign-in log, not the code. The Microsoft Learn guide to troubleshooting sign-in errors sends you to Entra ID, Monitoring and health, Sign-in logs, as at least a Reports Reader. Filter Status to Failure, open the event, and copy four things: the correlation ID, the sign-in error code, the failure reason, and the user and sign-in identifier. The failure reason and the Additional Details field often tell you the fix before you have searched for anything.

Three habits save time.

1. Check which log type you are in. Entra keeps four kinds of sign-in log: interactive user, non-interactive user, service principal and managed identity. Microsoft notes that the legacy sign-in log experience only includes interactive user sign-ins. A token refresh failing in the background, or an app signing in as itself, will not appear where most people look first.
2. Read the code with the application and the resource. The same code means different things for a user opening Outlook on the web and for a script calling Microsoft Graph with a client secret. The application tells you who asked; the resource tells you what for.
3. Use Microsoft’s own lookup for the current wording. The error code reference says codes and messages are subject to change and points to login.microsoftonline.com/error, where you can search a code or add it to the URL as ?code=50058. The same page warns that apps taking a dependency on error text or code numbers will break over time.

The prefix is just the service. The Conditional Access troubleshooting article confirms that the codes in its list appear with a prefix of AADSTS followed by the number you see in the browser, so 53002 in the log and AADSTS53002 on the error page are the same thing.

Codes that are not failures

Several of the most common AADSTS error codes in a sign-in log are expected parts of the flow. Filtering them out first makes the real failures visible.

That last row is the one to watch. A handful of 50126 events per user per week is people mistyping. The same code at volume, against many accounts, from a small set of addresses, is something else, and I would expect it to arrive alongside 50053.

Wrong tenant, or the account does not exist there

This is the largest group, and the codes overlap more than the reference suggests. They all mean that the identity presented does not exist, or does not exist as a usable object, in the tenant that received the request.

• AADSTS50020. The account from the named identity provider does not exist in the tenant and cannot access the application there. Microsoft’s description says it needs to be added as an external user first, and if the user should be a member of the tenant, they should be invited through the B2B system.
• AADSTS16000. Near-identical wording, flagged as InteractionRequired. Microsoft notes it is fairly common when someone signs in to the Entra admin center with a personal Microsoft account that has no directory.
• AADSTS50034 and AADSTS51004. The account is not in the directory. Both descriptions say an application likely chose the wrong tenant to sign into. 50034 adds that the user may simply have mistyped the username.
• AADSTS90072. The external account does not exist in the tenant, so the user cannot satisfy that tenant’s MFA requirements. Microsoft adds a second cause that has nothing to do with guests: synced users with a mismatched ImmutableID (sourceAnchor) between Active Directory and Entra ID.
• AADSTS50059. No tenant-identifying information was found in the request or implied by the credential.

The first check for the whole group is the same: compare the tenant in the sign-in event with the tenant the application lives in. When they differ, the question is whether the user should be a guest in the app’s tenant or whether the app is sending users to the wrong authority. When they match, look at the user object itself: is it the right UPN, is it in sync scope, and has an on-premises change broken the match between the two directories? The choice between Cloud Sync and Connect Sync decides where that matching happens and how you repair it.

For organisations that collaborate, there is a neighbour to this group. AADSTS90071 is not a missing account but a trust setting in the resource tenant, and how cross-tenant access trust settings decide which claims you accept covers why it sends the wrong administrator to the wrong tenant.

App registration, consent and assignment

These codes come from the application side of the request. The user exists and may have authenticated perfectly well; the app, its configuration, or its permissions are the problem.

Two pairs here are easy to confuse. 700016 is about the client: the application making the request cannot be found. 500011 is about the resource: the API the client wants a token for cannot be found. And 7000215 and 7000222 look like the same problem in a log export, but one means the secret is wrong and the other means it was right and has expired. The fix for the second is a rotation process, not a typo.

50105 is the one I would expect administrators to cause themselves. Microsoft’s description is simply that the user is not assigned to the app. My expectation, which I have not tested at scale, is that it most often follows switching on Assignment required for an enterprise application when the group the users relied on is not the group that was assigned.

MFA and authentication method codes

These codes mean Entra wanted a stronger or different proof of identity than the one it got. The descriptions are close enough that the code alone rarely tells you which policy asked.

• AADSTS50076. The user must use MFA to access the resource, because of a configuration change such as a Conditional Access policy, per-user enforcement, or a move to a new location. Microsoft’s guidance is to retry with a new authorise request for the resource.
• AADSTS50079. The same trigger, but either a managed user needs to register security info, or a federated user needs the MFA claim from the federated identity provider.
• AADSTS50074. Strong authentication was required and the user did not pass the MFA challenge.
• AADSTS50072. The user needs to enrol for second factor authentication, interactively.
• 500121. Listed on the sign-in troubleshooting page as the user not completing the MFA prompt, which Microsoft says often appears when the user has not finished setting up MFA.
• AADSTS53004. The user must complete MFA registration before accessing the content; the error string is ProofUpBlockedDueToRisk.
• AADSTS75011. The method the user authenticated with does not match the requested authentication method. I would expect this most from SAML and federated apps that request a specific method.

The first check is the Authentication Details tab of the sign-in event, then the Conditional Access tab. Between them they show which methods were attempted and which policy demanded what. If the method was right and the result was still a failure, the problem may be the client. Why number matching does not appear in some clients is a good example of a method that works in one path and not another, and what an authentication strength requirement actually accepts explains why a user with MFA registered can still be refused.

Conditional Access and device codes

The Microsoft Learn guide to troubleshooting Conditional Access sign-ins lists a short set of common codes, and every one of them points at a requirement in a policy rather than at a credential.

53003 is the only plain block. Everything else in that table is a requirement the session did not meet, and the sign-in event’s Conditional Access tab names the policy. The same article says that selecting the ellipsis on a policy shows what was collected at sign-in alongside whether it satisfied each requirement. It also states that Conditional Access policies only apply when all conditions are satisfied or not configured, which is why a policy you expected to apply sometimes did not.

Two device codes sit outside that table. AADSTS50097 means device authentication is required, and AADSTS50155 means device authentication failed for this user. Both point at the device object rather than the policy. If the device never registered properly, the hybrid join failures that leave a device pending are where I would look, and a device filter that matches nothing on an unregistered device fails in the same place.

One more trap from the troubleshooting article: service dependencies. The article’s example is a user signing in to the Azure portal whose resource is Azure Resource Manager, and a user opening Teams who is actually requesting several resources at once. Audience reporting in the sign-in log shows all of them, and a policy can apply because one of those audiences is in scope even though the user thinks they only opened one app.

Account state and credentials

These codes come from the user object, not the app and not the policy.

• AADSTS50053. Microsoft gives two different causes: the account is locked after too many sign-in attempts with an incorrect user ID or password, or the sign-in came from an IP address with malicious activity. The reference says to find the event with error code 50053 in the sign-in logs and check the Failure reason to tell them apart.
• AADSTS50057. The user account is disabled.
• AADSTS50055. The password has expired.
• AADSTS50132 and AADSTS50133. The session is not valid because of password expiry or a recent password change.
• AADSTS50173. The grant has expired because it was revoked, and the user might have changed or reset their password. The error states when the grant was issued and the user’s TokensValidFrom date.

The practical point about 50053 is that it is two problems sharing one number. Unlocking an account that was blocked because of a malicious IP fixes nothing, and treating a genuine lockout as an attack wastes an afternoon. The Failure reason is the deciding field.

Tokens, sessions and malformed requests

The last group mostly belongs to developers and to the people supporting line-of-business apps. I would expect to find them in the non-interactive and service principal logs more often than in the interactive one.

• AADSTS70043. The refresh token has expired or is invalid because of Conditional Access sign-in frequency checks. That is a policy working as designed.
• AADSTS700082 and AADSTS70008. The refresh token expired through inactivity. Microsoft calls 700082 an expected part of the token lifecycle.
• 70046. The session expired or a reauthentication check failed, which the troubleshooting page links to Conditional Access requiring reauthentication for various sign-in risk levels.
• AADSTS54005. The authorisation code was already redeemed.
• AADSTS50196. A client loop was detected. Microsoft’s description says the app has made too many of the same request in too short a period, and tells you to check that token caching is implemented and error conditions are handled.
• AADSTS90014, AADSTS90023 and AADSTS900561. A required field is missing from the credential, the request is not valid, or the endpoint received the wrong HTTP verb. All three describe the shape of the request, not the user.

If you send sign-in logs to a Log Analytics workspace, a count by code and application is the fastest way to see which group you are dealing with. In the SigninLogs table, the ResultType column carries the error code, with 0 for success, and ResultDescription carries the reason.

1// Count failed interactive sign-ins by AADSTS code and app, last 7 days.
2SigninLogs
3| where TimeGenerated > ago(7d)
4| where ResultType != '0'
5| summarize Failures = count(), Users = dcount(UserPrincipalName)
6    by ResultType, ResultDescription, AppDisplayName
7| order by Failures desc

A code that is high on Failures and low on Users is usually one broken client retrying. A code spread across many users is usually a policy or a tenant-wide change.

The failure modes

Where AADSTS error codes mislead, and what is really going on.

• The browser shows one code, the log seems to show another. An interrupt such as 50140 or 50158 can sit next to the event that matters. Filter the log by the correlation ID from the error page’s More Details and read the events in time order before deciding which code is the real one.
• The code is right and the account is wrong. 50020, 50034 and 51004 can mean the user picked an account from a different tenant. I would check which account was presented before sending a guest invitation.
• The policy is right and the resource is unexpected. Microsoft’s example is a policy restricting SharePoint that still applies when the user thinks they are only signing in to Teams. Audience reporting shows it.
• Nothing in the interactive log. A service or a background refresh is failing, and its events are in the non-interactive or service principal logs.
• A lookup site gives a different description. Microsoft says error codes and messages change. Third-party lookup tables are snapshots; the reference and login.microsoftonline.com/error are current.
• The app depends on the text. Microsoft is explicit that apps taking a dependency on error text or numbers will break over time. If an internal app parses AADSTS strings to decide what to do, that is a defect waiting for the next wording change.

What I would do differently

I would not start with the code at all. I would start with the correlation ID, the application and the resource, and only then read the code, because the code is the least specific of the four. A lot of time on these errors goes on reading the right description for the wrong event.

I would separate the expected noise before building any alert. An alert on every failed sign-in will fire on 50058 and 50140 all day, and the people watching it will learn to ignore it. Excluding the codes Microsoft itself calls expected gives an alert that means something.

I would treat 50053 and 50126 at volume as a security signal first and a helpdesk ticket second, and I would want the Failure reason in any alert so the two causes of 50053 are not merged.

And I would keep an internal page like this one, mapped to the tenant’s own policies. Microsoft’s reference is the authority for what a code means; only your own Conditional Access design can tell you which of your policies produces it. That is what the spokes under this hub will add, one code at a time, starting with AADSTS50020 and AADSTS50105.

The full list of AADSTS error codes, with Microsoft’s current descriptions, is in the Microsoft Entra authentication and authorization error codes reference. Use it to confirm a description, and use the sign-in log to find out why.

Last verified: 31 October 2026.