AADSTS53003 — "Access has been blocked by Conditional Access policies" means your credentials were accepted and then a policy refused to issue the token. This guide shows how to identify exactly which policy blocked the sign-in, and how to fix the cause rather than punching a hole in your security posture.
The Error
AADSTS53003: Access has been blocked by Conditional Access policies.
The access policy does not allow token issuance.
Microsoft's internal name for the code is BlockedByConditionalAccess. You may see it in a browser, in an Office application sign-in dialog, or in a PowerShell connection failure.
Why This Happens
Entra ID authenticates you first, then evaluates Conditional Access. AADSTS53003 comes from the second stage: authentication succeeded, and a policy decided the conditions of the sign-in were unacceptable.
A policy can block on any combination of:
- Device state — not enrolled, not compliant, not hybrid-joined
- Location — an untrusted network, a blocked country, an unexpected IP
- Client app — legacy authentication, or an app not on the approved list
- Sign-in risk — Entra ID Protection scored the attempt as risky
- Platform — an operating system the policy does not permit
- An outright block rule for a named application or user group
The important framing: this is your organization's policy working as intended. Something about the sign-in did not meet requirements. The job is to find out what, not to disable the protection.
If You're a User (Not an Admin)
Check the conditions you actually control, in this order:
- Are you on your normal device? Personal laptops and phones are the single most common trigger, because compliant-device policies exclude them by design.
- Are you on a VPN, hotspot, or traveling? Location-based policies block unfamiliar networks and countries. Disconnect the VPN and retry.
- Are you using an unusual app? Older mail clients and anything using legacy authentication are routinely blocked outright.
- Is your device up to date? A missed OS update or a disabled disk encryption setting can quietly drop a managed device out of compliance.
- Is your Company Portal or Intune enrollment still healthy? Opening Company Portal and letting it re-check compliance resolves a surprising share of cases.
If none of that helps, send IT the full error text, the Request ID, the timestamp including time zone, the account and the application. The Request ID is what lets them find your exact sign-in in seconds instead of trawling logs.
Admin Fix 1: Find the Policy That Blocked It
Do this first. Never guess from policy names.
Requires: Security Reader, Global Reader, or higher to read logs; Conditional Access Administrator or Global Administrator to change policies.
- Sign in to the Microsoft Entra admin center.
- Go to Monitoring (or Identity → Monitoring & health) → Sign-in logs.
- Filter by the affected user and narrow the date range to the reported time.
- Open the failed sign-in entry.
- Select the Conditional Access tab.
Every policy evaluated for that sign-in is listed with a result:
| Result | Meaning |
|---|---|
| Success | The policy applied and its controls were satisfied |
| Failure | The policy applied and blocked the sign-in — this is your culprit |
| Not applied | The policy's conditions did not match this sign-in |
| Not enabled | The policy is off or in report-only mode |
Expand the failing policy to see which grant control was not satisfied. That tells you the actual requirement — compliant device, MFA, approved app — rather than leaving you to infer it.
Admin Fix 2: Fix the Condition, Not the Policy
Once you know the control that failed, resolve it at the source:
| Failed requirement | Correct fix |
|---|---|
| Compliant device | Enroll the device in Intune, or resolve the compliance failure the Intune portal reports |
| Hybrid Entra join | Confirm the device is joined; dsregcmd /status on the device shows its join state |
| MFA | Have the user complete security-info registration at aka.ms/mfasetup |
| Approved client app | Move the user to a supported app — commonly replacing an old mail client with Outlook |
| Trusted location | Add the site's egress IP range to named locations, if it genuinely is a trusted office |
| Sign-in risk | Review the detection in Entra ID Protection and remediate or dismiss it deliberately |
This is the part that separates a fix from a workaround. Enrolling the device solves the problem permanently for that user and everyone after them; excluding them solves it once and leaves a hole.
Admin Fix 3: Exclusions — Use Sparingly
Sometimes an exception is legitimate: a break-glass account, a service scenario, a genuinely unsupported edge case.
When you must:
- Open the policy in Entra admin center → Protection → Conditional Access → Policies.
- Under Assignments → Users, add an exclusion.
- Exclude a named group, never an individual, so membership is auditable.
- Record why the exclusion exists and when it will be reviewed.
Two rules worth holding to. Always keep at least one excluded break-glass account — a cloud-only Global Administrator with a long, stored credential — so a bad policy cannot lock every administrator out of the tenant simultaneously. And never exclude a user permanently to close a ticket; exclusions compound until the policy protects nobody, and nobody notices until an audit.
Verify the Fix
- Have the user sign out fully and retry — ideally from a private browser window, since an existing session can mask the change.
- Re-check the sign-in logs for a new entry. The Conditional Access tab should now show the previously failing policy as Success.
- Use the What If tool to confirm before the user tries: Protection → Conditional Access → What If, enter the user, app, and conditions, and it reports which policies would apply and why.
Policy changes generally take effect within minutes, but cached tokens can persist — a full sign-out matters here.
Prevent It Coming Back
- Roll out new policies in report-only mode first. They evaluate and log without enforcing, so you see exactly who would have been blocked before anyone actually is.
- Use the What If tool before enabling, not after the tickets arrive.
- Maintain break-glass accounts excluded from all Conditional Access policies, with monitored, stored credentials.
- Monitor device compliance proactively. Compliance drift is the most common cause of a sudden AADSTS53003 for a user who changed nothing.
- Tell people what changed. Most of these tickets are avoidable with a heads-up before a policy tightens.
- Review exclusions on a schedule. Every exclusion is a documented decision or an accident waiting to be found by an auditor.
Related Errors
| Code | Meaning |
|---|---|
AADSTS53000 | Policy requires a compliant device and the device isn't compliant — enroll with an approved MDM such as Intune |
AADSTS53001 | Policy requires a domain-joined device and the device isn't domain joined |
AADSTS530035 | Blocked by security defaults, typically legacy authentication — not a Conditional Access policy at all |
AADSTS50076 | Multifactor authentication required — sign-in incomplete rather than blocked |
AADSTS50158 | An external security challenge was not satisfied, such as terms of use or a third-party MFA provider |
Conditional Access frequently blocks PowerShell connections too. If you hit this connecting to Exchange Online, see how to install and connect to Exchange Online PowerShell, which covers the connection errors and the modern authentication requirements.