Conditional Access Block Troubleshooting Guide (AADSTS53003)

AADSTS53003 means a Microsoft Entra Conditional Access policy decided not to issue a token, and the person or workload on the other end usually has no idea which policy or why. The error is the intended result of a block control, so the question is never "how do I make it go away" but "is this block correct, and if not, which condition matched that should not have". This guide works through the symptom, the likely causes from most to least common, how to read the sign-in log and the What If tool to prove the cause, safe fixes and how to stop the same block recurring. It covers users, guests and single-tenant service principals, and is written for identity administrators, service desk leads and engineers who own Conditional Access policy.

Key takeaways

• 53003 is a policy decision, not a fault. Microsoft defines it as BlockedByConditionalAccess: the access policy does not allow token issuance. Find the policy before changing anything.
• The sign-in log tells you which policy. The Conditional Access tab of the failed event lists every evaluated policy and its result, and the policy details view shows which conditions matched.
• Neighbouring codes need different fixes. 53000 (device not compliant), 53001 (not domain joined), 53002 (unapproved app) and 53004 (proof-up blocked due to risk) are grant-control failures, not block-access policies.
• What If simulates, it does not replay. It evaluates only enabled and report-only policies, ignores service dependencies and reports "does not apply" when you leave out a condition the policy uses.
• Never fix a block by adding a broad exclusion. Exclusions are where Conditional Access coverage quietly decays; scope any exception to the exact identity, app and condition, and review it.

What the error tells you

Microsoft's error reference describes AADSTS53003 as BlockedByConditionalAccess: access has been blocked by Conditional Access policies, the access policy does not allow token issuance, and if this is unexpected the administrator should look at the policy that applied to the request. That is the whole story the end user sees. Behind it, at least one policy in the On state matched the sign-in on every configured condition (users or workload identities, target resources, network, device platforms, client apps, risk, filters) and its grant control was Block access. Policies in Report-only mode never produce 53003; they only record what would have happened.

Two practical consequences follow. First, every condition in the blocking policy was satisfied, so the cause is always one of: the identity was in scope, the resource was in scope, or a condition such as location or platform evaluated differently from what you expected. Second, the block happened at token issuance, so a client may report it later or in a different form, for example a desktop app that shows a generic access page or a script that surfaces the raw token endpoint response.

Related Conditional Access error codes

The descriptions below follow Microsoft's error code reference and its Conditional Access troubleshooting article, read on 11 November 2026. Codes carry the AADSTS prefix in responses, and Microsoft notes that messages can change, so confirm wording at https://login.microsoftonline.com/error?code=53003.

Likely causes, most to least common

1. Location condition: a policy blocks access from outside named locations or from specific countries, and the sign-in came from an IP address that is not in the trusted ranges. Typical triggers are a new office egress IP, a VPN or proxy change, IPv6 traffic that the named location only lists as IPv4, or a travelling user.
2. Legacy authentication or client app condition: a block policy targets "Exchange ActiveSync clients" and "Other clients", and an old mail client, scanner, printer or script still uses basic authentication.
3. Device platform condition: a policy blocks unknown or unsupported platforms, and the client sends a user agent that Entra cannot classify, common with command-line tools and some browsers.
4. Service dependency: the user opened an app that is allowed, but that app requests a token for another resource that a block policy covers. Microsoft's example is the Azure portal calling Azure Resource Manager; the sign-in log's Audience field shows every resource requested.
5. Workload identity policy: a single-tenant service principal is blocked by a location or service principal risk policy. Here the sign-in appears under Service principal sign-ins, with a failure reason that access was blocked due to Conditional Access policies.
6. Scope drift: a group used in the policy's include list gained members through dynamic rules or nesting, or an exclusion group lost a member, so a new set of identities came into scope.
7. Risk-based block: a policy blocks high sign-in risk or high user risk, and ID Protection raised a detection. See the Microsoft Entra ID Protection guide.

How to diagnose: the sign-in log first

Microsoft's troubleshooting article gives the sequence, and it works for nearly every 53003:

1. Collect identifiers: ask the user for the Correlation ID, Request ID and timestamp from the error page's details link, or take correlation_id and trace_id from the token response for a workload.
2. Open the event: sign in to the Microsoft Entra admin center as at least a Reports Reader, go to Entra ID, Monitoring & health, Sign-in logs, and filter by Correlation ID, username, date, resource, or the Conditional Access filter set to failures. Use the Service principal sign-ins tab for app-only sign-ins.
3. Read the Conditional Access tab: it lists the policies evaluated for the sign-in and their outcome. The policy with a failure result and a Block grant control is your culprit. Select its name to open the configuration.
4. Find the matching condition: select the ellipsis next to the policy to open the policy details. Microsoft describes a split view: sign-in data on the left, and on the right whether that data meets each of the policy's requirements. A policy applies only when all its configured conditions are met.
5. Check the client details: the Basic Info, Location, Device Info, Authentication Details and Additional Details tabs show the IP address, resolved location, platform, client app and device state that Entra actually saw, which is often not what the user believes.
6. Use Troubleshooting and support: the tab may state the reason directly, and the Sign-in diagnostic is available under Basic info, Troubleshoot Event.

When to use the What If tool

