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

Canonical: https://brambrinkmeier.com/entra/aadsts/530002/
By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/530002.json

**Short answer:** AADSTS530002 means a Conditional Access policy requires a compliant device and the device isn't compliant. Microsoft's error reference doesn't list it; a Viva Goals troubleshooting page does, for stored connections whose device fell out of compliance. Most user reports of compliant-device blocks quote the listed code 53000 instead. Usually benign drift out of compliance.

**Fix:** User: open Company Portal (or your MDM app), fix what it reports, sync, and sign in again. For a stopped integration, reauthenticate or recreate the connection on a compliant device. Admin: find the policy in the sign-in log, then check in Intune which compliance setting fails.

| Field | Value |
|---|---|
| Code | AADSTS530002 |
| Category | Devices |
| Type | Failure |
| Attack signal | Medium: worth a look in context |
| In Microsoft's error reference | No (checked 2026-10-30) |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS530002 mean?

Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) 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](https://brambrinkmeier.com/entra/aadsts/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:

```kusto
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:

```kusto
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:

```kusto
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](https://brambrinkmeier.com/entra/aadsts/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.

## Evidence

Not in Microsoft's error reference and not reproduced in the lab; built from lab results, other Microsoft pages and user reports, which the page names.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes)
2. [Troubleshoot AAD errors for integrations (Viva Goals)](https://learn.microsoft.com/en-gb/viva/goals/integration-aad-errors)
3. [Graph API token generation failed: device is not in required state (Microsoft Q&A 2122577)](https://learn.microsoft.com/en-sg/answers/questions/2122577/graph-api-token-generation-failed-device-is-not-in)
4. [Conditional Access: Grant](https://learn.microsoft.com/en-gb/entra/identity/conditional-access/concept-conditional-access-grant)
5. [Troubleshoot sign-in problems with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access)
6. [deviceDetail resource type (Microsoft Graph)](https://learn.microsoft.com/en-us/graph/api/resources/devicedetail)
7. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
8. [AADNonInteractiveUserSignInLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/AADNonInteractiveUserSignInLogs)

## Related codes

[AADSTS53000](https://brambrinkmeier.com/entra/aadsts/53000/), [AADSTS50097](https://brambrinkmeier.com/entra/aadsts/50097/), [AADSTS53003](https://brambrinkmeier.com/entra/aadsts/53003/), [AADSTS530003](https://brambrinkmeier.com/entra/aadsts/530003/), [AADSTS530004](https://brambrinkmeier.com/entra/aadsts/530004/)

## License and citation

CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.

Cite as: Bram Brinkmeier, "AADSTS530002: Your device is required to be compliant (fix)", https://brambrinkmeier.com/entra/aadsts/530002/ (CC BY 4.0), last updated 2026-10-30.