AADSTS53003 - Access Blocked by Conditional Access
Azure AADSTS53003 is a policy-based rejection. It indicates that while the user’s credentials were valid, the sign-in attempt was blocked by a specific Microsoft Entra Conditional Access policy due to untrusted location, non-compliant device, or high-risk signals.
Last reviewed: April 6, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Access Blocked by Conditional Access Mean?
AADSTS53003 is the bouncer of the Entra ecosystem. In a Zero Trust model, a password is only one signal. Entra ID evaluates other signals, such as whether the device is managed by Intune or whether the user is signing in from an approved country, before granting access. If any of these signals fail a block policy, AADSTS53003 is returned. Unlike AADSTS50076, which asks for MFA, AADSTS53003 is a terminal state. The user cannot proceed without changing their context, such as switching to a corporate laptop, or having an admin adjust the policy.
Common Causes
- -Location-Based Blocking: The user is attempting to sign in from a country or IP range that is explicitly blocked.
- -Device Non-Compliance: The policy requires a compliant or hybrid-joined device, but the user is on a personal or unmanaged machine.
- -Risk-Based Denial: Microsoft Identity Protection has flagged the sign-in as high risk, such as leaked credentials or impossible travel, and a block policy was triggered.
- -Unsupported Client App: The user is using a legacy mail client or unapproved browser that does not meet policy requirements.
- -Specific App Restrictions: A policy blocks access to a sensitive app outside the corporate network or other approved context.
How to Fix Access Blocked by Conditional Access
- 1Consult The Sign-In Logs: Go to Entra ID > Sign-in logs, find the failed attempt, and inspect the Conditional Access tab. It will identify the exact policy that blocked access.
- 2Check Device Status: If the policy requires compliance, ensure the device is enrolled in Intune and has not fallen out of compliance due to missing updates or disabled protections.
- 3Use A Trusted Network: If the user is on a VPN or public Wi-Fi, disconnect and retry from a known-good corporate or home network.
- 4Remediate Risk: If the block is risk-based, the user may need to change their password or complete another remediation path to lower their risk score.
Step-by-Step Diagnosis for Access Blocked by Conditional Access
- 1Open the Microsoft Entra admin center and locate the specific AADSTS53003 failure in the logs.
- 2Identify the policy name listed in the Conditional Access tab of the sign-in record.
- 3Examine the signals gathered during the attempt, including detected IP, location, device ID, device trust state, and client app type.
- 4Use the Conditional Access What If tool to simulate the user’s sign-in and confirm why the policy is triggering.
Blocking vs. Granting with Controls
- -AADSTS53003 (Block): The policy mode is set to block. There is no direct path forward for the user in that session.
- -AADSTS50076 (Grant + MFA): The policy mode is grant, but requires MFA. The user can satisfy the control and continue.
Device Compliance Logic
- -If a policy requires a compliant device, the browser must be able to prove device identity. On Chrome or Edge this often depends on proper enterprise sign-in integration or the Microsoft Single Sign On extension.
Implementation Examples
try {
const result = await msalInstance.acquireTokenSilent(request);
} catch (error) {
if (error.errorCode === "AADSTS53003") {
// Redirect to a page explaining that a compliant device or trusted context is required
window.location.href = "/access-denied-policy-info";
}
}Seen in Production
Traveler blocked by geo restriction
Frequency: medium
Example: An employee travels to a country listed on the company’s blocked locations list. They try to check email and hit AADSTS53003.
Fix: The user must wait until they are in an approved region or an admin must grant a temporary exclusion if policy allows it.
Non-compliant OS version triggers a block
Frequency: high
Example: A policy requires the latest Windows patch level. A user ignores update prompts for two weeks, Intune marks the device non-compliant, and Entra returns AADSTS53003.
Fix: The user must update the operating system and wait for Intune to sync the compliant state again.
Debugging Tools
- -Entra ID What If Tool: Best simulator for Conditional Access troubleshooting.
- -Microsoft Intune Portal: Useful for verifying device compliance state and why a device fell out of policy.
- -Azure Monitor or Log Analytics: Useful for KQL queries when investigating broad denial patterns.
How to Verify the Fix
- -Confirm the user can sign in successfully once they meet the policy requirements, such as using a managed laptop or an approved location.
- -Verify in sign-in logs that the specific policy now shows a non-blocking outcome such as Not Applied, Success, or Allow with required controls satisfied.
- -Ensure the user agent and browser session are correctly presenting device state to Entra ID if compliance is part of the requirement.
How to Prevent Recurrence
- -Use Report-Only Mode: Deploy new Conditional Access policies in report-only mode first so you can audit the impact before enabling block.
- -Exclude Break-Glass Accounts: Keep emergency access accounts excluded from strict block policies to avoid tenant-wide lockout.
- -Educate Users: Tell users which apps require corporate devices, trusted networks, or specific browsers so they know what context is expected.
- -Pro tip: If AADSTS53003 appears for a user who is already on a compliant device, the problem is often that the browser is not sharing device identity properly with Entra ID.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.