AADSTS530003: Your device is required to be managed (fix)

What does AADSTS530003 mean?

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

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

The device on which this connection was first created might not have been in a managed 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 it covers a stored connection whose token is refreshed later.

Users report the same message from command-line tools. On HashiCorp Discuss, terraform plan on Ubuntu with the azurerm provider failed while reading a token from the Azure CLI:

ERROR: AADSTS530003: Your device is required to be managed to access this resource.

On Microsoft Q&A, az account get-access-token --resource https://graph.microsoft.com in Azure Cloud Shell returned the same text. Neither thread has an answer.

Our reading: a Conditional Access policy requires a managed device (compliant or hybrid joined), and the device asking for the token is not one or can’t prove it. Microsoft doesn’t publish a name or a precise definition for 530003. The listed codes for the same family are 53000 (device not compliant) and 53001 (device not domain joined).

Is it an attack?

Usually not. Most reports come from tools that can’t present a device identity: a CLI on Linux, a container, Cloud Shell, or a stored integration.

Pattern	Likely meaning
530003 from Azure CLI, Terraform or PowerShell on a build agent or Linux machine	The tool runs on a machine that isn’t managed by the tenant. Expected under a managed-device policy.
530003 right after az login --use-device-code	Microsoft says device code flow can’t carry device state (see below), so expect it under a managed-device policy.
530003 from Cloud Shell	Probably because Cloud Shell runs on a Microsoft host, not on the user’s device. Unconfirmed; based on one Q&A report.
530003 for a privileged account from a new IP or country	Our reasoning: the account got far enough for a device control to apply. Check whether the sign-in was the user.

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

Microsoft doesn’t document which sign-in table 530003 is logged in. Check where it lands first:

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

Which users, apps and device states hit it. DeviceDetail is dynamic in SigninLogs and a string in AADNonInteractiveUserSignInLogs, so each leg parses it before the union. The property names come from the Graph deviceDetail resource:

let rows =
    union
        (SigninLogs | extend D = parse_json(tostring(DeviceDetail)) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, ClientAppUsed, UserAgent, IPAddress, D),
        (AADNonInteractiveUserSignInLogs | extend D = parse_json(DeviceDetail) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, ClientAppUsed, UserAgent, IPAddress, D);
rows
| where TimeGenerated > ago(7d)
| where ResultType == "530003"
| extend DeviceId = tostring(D.deviceId),
         TrustType = tostring(D.trustType),
         IsManaged = tostring(D.isManaged),
         IsCompliant = tostring(D.isCompliant),
         OS = tostring(D.operatingSystem)
| summarize Rows = count(), IPs = make_set(IPAddress, 10), Agents = make_set(UserAgent, 5)
          by UserPrincipalName, AppDisplayName, ClientAppUsed, DeviceId, TrustType, IsManaged, IsCompliant, OS
| extend Unregistered = isempty(DeviceId)
| sort by Rows desc

530003 from an IP where the same user had no successful sign-in in the last 30 days. A starting point for triage, not a detection rule:

let lookback = 30d;
let knownUserIPs =
    union
        (SigninLogs | project TimeGenerated, UserPrincipalName, IPAddress, ResultType),
        (AADNonInteractiveUserSignInLogs | project TimeGenerated, UserPrincipalName, IPAddress, ResultType)
    | where TimeGenerated > ago(lookback)
    | where ResultType == "0"
    | distinct UserPrincipalName, IPAddress;
union
    (SigninLogs | project TimeGenerated, ResultType, UserPrincipalName, IPAddress, AppDisplayName, UserAgent),
    (AADNonInteractiveUserSignInLogs | project TimeGenerated, ResultType, UserPrincipalName, IPAddress, AppDisplayName, UserAgent)
| where TimeGenerated > ago(1d)
| where ResultType == "530003"
| join kind=leftanti knownUserIPs on UserPrincipalName, IPAddress
| sort by TimeGenerated desc

How does Conditional Access affect it?

• 530003 most likely comes from a device grant control: Require device to be marked as compliant, Require Microsoft Entra hybrid joined device, or both. The Conditional Access tab on the failed sign-in shows which policy applied.
• Microsoft says device code flow can’t satisfy these controls: “When you use the device-code OAuth flow, the required grant control for the managed device or a device state condition isn’t supported. This is because the device that is performing authentication can’t provide its device state to the device that is providing a code.” Microsoft’s advice there: use Require multifactor authentication instead.
• Microsoft also says Edge in InPrivate mode doesn’t count as compliant or hybrid joined.
• By default, a policy with several controls requires all of them. With “require one of the selected controls”, MFA can stand in for the device.

How do I fix AADSTS530003?

For the user: run the tool on your managed work device, or sign in with a browser on that device. If you need the tool somewhere else, such as a build server, ask IT how they want that done.

For developers: Microsoft’s MSAL.NET page on device authentication says the device must prove its identity, and “to satisfy this requirement you will have to leverage WAM on Windows or the system browser. On mobile platforms, you’ll need to enable the brokers (Microsoft Authenticator and Company portal).” An embedded web view or a plain HTTP client can’t do that. For automation, don’t use a user account at all. Use a service principal or managed identity. Our reading is that user device-state controls don’t apply to those, but check your own policies.

For admins:

1. Open the failed sign-in in Entra ID > Monitoring & health > Sign-in logs and select the Conditional Access tab. It names the policy. Microsoft adds that the Troubleshooting and support tab may show the reason directly.
2. Check the device in the second query. An empty DeviceId means the device isn’t registered, so it can’t be managed.
3. Decide whether the policy should cover that app. If admins need Azure CLI from unmanaged machines, scope an exception for those users or allow MFA as an alternative. Use the What If tool before you change a production policy.
4. If the device should be managed, enroll or join it and sign in again. The Viva Goals page gives the same advice for stored connections: reauthenticate or create a new connection.