Microsoft Entra AADSTS Error Codes: The Ones You Will See and How to Fix Them

Reading an AADSTS error without guessing

Every failed Microsoft Entra sign-in carries an error code that starts with AADSTS, short for the security token service that issued the failure. The code is more precise than the message a user sees on screen, and it is the fastest way to tell a wrong password from a Conditional Access block from a broken app registration. This guide covers fifteen AADSTS error codes that turn up often, with the usual cause and a sensible first check for each. It is a starting point, not a replacement for the official list, which Microsoft keeps current in Microsoft Entra authentication and authorization error codes.

Where to find the code and its context

Ask the user for the full error text, or the Request ID and Correlation ID shown on the error page, plus an approximate time. Then open the Microsoft Entra admin center, go to the sign-in logs and search by user, time or correlation ID. The log entry shows the result type, the failure reason, which client app was used, which application was the target, and which Conditional Access policies were evaluated and what each decided. That context matters more than the code alone: the same code can come from a browser, a mobile app or an old mail client, and the fix differs.

If you only have the number, Microsoft provides an error lookup at https://login.microsoftonline.com/error; adding ?code=50058 to the address, for example, jumps to that code. You can also paste a code into the Microsoft error code explainer, which runs in the browser and gives a plain-language reading and a list of first checks. Treat any explainer as a pointer and confirm against the sign-in log.

Fifteen codes you will meet most often

Each entry gives the code, what Microsoft says it means, and a first check. The descriptions paraphrase the official reference.

• AADSTS50126, invalid username or password. The credentials did not validate. Expect a steady background of these from ordinary typing mistakes. First check: whether failures are spread across many users, which is normal, or concentrated on one account from many addresses, which can indicate password spray.
• AADSTS50053, account locked or blocked sign-in. Either the account was locked after too many incorrect attempts, or the sign-in came from an IP address with malicious activity. First check: the sign-in log details to see which reason applies, then Microsoft's guidance on remediating risks and unblocking users before you reset anything.
• AADSTS50055, password expired. The user is normally offered a reset. First check: whether the account is synced from on-premises Active Directory, because a reset may need to happen there or through password writeback.
• AADSTS50057, user account disabled. The account is disabled. First check: whether this is deliberate, such as a leaver, before anyone re-enables it. For synced accounts, the object is disabled in the on-premises directory.
• AADSTS50034, user account not found. The account does not exist in the tenant being signed into. It is often a mistyped name, or an app sending the user to the wrong tenant. First check: the exact sign-in name, and the tenant in the request. A guest account may need to be invited.
• AADSTS50020, account from an identity provider does not exist in this tenant. Closely related to 50034, and typical when a person signs in with a personal Microsoft account or another organization's account to an app that only allows your tenant. First check: whether the app should accept external accounts, and whether the person should be invited as a guest.
• AADSTS50076, multifactor authentication required. A Conditional Access policy, per-user setting or location change now requires MFA, and the client must start a new interactive request. First check: the Conditional Access tab of the sign-in entry, to confirm which policy asked for it.
• AADSTS50079, MFA enrolment required. Same trigger as 50076, but the user has not registered a method. First check: whether the user has registered authentication methods, and whether the registration page itself is reachable under your policies.
• AADSTS53003, blocked by Conditional Access. A policy does not allow token issuance. First check: the sign-in log, which names the policy that blocked. Use the What If tool to reproduce the situation without asking the user to try again.
• AADSTS65001, consent has not been granted. The user or an administrator has not consented to the application for the permissions requested. First check: the app's requested permissions and your tenant's user consent settings. Granting admin consent is a decision about data access, so review what the permissions allow first.
• AADSTS70008, expired or revoked grant. The refresh token expired through inactivity or was revoked. This is part of the normal token lifecycle. First check: whether the user simply has to sign in again, and whether something such as a password change revoked sessions.
• AADSTS50105, user not assigned to the application. The app requires user assignment and this user has no assignment. First check: the enterprise application's Users and groups blade, and whether assignment is meant to be required.
• AADSTS50011, reply URL mismatch. The redirect address in the request is missing from the app registration. This is a developer-side problem. First check: compare the exact address, including scheme, path and trailing slash, with the registered redirect URIs.
• AADSTS700016, application not found in the tenant. The application identifier is wrong, or the app is not installed or consented in this tenant, or the request went to the wrong tenant. First check: the client ID and the tenant ID in the request.
• AADSTS7000215, invalid client secret. The app presented a wrong secret. First check: whether the secret has expired or was copied by its ID rather than its value, and replace it through your secret-handling process rather than pasting it into tickets.

A short method that works for most of them

Start by sorting the code into one of four groups. User problems, such as 50126, 50055 and 50057, are about the person's account. Policy outcomes, such as 50076, 50079 and 53003, mean a control did what it was configured to do, so the question is whether the configuration is right. Tenant and app mismatches, such as 50034, 50020, 50105 and 700016, are usually about the wrong tenant or a missing assignment. App configuration errors, such as 50011 and 7000215, belong to whoever owns the app registration.

Then read the sign-in log entry for that group. For policy outcomes, open the Conditional Access tab. For tenant mismatches, compare the home tenant and the resource tenant. For app errors, ask the developer for the exact request.

Things not to do

Do not switch off a Conditional Access policy to clear a 53003 or 50076 for one person. Use the What If tool, then add a narrow, time-limited, documented exclusion if one is justified, and remove it afterwards. Do not paste screenshots that include tokens or secrets into a ticket. Do not grant admin consent to clear 65001 until you know what the application can read.

Do not treat a high count of 50126 as an incident by itself. Look at the pattern across accounts and source addresses first.

Keeping a record

When you resolve a code, write down the code, the cause, and the check that confirmed it. After a few weeks you will have a short list of what really happens in your tenant, which is more useful than any general table. If you would like help reviewing a set of sign-in failures, the Cloudek read-only pilot is described on its scope page, and the free tools linked above work without it.

Check the Microsoft reference again before acting on a specific code, as descriptions and recommended actions are updated over time.