AADSTS53000: Device not compliant

What does AADSTS53000 mean?

DeviceNotCompliant: Conditional Access policy requires a compliant device, and the device isn’t compliant. The user must enroll their device with an approved MDM provider like Intune. For additional information, please visit Conditional Access device remediation.

Conditional Access only evaluates after the first factor succeeds. So a 53000 row means the username and password (and any earlier step) were accepted, and the device grant control is what stopped the sign-in. ConditionalAccessStatus on these rows is failure.

Is it an attack?

Usually not. Most 53000 rows are users on a personal laptop or phone, a new device that hasn’t finished Intune enrollment, or a device that has drifted out of compliance.

The security reading comes from what the code proves: someone with a working credential tried to use it from a device you don’t manage. That is exactly what an attacker’s machine looks like.

Pattern	Likely meaning
Known user, known device, compliance recently lapsed	Benign. Fix the device.
New user onboarding, first days	Benign. Device not enrolled yet.
Privileged account, device never seen before, unfamiliar IP or country	Investigate. The credential works and is being used off-estate.
53000 shortly after a phishing click, or after 50126 failures from the same IP	Treat the password as compromised.
53000 in non-interactive logs from an unexpected IP	A refresh token being redeemed from an unmanaged device. Possible token replay (reasoning, not a Microsoft statement).

Why it matters: an adversary-in-the-middle phishing kit can capture a password, the MFA result and the session cookie, but it runs on the attacker’s infrastructure, not on an enrolled device. A compliant-device requirement is one of the controls that still holds after MFA is phished. A 53000 from a source that isn’t the user, for an account that otherwise passed MFA, is that control working, and a reason to ask how the earlier layers were passed.

How do I find it in my logs (KQL)?

Who is hitting the compliant-device requirement, and from which devices:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "53000"
| extend DeviceId    = tostring(DeviceDetail.deviceId),
         DeviceName  = tostring(DeviceDetail.displayName),
         OS          = tostring(DeviceDetail.operatingSystem),
         TrustType   = tostring(DeviceDetail.trustType),
         IsCompliant = tostring(DeviceDetail.isCompliant),
         Country     = tostring(LocationDetails.countryOrRegion)
| summarize Attempts = count(),
            IPs = make_set(IPAddress, 10),
            Countries = make_set(Country, 5),
            Apps = make_set(AppDisplayName, 5)
          by UserPrincipalName, DeviceId, DeviceName, OS, TrustType, IsCompliant
| sort by Attempts desc

An empty DeviceId means the device isn’t registered in Entra at all, which is the more interesting case for an attacker machine.

An unregistered device was blocked, then the same user from the same IP succeeded somewhere else on the same day. That can mean the credential reached an app or client the device policy doesn’t cover:

let blocked =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "53000"
    | where isempty(tostring(DeviceDetail.deviceId))
    | summarize BlockedIPs = make_set(IPAddress) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "0"
| join kind=inner blocked on UserPrincipalName
| where set_has_element(BlockedIPs, IPAddress)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed,
          ConditionalAccessStatus, DeviceDetail
| sort by TimeGenerated asc

Run the first query against AADNonInteractiveUserSignInLogs as well. There DeviceDetail and LocationDetails are string columns, so wrap them: parse_json(DeviceDetail).deviceId.

The DeviceDetail property names above (deviceId, displayName, operatingSystem, trustType, isCompliant) follow the Microsoft Graph signIn device detail object. Check them against one row in your own workspace before building a rule on them.

How does Conditional Access affect it?

• 53000 is produced by Conditional Access. Open the sign-in, select the Conditional Access tab, and Microsoft’s troubleshooting guide says it “shows the specific policy or policies that resulted in the sign-in interruption.”
• A policy that requires a compliant device only protects the apps and users it targets. Excluded apps, excluded users and report-only policies are where a stolen credential still works.
• A policy that accepts a compliant device or MFA as alternatives lets a phished MFA result satisfy it. For admin accounts, require the device control on its own.

How do I fix AADSTS53000?

For the user: enroll the device with your organization’s MDM (for example Intune). If it is already enrolled, ask IT which compliance setting is failing.

For admins:

1. Open the failed sign-in and confirm which policy and which device it was. Compare the device ID with the user’s enrolled devices.
2. If the device is unknown and the account is privileged or the IP is unfamiliar, treat the password as compromised: reset it, revoke sessions (Revoke-MgUserSignInSession) and review recent sign-ins for the same IP.
3. If it is a real user on a real device, fix compliance rather than adding an exclusion. Every exclusion is a path for a stolen credential.