What If, under Entra ID, Conditional Access, Policies, What If, simulates a sign-in and lists the policies that would apply (with their grant and session controls) and those that would not (with the first unmet condition as the reason). It accepts a user, an agent identity (in preview) or a single-tenant service principal, and requires a target resource, device platform and client app. Use it to test a proposed fix before you change policy, and to check how a new user or workload will be treated. Know its limits, as Microsoft documents them: it evaluates only enabled and report-only policies, it does not test service dependencies, it needs every condition the policy uses or it may wrongly say a policy does not apply, and apps must be specified by App ID because groups such as Office 365 do not match.

Fixes by cause

• Location: if the IP address is legitimately yours, add it to the correct named location (including IPv6 ranges) and mark it trusted only if it really is. If the user is travelling, use a time-bound exception through a reviewed group rather than editing the country list.
• Legacy authentication: do not exempt the client. Move it to modern authentication, or for devices such as multifunction printers use a supported relay pattern. See the Conditional Access Guide for baseline policies.
• Device platform: decide whether unknown platforms should be allowed for that app. If a tool legitimately sends an unrecognised user agent, scope a narrow policy for that app rather than allowing unknown platforms everywhere.
• Service dependency: align the policies so the dependent resource carries the same controls as the parent app, as Microsoft recommends including all related apps and resources.
• Workload identity: confirm the call came from an expected location. If the location list is out of date, update it; if not, treat the call as a possible stolen credential. Policies for workload identities need the Workload Identities Premium licence to create or change, apply only to single-tenant service principals assigned directly (not through groups), and offer Block as the only grant control. Use the Object ID from Enterprise applications when scoping, not the one from App registrations.
• Scope drift: fix the group membership or rule rather than the policy, and record why.
• Risk: investigate the detection first; dismiss or remediate the risk only once you are satisfied it is benign.

Rollout, testing and rollback for policy changes

1. Change in report-only first: clone the policy with the fix in report-only mode, or switch a new policy to report-only, and watch real sign-ins for at least several business days.
2. Simulate edge cases: run What If for emergency accounts, a service principal, a guest and a user on an unmanaged device.
3. Pilot ring: enforce for an IT pilot group, then a business pilot, then everyone.
4. Rollback: keep the previous policy definition (export it as JSON through Microsoft Graph or your configuration-as-code tooling) so you can restore it, and know that switching a policy Off or back to report-only takes effect on new token requests.
5. Lockout plan: Microsoft advises checking whether another administrator who is not blocked can disable the policy, and otherwise raising a support request, which Microsoft reviews before updating the blocking policy. Two excluded, monitored emergency access accounts avoid reaching that point. See the Break-Glass Account Guide.

Microsoft also lists configurations to avoid because they cause tenant-wide blocks: Block access for all users and all resources, requiring a compliant or hybrid joined device for all users and resources, and requiring app protection policy for all users and resources. Small tenants with a single administrator are most exposed to these; larger tenants should require peer review for any change to a policy scoped to all users.

Where identity fits

Service principals and automation accounts are where Conditional Access blocks are hardest to see and where exclusions accumulate. Every exclusion added to make a 53003 go away is an identity that sits outside the control plane, which is exactly what attackers look for when they abuse valid cloud accounts (ATT&CK T1078.004) or stolen application tokens (T1528). Review exclusions on a schedule; see How to Find Accounts Excluded From MFA and Conditional Access.

Detection and measurement

• Logs: export interactive, non-interactive and service principal sign-in logs, plus audit logs, to Log Analytics or your SIEM. Filter for result code 53003 and group by policy, application and IP address.
• Policy change alerts: alert on audit events that add, update or delete Conditional Access policies or named locations, and on changes to exclusion groups.
• Report-only reporting: use per-policy impact and the Conditional Access insights and reporting workbook to see what a report-only policy would block.

Common failure patterns

• Exclusion as the default fix: the service desk adds users to an exclusion group to close tickets, and months later the group holds hundreds of members.
• Testing only with What If: a change that passes What If still blocks because of a service dependency the tool does not evaluate.
• Named locations that miss IPv6: users on dual-stack networks hit location blocks intermittently, depending on the path their traffic takes.
• Scoping workload identity policies through groups: Microsoft states such policies are not enforced for service principals in groups, so the policy looks correct and does nothing, or a later direct assignment surprises everyone.
• Editing live policies in a crisis: changes made during an outage without a saved copy of the previous version cannot be rolled back cleanly.

Framework mapping

Practitioner checklist

• Get the Correlation ID, Request ID and time for every 53003 report.
• Identify the blocking policy and the matching condition in the sign-in log before acting.
• Check the Audience field for service dependencies.
• Test any fix with What If, supplying every condition the policy uses.
• Stage policy changes in report-only and keep the previous definition for rollback.
• Scope exceptions to the exact identity, app and condition, time-bound and owned.
• Assign workload identity policies to service principals directly, by Enterprise application Object ID.
• Keep two excluded, monitored emergency access accounts and test them.
• Alert on Conditional Access policy, named location and exclusion group changes.

Standards and references

• Microsoft Learn: Troubleshooting sign-in problems with Conditional Access
• Microsoft Learn: Microsoft Entra authentication and authorization error codes
• Microsoft Learn: Conditional Access What If tool
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Service principal sign-ins in Microsoft Entra ID
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)

Related NHI Mgmt Group resources: Conditional Access Guide, Entra ID Sign-In and Audit Log Detection Guide, Entra Service Principal Sign-In Errors Guide (AADSTS7000215, 7000222, 700016), How to Find Accounts Excluded From MFA and Conditional Access.