AADSTS530002: Your device is required to be compliant (fix)

What does AADSTS530002 mean?

Microsoft’s error code reference doesn’t list AADSTS530002 (checked 30 October 2026).

Microsoft documents it on another page. The Viva Goals troubleshooting page for integration errors lists it under the heading “AADSTS530002: Your device is required to be compliant to access this resource” and says:

The device on which this connection was first created is no longer in a compliant state. Try reauthenticating or creating a new connection.

That page introduces its list as errors you get “if you encounter an AAD invalid grant error for an integration”. So the scenario Microsoft describes is a connection created on a device that was compliant at the time, whose token later fails because the device no longer is.

We found little else. Two web searches for the exact message returned no user thread that quotes 530002. The Q&A and community threads they returned all quote the listed code 53000 instead, for example: “AADSTS53000: Device is not in required device state: compliant. Conditional Access policy requires a compliant device, and the device is not compliant.”

Our reading: 530002 and 53000 come from the same grant control, Require device to be marked as compliant. 53000 is the code people see at sign-in. 530002 shows up, as far as Microsoft’s one page says, when a stored grant is used later. Microsoft doesn’t document how the two differ, so fix both the same way.

Is it an attack?

Usually not. The common cause is a device that drifted out of compliance: an overdue OS update, a disabled disk encryption setting, or a lapsed Intune check-in.

Pattern	Likely meaning
530002 for an integration or background sync that worked before	The device the connection was created on is no longer compliant. Microsoft’s Viva Goals scenario.
530002 for many users on the same day	A compliance policy changed in Intune and many devices fell out of compliance at once. Likely, but unconfirmed.
530002 for one user on a device with an empty device ID	The device isn’t registered, so it can’t be compliant. Microsoft says devices “must be registered in Microsoft Entra ID before they can be marked as compliant.”
530002 for a privileged account from a new IP or country	Our reasoning: a working session or token is being used from a device you don’t manage. Check whether it was the user.

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

Microsoft doesn’t document which sign-in table 530002 is logged in. The Viva Goals scenario (a refreshed integration token) points to AADNonInteractiveUserSignInLogs as the likely place, but check:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("530002", "53000")
| summarize Rows = count() by SourceTable, ResultType

Which devices fail, and what compliance state the sign-in recorded. DeviceDetail is dynamic in SigninLogs and a string in AADNonInteractiveUserSignInLogs, so each leg parses it first. The property names come from the Graph deviceDetail resource:

let rows =
    union
        (SigninLogs | extend D = parse_json(tostring(DeviceDetail)) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, IPAddress, D),
        (AADNonInteractiveUserSignInLogs | extend D = parse_json(DeviceDetail) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, IPAddress, D);
rows
| where TimeGenerated > ago(7d)
| where ResultType == "530002"
| extend DeviceId = tostring(D.deviceId),
         DeviceName = tostring(D.displayName),
         IsCompliant = tostring(D.isCompliant),
         TrustType = tostring(D.trustType),
         OS = tostring(D.operatingSystem)
| summarize Rows = count(), Users = make_set(UserPrincipalName, 10), Apps = make_set(AppDisplayName, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by DeviceId, DeviceName, IsCompliant, TrustType, OS
| sort by Rows desc

A day with many more devices failing than usual. The factor of 3 is a starting point:

let daily =
    union
        (SigninLogs | extend DeviceId = tostring(DeviceDetail.deviceId) | project TimeGenerated, ResultType, DeviceId),
        (AADNonInteractiveUserSignInLogs | extend DeviceId = tostring(parse_json(DeviceDetail).deviceId) | project TimeGenerated, ResultType, DeviceId)
    | where TimeGenerated > ago(30d)
    | where ResultType in ("530002", "53000")
    | summarize Devices = dcount(DeviceId) by Day = bin(TimeGenerated, 1d);
let baseline = toscalar(daily | summarize avg(Devices));
daily
| where Devices > 3 * baseline
| sort by Day asc

How does Conditional Access affect it?

• The control is Require device to be marked as compliant. Microsoft says it “only supports Windows 10+, iOS, Android, macOS, and Linux Ubuntu devices registered with Microsoft Entra ID and enrolled with Intune”, and that “Microsoft Edge in InPrivate mode on Windows is considered as a noncompliant device.”
• Compliance comes from Intune or a supported non-Microsoft MDM: “Intune sends compliance information to Microsoft Entra ID so Conditional Access can decide to grant or block access to resources.” So the fix is usually in Intune, not in Conditional Access.
• By default a policy with several controls requires all of them. With “require one of”, hybrid join or MFA can stand in for compliance.
• For guest users, see 530004: the resource tenant has to trust the home tenant’s compliance claim.

How do I fix AADSTS530002?

For the user: open Company Portal (or your MDM app) on the device, check what it says is wrong, fix it, and sync. Then sign in again. For an integration that stopped working, the Viva Goals advice is to reauthenticate or create the connection again, on a compliant device.

For admins:

1. Open the failed sign-in in Entra ID > Monitoring & health > Sign-in logs. The Conditional Access tab names the policy; Microsoft says the Troubleshooting and support tab may show the reason, “such as a device that didn’t meet compliance requirements.”
2. Look the device up in Intune and read which compliance setting fails.
3. If the second query shows an empty device ID, the device isn’t registered. Register or enroll it first.
4. If many devices failed on one day, review the last change to your compliance policies before you touch Conditional Access.