AADSTS53003 blocked by Conditional Access: find the policy and fix it

AADSTS53003 means a Conditional Access policy matched the sign-in and its control was Block access, so Microsoft Entra ID refused to issue a token even though the credentials were correct. To fix it, take the correlation ID from the error page, find that event in Entra ID > Monitoring & health > Sign-in logs, open the Conditional Access tab to see which policy failed and which condition matched, then change the sign-in conditions or correct the policy.

Who this is for and what you will have at the end

This guide is for help desk staff and identity administrators handling "Access has been blocked by Conditional Access policies" tickets from Outlook, Teams, the Azure portal, line-of-business apps or guest users. It also covers the case where a new block policy unexpectedly hits many users at once.

At the end you will have:

• A clear picture of what 53003 means and how it differs from the other 53xxx codes.
• A step-by-step method to trace a user's error to the exact policy and matching condition.
• A Log Analytics query and a Microsoft Graph PowerShell command for finding all 53003 events.
• Fixes for the common block patterns and a safe way to test policy changes before enforcing them.

What AADSTS53003 means

Microsoft's error reference defines AADSTS53003 as BlockedByConditionalAccess: access has been blocked by Conditional Access policies, and the access policy doesn't allow token issuance. In practice the user's password and MFA can be perfect and the sign-in still fails, because the decision happens after authentication.

Conditional Access policies work as if-then statements. A policy applies only when all its configured conditions are satisfied. If a policy that applies has the Block access control, the result is 53003. The other grant controls produce different codes, which tell you the user has something to fix:

If the code is 53000 or 53009, the fix is in Intune, not in the Conditional Access policy.

Prerequisites

• At least Reports Reader to read sign-in logs.
• To see which policies applied, a role that can read Conditional Access data: Global Reader, Security Reader, Security Administrator or Conditional Access Administrator. Without one, sign-in events are visible but the applied policies aren't.
• Conditional Access Administrator to change policies.
• Optional: sign-in logs in a Log Analytics workspace, and the Microsoft Graph PowerShell SDK. Reading sign-in logs through Microsoft Graph requires a Microsoft Entra ID P1 or P2 licence.

Step 1: Get the details from the user

The error page has a More details link that reveals troubleshooting information. Ask the user for a screenshot or the text, specifically:

• Correlation ID and Request ID
• Timestamp
• App name and the account they used

The correlation ID is the quickest way to the exact event. If the user can't provide it, the username and time range are enough to start.

Step 2: Find the blocking policy in the sign-in logs

1. Sign in to the Microsoft Entra admin center as at least a Reports Reader (plus a role that can read Conditional Access data).
2. Browse to Entra ID > Monitoring & health > Sign-in logs.
3. Filter by Correlation ID, or by Username, Date and Resource. Add the Conditional Access filter and set it to failures to limit the results.
4. Open the failed event and confirm the sign-in error code is 53003.
5. Select the Conditional Access tab. Policies with a Failure result are the ones that blocked the sign-in.
6. Select the ellipsis next to the failed policy. The left side shows details collected at sign-in, and the right side shows whether each detail satisfied the policy's conditions. This tells you which condition matched: user, application, location, device platform, client app or another condition.
7. Check the Basic info, Location, Device Info, Authentication Details and Additional Details tabs for the client, IP address, device and app actually used.
8. If it's still unclear, open Basic info > Troubleshoot Event to run the sign-in diagnostic.

Selecting the Policy Name opens the policy's configuration for review.

Check the resource, not just the app

The app the user opened isn't always the resource being blocked. Microsoft's example: the application is Azure portal, but the resource is Azure Resource Manager. Teams likewise requests tokens for Exchange Online, SharePoint and other services. When you select a policy on the Conditional Access tab, the Audience list shows every resource requested in the sign-in. If one of them is in scope of a block policy, the sign-in fails even though the user thinks they only opened Teams.

Step 3: Find every 53003 event

When the problem affects more than one user, query the logs instead of opening events one at a time.

In Log Analytics, ResultType holds the error code as a string and ConditionalAccessPolicies holds the evaluated policies:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "53003"
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.result) == "failure"
| summarize Users = dcount(UserPrincipalName), Events = count()
    by PolicyName = tostring(Policy.displayName), AppDisplayName, ResourceDisplayName, ClientAppUsed
| order by Events desc

With Microsoft Graph PowerShell, the sign-in list supports filtering on status/errorCode and on createdDateTime:

Import-Module Microsoft.Graph.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All", "Policy.Read.All"
 
