Which policy blocked the sign-in?

Open the sign-in event and check the Conditional Access tab, or read appliedConditionalAccessPolicies in a Graph export: each policy is listed with its result, and the ones with the result failure produced the block. In Log Analytics the same list is in the ConditionalAccessPolicies column of SigninLogs, which the query on this page expands.

Does AADSTS53003 mean the password was correct?

For an interactive username-and-password sign-in, yes in practice: Microsoft documents that Conditional Access policies are enforced after first-factor authentication is completed. For token refreshes and other non-interactive flows the first factor is an existing token rather than a password, so the conclusion applies to whatever credential the client presented.

Why do I see AADSTS53003 for IMAP, POP3 or SMTP?

A Conditional Access policy that blocks legacy authentication rejects those clients with 53003. The block is doing its job, but each entry is still a request that presented working credentials over a legacy protocol, which is typical of password-spraying tools. Group them by IP and user to see whether one source is cycling through accounts.

Is a location-based AADSTS53003 from another country a compromise?

It is a strong sign that the password is known outside your organization, because the block happened after the first factor. Reset the password, revoke the user's sessions and check whether the same account signed in successfully from any location or application the policy does not cover.

AADSTS53003: Blocked by Conditional Access — Reading the Block

Published October 6, 2026

A Conditional Access policy blocked the sign-in. Conditional Access is enforced after first-factor authentication completes, so for an interactive sign-in an unexpected 53003 usually means the password was right.

Did the attacker have the password? Yes — the password was accepted; the sign-in failed at a later step. Treat the credential as known to whoever attempted it.

Microsoft's definition

BlockedByConditionalAccess

BlockedByConditionalAccess - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. If this is unexpected, see the Conditional Access policy that applied to this request or contact your administrator. For additional information, please visit troubleshooting sign-in with Conditional Access.

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 policy that blocked the request: appliedConditionalAccessPolicies in Graph, the ConditionalAccessPolicies column in Log Analytics, the Conditional Access tab in the portal

What it means

AADSTS53003 means one or more Conditional Access policies evaluated the sign-in and blocked token issuance. Microsoft’s Conditional Access overview is explicit that policies are enforced after first-factor authentication is completed. For an interactive sign-in with a password, a 53003 therefore means the password was accepted and a policy then refused the request.

That turns many 53003 entries from “the policy works” into “someone has this user’s password and the policy was the last line.”

Is it an attack?

Read the block together with the policy that caused it:

Location or country block — the credential was used from somewhere your organization does not allow. Unless the user is travelling, assume the password is exposed.
Legacy authentication block — a client using IMAP, POP3, SMTP AUTH or another legacy protocol presented working credentials. Spraying tools favour these protocols because they cannot do MFA; see the legacy-auth MFA bypass rule.
Device platform or app restrictions — often configuration (an unsupported device or app), occasionally an attacker on an unexpected platform.
Risk-based policies — Entra ID Protection rated the sign-in or the user as risky and the policy blocked it. Check riskLevelDuringSignIn and the user’s risk detections: the risk engine saw something the password check could not.
Report-only or newly enabled policies — a sudden jump in 53003 right after a policy change is usually rollout noise, not an attack.

How to investigate

Expand the policies on each blocked sign-in to see which policy fired, for which client, from where:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "53003"
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.result) == "failure"
| summarize Blocks = count(), Accounts = dcount(UserPrincipalName),
            SourceIPs = make_set(IPAddress, 10)
    by PolicyName = tostring(Policy.displayName), ClientAppUsed, Location
| order by Blocks desc

For blocks from unexpected countries or legacy clients, list the affected users and treat their passwords as known: reset, revoke sessions, and search for successful sign-ins from the same IPs to applications or locations the policy excludes — exclusions are where a blocked attacker goes next. Device-compliance blocks have their own code, AADSTS53000; the MFA-stage codes AADSTS50074 and AADSTS50076 carry the same “first factor passed” meaning.

Related codes

AADSTS53000 DeviceNotCompliant
AADSTS53001 DeviceNotDomainJoined
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.
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.
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.

Frequently Asked Questions

Which policy blocked the sign-in?: Open the sign-in event and check the Conditional Access tab, or read appliedConditionalAccessPolicies in a Graph export: each policy is listed with its result, and the ones with the result failure produced the block. In Log Analytics the same list is in the ConditionalAccessPolicies column of SigninLogs, which the query on this page expands.
Does AADSTS53003 mean the password was correct?: For an interactive username-and-password sign-in, yes in practice: Microsoft documents that Conditional Access policies are enforced after first-factor authentication is completed. For token refreshes and other non-interactive flows the first factor is an existing token rather than a password, so the conclusion applies to whatever credential the client presented.
Why do I see AADSTS53003 for IMAP, POP3 or SMTP?: A Conditional Access policy that blocks legacy authentication rejects those clients with 53003. The block is doing its job, but each entry is still a request that presented working credentials over a legacy protocol, which is typical of password-spraying tools. Group them by IP and user to see whether one source is cycling through accounts.
Is a location-based AADSTS53003 from another country a compromise?: It is a strong sign that the password is known outside your organization, because the block happened after the first factor. Reset the password, revoke the user's sessions and check whether the same account signed in successfully from any location or application the policy does not cover.

Find AADSTS53003 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