AADSTS50053: Account locked or sign-in blocked

What does AADSTS50053 mean?

This error can result from two different reasons: IdsLocked - The account is locked because the user tried to sign in too many times with an incorrect user ID or password. The user is blocked due to repeated sign-in attempts. See Remediate risks and unblock users. Or, sign-in was blocked because it came from an IP address with malicious activity. To determine which failure reason caused this error, sign in to the Microsoft Entra admin center … Navigate to … Monitoring & health > Sign-in logs. Find the failed user sign-in with Sign-in error code 50053 and check the Failure reason.

One code, two mechanisms. Read the failure reason before you decide what happened. For the full spray investigation, see How to detect password spraying in Entra ID.

1. Smart lockout. Too many wrong passwords. Microsoft’s smart lockout page:

By default, smart lockout locks an account from sign-in after: 10 failed attempts in Azure Public and Microsoft Azure operated by 21Vianet tenants; Three failed attempts for Azure US Government tenants. The account locks again after each subsequent failed sign-in attempt. The lockout period is one minute at first, and longer in subsequent attempts.

Microsoft also says smart lockout “uses familiar location versus unfamiliar location to differentiate between a bad actor and the genuine user. Both unfamiliar and familiar locations have separate lockout counters.”

2. Built-in protection block. The same smart lockout page says Entra ID “blocks these malicious sign-ins by default and returns AADSTS50053 - IdsLocked error code, regardless of the password validity.” The ID Protection documentation adds:

Microsoft Entra ID Protection automatically blocks sign-ins that have a very high confidence of being risky. This block most commonly occurs on sign-ins performed using legacy authentication protocols or displaying properties of a malicious attempt. When a user is blocked for either scenario, they receive a 50053 authentication error. The sign-in logs display the following block reason: ‘Sign-in was blocked by built-in protections due to high confidence of risk.’

The important phrase is “regardless of the password validity”. A 50053 of this kind does not tell you whether the password was right or wrong.

Is it an attack?

Pattern	Likely meaning
One user, preceded by a handful of 50126 from their usual IP and device	The user forgot or mistyped the password and tripped smart lockout. Benign.
Failure reason “Sign-in was blocked by built-in protections due to high confidence of risk”	Microsoft judged the sign-in malicious. Look at the IP and ClientAppUsed. Legacy protocols are the common case.
Many different users hitting 50053 from one IP or range, after a run of 50126	A password spray (T1110.003) that tripped lockout.
Many 50053 against one user from unfamiliar IPs	Brute force against that account (T1110.001).
50053 on legacy clients (SMTP, IMAP, POP) for a service account or old device	Often a device or script with a stale password, or a legacy-auth spray. Check the IP.
A success, 50076/50074 or 53003 from the same IP for a targeted user	The attacker found a correct password at some point. Treat that account as compromised.

Conditional Access does not run on a 50053. Microsoft’s moderator in the Q&A thread puts it this way: “Conditional access policies only apply after the first factor of authentication is successfully completed.” So expect ConditionalAccessStatus = notApplied on these rows.

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

Split 50053 by mechanism. The built-in protection block is identified by its documented failure reason. Everything else under 50053 is, in practice, smart lockout, but Microsoft does not publish the exact lockout wording, so check the ResultDescription values the query returns in your own workspace.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50053"
| extend FailureReason = tostring(Status.failureReason)
| extend Mechanism = iff(ResultDescription has "built-in protections" or FailureReason has "built-in protections",
                         "Built-in protection block", "Smart lockout (likely)")
| summarize Events = count(),
            Users = dcount(UserPrincipalName),
            IPs = dcount(IPAddress),
            Clients = make_set(ClientAppUsed, 5)
          by Mechanism, ResultDescription
| sort by Events desc

Spray that tripped lockout: one IP, many locked users, and did that IP ever get further than the password?

let lockoutIPs =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50053"
    | summarize LockedUsers = dcount(UserPrincipalName) by IPAddress
    | where LockedUsers >= 5
    | project IPAddress;
SigninLogs
| where TimeGenerated > ago(1d)
| where IPAddress in (lockoutIPs)
| where ResultType in ("0", "50076", "50074", "50079", "53003", "50055")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, ResultDescription,
          ConditionalAccessStatus, AppDisplayName, ClientAppUsed
| sort by TimeGenerated asc

ResultType is a string, so compare with "50053". Legacy clients such as SMTP AUTH can produce 50053 too. If you allow legacy auth, run the first query against AADNonInteractiveUserSignInLogs as well. There Status is a string, so use tostring(parse_json(Status).failureReason).

How do Conditional Access and MFA affect it?

• CA can’t prevent a 50053. Both mechanisms act at the credential stage, before CA evaluates.
• Smart lockout is always on for every tenant. Changing the threshold or duration needs Entra ID P1.
• Blocking legacy authentication with CA removes the protocols where the built-in block most commonly fires, and those protocols can’t do MFA.
• MFA does not stop the lockout itself. It decides what happens if the attacker ever gets the password right.

How do I fix AADSTS50053?

For the user:

• Smart lockout: wait for the lockout period to pass, or reset the password with self-service password reset. Don’t keep retrying the old password. Each further failure locks the account again, and later lockouts last longer.
• Built-in block: sign in from a familiar location and a modern client (the browser, current Outlook), not an old mail app.

For admins:

1. Check the failure reason first. It decides everything else.
2. Smart lockout on one user: find the source of the bad passwords. A phone or script with an old password keeps re-locking the account.
3. Built-in block: Microsoft’s unblock options are to add the IP to trusted named locations (only if you really own it), move the client to modern authentication, or have the user sign in from a familiar location.
4. Spray pattern: use the second query to find any targeted account that got past the password. Reset those passwords and revoke sessions.
5. Block legacy authentication with Conditional Access.