$since = (Get-Date).ToUniversalTime().AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "status/errorCode eq 53003 and createdDateTime ge $since" -All |
    Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, IPAddress, CorrelationId,
        @{ n = 'BlockingPolicies'; e = { ($_.AppliedConditionalAccessPolicies | Where-Object Result -eq 'failure').DisplayName -join '; ' } }

The appliedConditionalAccessPolicies property is only returned when the app has Policy.Read.All, Policy.Read.ConditionalAccess or Policy.ReadWrite.ConditionalAccess and the signed-in user holds a role that can read Conditional Access data.

If many users started failing at the same time, check the audit log for a recent policy change: Entra ID > Monitoring & health > Audit logs, Service filter Conditional Access, activity Update Conditional Access policy or Add Conditional Access policy. The Modified Properties tab shows the old and new JSON. If the change was a mistake, restoring the previous policy version with Entra Backup and Recovery is faster than rebuilding it by hand.

Step 4: Match the block to its cause

Most 53003 events come from a handful of policy patterns. Use the matched condition from Step 2 to pick the right row.

Note that the device platform condition is based on the user agent string. Microsoft recommends pairing platform-based block policies with another policy, such as device compliance or app protection, because user agents can be spoofed.

Step 5: Fix safely

Fix the user's conditions first. If the policy is doing its job, for example blocking a sign-in from a disallowed country, the correct fix is for the user to sign in from an allowed location or device. Don't add per-user exclusions to resolve individual tickets; exclusions accumulate and are rarely removed.

Test policy changes before enforcing them. If the policy is wrong:

1. Run the What If tool at Entra ID > Conditional Access > Policies > What If. Provide the user, target resource (by App ID; groups such as Office 365 don't match), device platform and client app, plus the location and other conditions from the sign-in event. The report lists applying policies with their controls and, for non-applying policies, the first condition that wasn't satisfied.
2. Make the change on a copy of the policy in Report-only mode, or switch the policy to report-only while you adjust it.
3. Review results on the Report-only tab of sign-in events. Report-only: Failure means the policy would block.
4. Switch Enable policy back to On only when the results are correct.

The What If tool doesn't test service dependencies, so a Teams simulation doesn't consider a policy that applies to Exchange Online.

Guest users and cross-tenant blocks

If the Conditional Access tab shows no failed policy in your tenant, check Basic info for the Home tenant and Resource tenant IDs and the cross-tenant access type. When the resource tenant isn't yours, a policy in the other organization's tenant evaluated the sign-in, and only that organization's administrators can see or change it. A common variant is a user whose app tries to sign in to the wrong tenant, such as a previous employer's, with a cached account; signing out of that account and choosing the correct one resolves it.

When an administrator is locked out

If a block policy locks out administrators, Microsoft's guidance is:

• Check whether another administrator isn't blocked yet. An administrator with access can disable the policy affecting your sign-in.
• If no administrator in the organization can update the policy, open a support request. Microsoft support reviews it and, after confirming, updates the Conditional Access policies that prevent access.

Emergency access accounts that are excluded from every block policy exist for exactly this situation, so the first option is always available.

Microsoft specifically warns against policies that target all users and all resources with Block access, which blocks the entire organization. The Zero Trust remote access architecture describes how block policies fit with device and network controls without creating that single point of failure.

Troubleshooting quick reference

If you open a support case, include the request ID, time and date from the sign-in event.

Checklist

• Correlation ID, request ID, timestamp and app collected from the user.
• Sign-in event found; error code confirmed as 53003.
• Failed policy and matched condition identified from the Conditional Access tab.
• Audience checked for service dependencies.
• Bulk impact checked with Log Analytics or Get-MgAuditLogSignIn; audit log reviewed for recent changes.
• Fix applied to the user's conditions, or the policy corrected with What If and report-only first.
• Guest cases checked for home and resource tenant.
• Emergency access accounts excluded from every block policy.

References

• Microsoft Entra authentication and authorization error codes
• Troubleshoot sign-in problems with Conditional Access
• The Conditional Access What If tool
• Analyze Conditional Access policy impact (report-only mode)
• Conditional Access: Grant
• Block unknown or unsupported device platform
• Block authentication flows with Conditional Access policy
• Sign-in log activity details
• View applied Conditional Access policies in Microsoft Entra sign-in logs
• List signIns (Microsoft Graph)
• appliedConditionalAccessPolicy resource type
• SigninLogs table reference
• Use audit logs to troubleshoot Conditional Access policy changes