How many failed attempts trigger AADSTS50053?

By default, smart lockout locks an account for one minute after 10 failed attempts in Azure public cloud tenants (3 in Azure US Government), and the lockout period grows with repeated lockouts. Administrators can change the threshold and duration in the authentication methods password protection settings, which requires Microsoft Entra ID P1 or higher.

Does smart lockout lock out the real user too?

It tries not to. Smart lockout keeps separate lockout counters for familiar and unfamiliar sign-in locations, so an attacker hammering from an unfamiliar network should not lock the employee out of their usual one. Lockouts that hit users from their normal office or home network are worth a closer look: either the attempts come from a familiar-looking place or the threshold is set very low.

Why does retrying the same wrong password not lock the account faster?

Smart lockout remembers the last three bad password hashes and does not count a repeat of the same wrong password again, so a device retrying one stale password does not keep extending the lockout. Different passwords tried in sequence — real guessing — do count toward the threshold, which is why lockouts are a reasonable signal of guessing.

How do I tell the lockout case from the malicious-IP case?

Open the failed sign-in and read the failure reason, as Microsoft's description says; in Log Analytics the same text is in the ResultDescription column. A lockout follows a run of AADSTS50126 for the same account, while an IP block can appear on the very first attempt from that address, with no earlier failures for the account.

AADSTS50053: Account Locked or Malicious IP Blocked in Entra ID

Published October 6, 2026

Entra ID refused the sign-in before accepting it: either smart lockout has locked the account after repeated failures, or the source IP was blocked for malicious activity.

Did the attacker have the password? Cannot tell from this code alone — correlate with the events around it.

Microsoft's definition

IdsLocked

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 as at least a Cloud Application Administrator. Navigate to your Microsoft Entra tenant and then Monitoring & health > Sign-in logs. Find the failed user sign-in with Sign-in error code 50053 and check the Failure reason.

Source: Microsoft Entra authentication and authorization error codes · checked against the published table on every build

Where it appears

Microsoft Sentinel / Log Analytics: the ResultType column of SigninLogs and AADNonInteractiveUserSignInLogs
Microsoft Graph signIns API and JSON exports: status.errorCode, with the text in status.failureReason
Entra admin center sign-in log download (CSV): the Sign-in error code column
The failure reason text (ResultDescription in Log Analytics) tells the lockout and the IP block apart

What it means

AADSTS50053 has two causes, and Microsoft’s description names both. In the common case it is smart lockout: the account received enough wrong passwords that Entra ID stopped accepting sign-ins for it for a while. In the other case Entra ID blocked the source IP because it was associated with malicious activity, regardless of the account.

Either way the request was refused before the credentials could produce a session, so the code alone cannot tell you whether the attacker had the right password. It does tell you that someone was trying hard enough to be stopped.

Is it an attack?

A run of AADSTS50126 for one account from one unfamiliar IP, ending in 50053 — password guessing against that account, stopped by smart lockout.
50053 across several accounts from the same IP — a spray that crossed the lockout threshold on some accounts, or an IP that Microsoft has already flagged.
50053 for one user from their usual network, after a password change — usually a device or app with an old password; a repeated identical wrong password is not counted again, so a long run of lockouts from one device still deserves a look.
50053 on the first attempt from a new IP — the malicious-IP case; check the failure reason to confirm.

How to investigate

List every account that was locked in the last day, with the failures that led up to it and the IPs involved:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50053", "50126")
| summarize Lockouts = countif(ResultType == "50053"),
            BadPasswords = countif(ResultType == "50126"),
            SourceIPs = make_set(IPAddress, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by UserPrincipalName
| where Lockouts > 0
| order by Lockouts desc

Then take the source IPs and check whether any of them later produced a success (ResultType == "0") or an MFA-stage code such as AADSTS50074 for the same account. A lockout followed by a success from the attacking IP once the lockout expired is a compromise, not a blocked attempt.

When nothing succeeded: block the sources with a named location, confirm the targeted accounts have MFA registered, and confirm legacy authentication is blocked. When the lockouts hit many accounts at once, treat it as a password-spray incident and review the AADSTS50126 queries for the full scope.

Related codes

AADSTS50126 InvalidUserNameOrPassword Entra ID rejected the password (or the username) for this sign-in. One failure is a typo; the same failure across many accounts from one IP is password spraying.
AADSTS50034 UserAccountNotFound
AADSTS50057 UserDisabled
AADSTS50074 UserStrongAuthClientAuthNRequiredInterrupt The password was correct and Entra ID asked for multifactor authentication, which this request did not complete. Followed by a success it is routine; alone, from an unfamiliar place, it means someone else knows the password.
AADSTS50076 UserStrongAuthClientAuthNRequired Entra ID accepted the username and password, then required multifactor authentication that this request did not provide. From scripts or legacy mail clients it is strong evidence that whoever sent it knows the password.

Frequently Asked Questions

How many failed attempts trigger AADSTS50053?: By default, smart lockout locks an account for one minute after 10 failed attempts in Azure public cloud tenants (3 in Azure US Government), and the lockout period grows with repeated lockouts. Administrators can change the threshold and duration in the authentication methods password protection settings, which requires Microsoft Entra ID P1 or higher.
Does smart lockout lock out the real user too?: It tries not to. Smart lockout keeps separate lockout counters for familiar and unfamiliar sign-in locations, so an attacker hammering from an unfamiliar network should not lock the employee out of their usual one. Lockouts that hit users from their normal office or home network are worth a closer look: either the attempts come from a familiar-looking place or the threshold is set very low.
Why does retrying the same wrong password not lock the account faster?: Smart lockout remembers the last three bad password hashes and does not count a repeat of the same wrong password again, so a device retrying one stale password does not keep extending the lockout. Different passwords tried in sequence — real guessing — do count toward the threshold, which is why lockouts are a reasonable signal of guessing.
How do I tell the lockout case from the malicious-IP case?: Open the failed sign-in and read the failure reason, as Microsoft's description says; in Log Analytics the same text is in the ResultDescription column. A lockout follows a run of AADSTS50126 for the same account, while an IP block can appear on the very first attempt from that address, with no earlier failures for the account.

Find AADSTS50053 in your own logs

Drop an Entra ID sign-in export into the free browser analyzer to see which users and IPs hit this code (nothing is uploaded), or run it through LogTriage for threat-intel enrichment and an AI-written incident report.

Open the free analyzer → Analyze Your Own Logs