AADSTS53000 and AADSTS53003 both leave a user looking at an access-denied page after a perfectly good sign-in, but they point at different problems. One says the device didn't meet a requirement; the other says a policy refused to issue a token at all. In this post I'll show how to tell them apart, find the exact policy in the sign-in logs, and fix the usual causes.
Symptoms#
The user's password and MFA are accepted, and then access stops. In a browser, the error page explains that the resource can only be used from devices or apps that meet the organization's management policy, or that the sign-in worked but doesn't meet the criteria to access the resource. Desktop and mobile apps usually show a shorter message with the same code. Selecting More details on the error page reveals the correlation ID and timestamp you'll need later.
| Code | Name | What it means |
|---|---|---|
AADSTS53000 | DeviceNotCompliant | A policy requires a compliant device, and Microsoft Entra ID doesn't see this device as compliant. |
AADSTS53001 | DeviceNotDomainJoined | A policy requires a Microsoft Entra hybrid joined (domain-joined) device, and this device isn't recognized as one. |
AADSTS53003 | BlockedByConditionalAccess | A policy evaluated the sign-in and doesn't allow a token to be issued. A Block access grant is the classic cause. |
Why it happens#
Conditional Access is evaluated after first-factor authentication. For 53000 and 53001 the policy needs proof about the device, so two things must be true: the client has to present the device identity, and Entra ID has to hold the right state for that device.
- The device really isn't compliant. It isn't enrolled, it fails a setting, or it was just enrolled and its compliance hasn't been registered yet. Compliance also isn't evaluated properly if the user has no Intune license.
- The browser didn't send the device identity. Without it, even a compliant laptop looks like an unknown device. Private windows (InPrivate, Incognito) don't send it either.
- The device object isn't in the expected state. For 53001 this is usually a hybrid join that never completed.
- For 53003, a block policy matched on location, device platform, client app or risk. The platform condition is derived from information the client provides, such as the user agent, so an unexpected client can fall into a "block unsupported platforms" policy.
How to fix it#
1. Find the blocked sign-in#
In the Microsoft Entra admin center (Reports Reader is enough), go to Entra ID › Monitoring & health › Sign-in logs. Filter by the correlation ID, or by username, date and status Failure. If the event isn't on the interactive tab, check the non-interactive sign-ins.
2. Read the Conditional Access tab#
Every evaluated policy is listed with its result; the one showing Failure is your blocker. Select the ellipsis next to it: the left side shows what was collected at sign-in, the right side whether it satisfied the policy. Select the policy name to open its configuration.
3. Read the Device info tab#
- No device ID: the client didn't present device identity. Fix the browser (step 4) or the app.
- Device ID present, Compliant is No: fix compliance in Intune (step 5).
- Join type missing or unexpected (53001): troubleshoot device registration with
dsregcmd /status.
4. Fix browser device identity#
| Browser on Windows | What it needs |
|---|---|
| Microsoft Edge | Native support. The user must be signed in to the Edge profile with the work account that's connected to Windows. |
| Google Chrome | The Microsoft Single Sign On extension, or Chrome's CloudAPAuthEnabled policy. |
| Mozilla Firefox 91+ | "Allow Windows single sign-on for Microsoft, work, and school accounts" enabled (the WindowsSSO policy). |
On macOS, browser device identity depends on the Microsoft Enterprise SSO plug-in being deployed through MDM.
5. Fix compliance#
In the Microsoft Intune admin center, open Devices › All devices, select the device and check Device compliance to see which policy and setting is failing. Confirm the user has an Intune license, fix the setting, then sync the device from its page in the admin center, or on Windows from Settings › Accounts › Access work or school › account › Info › Sync. A freshly enrolled device can need a few minutes before its compliance is registered, so retry after a short wait.
6. For 53003, review the policy conditions#
Identify which location, platform, client app or risk condition matched. Then decide whether the block is correct, or whether the policy needs a narrower condition or a documented exclusion.
Verify the fix#
- Have the user retry in a normal browser window or the app. In the new sign-in event, the blocking policy should show Success, and Device info should show the device ID with Compliant and Managed set to Yes.
- Run the What If tool from Entra ID › Conditional Access › Policies › What If for the same user, app, device platform and client app. It lists the policies that apply and the grant controls they require. It doesn't check whether a real device is compliant, so pair it with the sign-in log.
Prevent it next time#
- Never scope a compliant-device or Block policy to all users and all resources without exclusions. Microsoft warns this can lock out admins who don't have an enrolled device. Always exclude your emergency-access accounts.
- Deploy browser settings with Intune: the Chrome extension or policy, Firefox's
WindowsSSOpolicy, and Edge sign-in. - Make sure every platform you allow has a compliance policy assigned, and know how the tenant-wide Mark devices with no compliance policy assigned as setting is configured.
- Roll out new device-based policies in report-only mode and review the Failure results before enforcing.