AADSTS53003 Blocked by Conditional Access: A Read-First Sign-In Log Triage

A user forwards a screenshot: "You cannot access this right now" and, under More details, AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Someone in chat suggests excluding the user "just for today."

53003 is the generic BlockedByConditionalAccess result. It tells you that a policy with a Block control applied to this sign-in. It does not tell you which policy or which condition matched. This post is a read-first order to answer those two questions from the sign-in log before anyone edits a policy. Every step below only reads.

TL;DR

• Get the Request ID / Correlation ID / timestamp from the error page first. It turns a log hunt into a one-row lookup.
• Open that exact event in Sign-in logs and read the Conditional Access tab: the policy with result Failure and grant control Block is your answer.
• Check the non-interactive tab too. A lot of 53003 noise comes from Outlook, Teams and OneDrive refreshing tokens in the background.
• The usual causes are: location (often IPv6 or a new egress IP), device platform, client app / legacy auth, the resource audience, or a scope that is wider than intended.
• Fix the condition or the assignment. An exclusion is the last resort, not the first.

53003 vs its neighbours

Several CA error codes look alike on a helpdesk ticket. Read the number before you pick a runbook:

If the code is 53000 or 53001, this isn't a block policy. The user hit a grant requirement, and that is a device problem, not a policy-scope problem.

Step 1: Capture the event identifiers

On the error page, More details shows Request ID, Correlation ID and the timestamp (UTC). Ask the user for that block, not just the headline.

No screenshot? Filter by Username and Status = Failure over the reported time window instead. That's slower but works.

Step 2: Read the event's Conditional Access tab

Entra admin center > Entra ID > Monitoring & health > Sign-in logs (Reports Reader is enough).

1. Filter by Request ID or Correlation ID if you have it. Otherwise Username + date + Status = Failure.
2. Open the event and check Basic info: Sign-in error code should read 53003.
3. Open the Conditional Access tab. Each policy shows Success, Failure, Not applied, or a report-only result.
4. The policy with Failure and a Block grant control is what stopped the token.
5. Select the ellipsis next to that policy to see policy details. The left side shows what the sign-in sent (location, platform, client app, device). The right side shows which conditions matched.

That last view is usually the whole answer. A CA policy only applies when all its configured conditions match, so the matched list tells you exactly which condition to question.

If the event still doesn't make sense, Basic info > Troubleshoot Event opens the sign-in diagnostic.

Don't confuse this with report-only. A policy in Report-only can show Report-only: Failure on the same event without blocking anything. Only an On policy produces 53003. (Reading report-only results is its own topic: CA report-only results, logs vs On.)

Step 3: Check the non-interactive and service principal tabs

The Sign-in logs blade has separate tabs: User sign-ins (interactive), User sign-ins (non-interactive), Service principal sign-ins and Managed identity sign-ins.

Background 53003 rows after a new location or platform policy are common. They mean the policy is working, not that it's broken. Find out who they belong to before you treat them as an outage.

Step 4: The five usual causes

Using the matched conditions from Step 2:

Two from Microsoft's own troubleshooting guide are easy to miss:

• Service dependencies. The app you see (say, Azure portal) may call a resource (Azure Resource Manager) that a different policy blocks. Read the resource, not only the app.
• Audience reporting. One Teams sign-in requests several resources. A policy can apply because one audience in the list is in scope.

Step 5 (optional): Pull 53003 events with read-only Graph

If you need the pattern, not one event (all 53003 failures in the last 24 hours, say), a read-only pull helps. Scope: AuditLog.Read.All. The sign-in log API needs Entra ID P1, which you already have if you use Conditional Access.

Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome

$since = (Get-Date).ToUniversalTime().AddHours(-24).ToString('yyyy-MM-ddTHH:mm:ssZ')
$rows = Get-MgAuditLogSignIn -Filter "status/errorCode eq 53003 and createdDateTime ge $since" -All

$rows | ForEach-Object {
    $blocking = $_.AppliedConditionalAccessPolicies |
        Where-Object { $_.Result -eq 'failure' } |
        Select-Object -ExpandProperty DisplayName
    [pscustomobject]@{
        TimeUtc   = $_.CreatedDateTime
        User      = $_.UserPrincipalName
        App       = $_.AppDisplayName
        Resource  = $_.ResourceDisplayName
        ClientApp = $_.ClientAppUsed
        IP        = $_.IpAddress
        OS        = $_.DeviceDetail.OperatingSystem
        Policy    = ($blocking -join '; ')
    }
} | Sort-Object Policy, User | Format-Table -AutoSize

This returns interactive sign-ins only. For background token refreshes, use the beta endpoint with a signInEventTypes filter, or check the portal's non-interactive tab. Grouping the output by Policy and IP usually shows straight away whether this is one user, one office, or one legacy client.

Step 6: When a change is justified

Only after you can name the policy and the condition:

If you do add an exclusion, give it an owner and an expiry date, and run the change through report-only or What If first. Keep your break-glass accounts excluded separately. They are not a workaround for user tickets.

FAQ

Does AADSTS53003 mean the user's password or MFA is wrong?
No. 53003 is issued after authentication, when a Conditional Access policy with Block access matches. Password and MFA problems use other codes (50126, 50074, 50076 and so on).

Why does the user get 53003 in Teams but not in a browser?
The Teams client and the browser can send a different client app, device platform or location. Teams also requests several resources, and the block may be on one of them. Compare the two sign-in events side by side.

Why are there hundreds of 53003 failures but no complaints?
Most likely non-interactive token refreshes from a device or client the policy now blocks on purpose. Check the non-interactive tab and group by device and IP.

The Authentication Details tab is empty on the 53003 event. Is something broken?
Not necessarily. The block happens at token issuance, so you may not see the full authentication-method detail you'd expect on a successful sign-in. Use Basic info, Location, Device info and the CA policy details instead.

Can I tell users to "just use a different network"?
That only works around the condition. If the office's real egress IP is missing from a named location, fix the named location so the next 40 users don't file the same ticket.

Related posts

• Conditional Access report-only results: logs vs On
• Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass
• Entra ID break-glass accounts: best practices after mandatory MFA
• AzureAdPrt : NO in dsregcmd /status: a read-first Primary Refresh Token triage

Free checklist

Most 53003 tickets after a rollout come from a condition nobody checked in pilot: an office IP, a legacy client, an unknown platform. The free Conditional Access pre-enforcement checklist puts named locations, legacy-auth clients, pilot groups and report-only review on one page so you catch them before you enforce:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts53003-blocked-by-conditional-access

If you want a starting policy set and the exclusions pattern written down, the Entra ID Conditional Access Starter Pack has a starter policy library, a break-glass and exclusions playbook, and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts53003-blocked-by-conditional-access

Admin Pack Studio; not affiliated with Microsoft. The portal steps and the Graph snippet above only read. Test any Conditional Access change in report-only or with What If before you turn it On, and never paste full sign-in tokens or user IP lists into public tickets.