# AADSTS530004: AcceptCompliantDevice setting isn't configured (fix)

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

**Short answer:** AADSTS530004 means a guest user hit a device-based Conditional Access policy in the resource tenant, and that tenant doesn't trust device claims from the guest's home tenant. Microsoft's error reference doesn't list it, but a Microsoft troubleshooting article does. It is a B2B configuration gap with low attack value. The fix is the inbound trust settings in cross-tenant access.

**Fix:** Resource tenant admin: in Cross-tenant access settings, open inbound trust for the guest's home tenant (or the defaults) and select Trust compliant devices or Trust Microsoft Entra hybrid joined devices. Exclude guests from Require approved client app. Guest: use your work device, not InPrivate.

| Field | Value |
|---|---|
| Code | AADSTS530004 |
| Category | Guests and tenants |
| Type | Failure |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | No (checked 2026-10-30) |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS530004 mean?

Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) doesn't list AADSTS530004 (checked 30 October 2026).

Microsoft documents it in a troubleshooting article, which quotes the message as:

> AADSTS530004: AcceptCompliantDevice setting isn't configured for this organization. The administrator needs to configure this setting to allow external user access to protected resources.

The article says it happens *"when a guest user tries to access an application or resource in a resource tenant"*, and that *"when an administrator reviews the sign-in logs in the home tenant, the same error code is displayed."*

It names three scenarios, all with a Conditional Access policy in the resource tenant that applies to guests:

| Policy control in the resource tenant | What Microsoft says to do |
|---|---|
| **Require device to be marked as compliant** | Configure cross-tenant access with **Trust compliant devices**, and make sure the guest's device is authenticated, enrolled in Intune or a supported MDM in the home tenant, and compliant. |
| **Require Microsoft Entra hybrid joined device** | Configure cross-tenant access with **Trust Microsoft Entra hybrid joined devices**, and make sure the device is authenticated and hybrid joined in the home tenant. |
| **Require approved client app** | *"This scenario isn't supported. To resolve the error, don't apply this control to guest users."* |

The background is in Microsoft's cross-tenant access overview: by default, *"MFA and device claims from other Microsoft Entra organizations aren't trusted."* Without the trust setting, a guest's compliant or hybrid joined device counts for nothing in your tenant.

## Is it an attack?

No. It is a mismatch between a device policy and the B2B trust settings. A guest who can't pass it is either on a device the home tenant doesn't manage or in a tenant you haven't chosen to trust.

| Pattern | Likely meaning |
|---|---|
| 530004 for every guest from one partner | Your tenant has no trust setting for that partner, or the partner doesn't manage its devices. |
| 530004 for one guest while colleagues from the same partner succeed | That guest's device isn't compliant or registered, or the browser can't send the device claim. |
| 530004 starting on the day a device policy was extended to guests | The policy change, not the guests. Likely, but unconfirmed. |
| 530004 on an approved-client-app policy | Unsupported for guests, per Microsoft. Exclude guests from that control. |

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

Microsoft says the error shows up in the home tenant's sign-in logs, and the article's verification steps use the resource tenant's sign-in logs. It doesn't say which table. Check where it lands:

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

Which partner tenants and devices are affected. In the resource tenant, `HomeTenantId` tells you which partner the guest comes from. In the home tenant, `ResourceTenantId` tells you which external tenant your user was trying to reach. `DeviceDetail` property names come from the Graph `deviceDetail` resource; Microsoft's article says the **Join type** field shows which device claim was passed:

```kusto
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "530004"
| extend TrustType = tostring(DeviceDetail.trustType),
         IsCompliant = tostring(DeviceDetail.isCompliant),
         Browser = tostring(DeviceDetail.browser)
| summarize Rows = count(), Users = dcount(UserPrincipalName), Apps = make_set(AppDisplayName, 10)
          by HomeTenantId, ResourceTenantId, CrossTenantAccessType, UserType, TrustType, IsCompliant, Browser
| sort by Rows desc
```

Our reading: an empty `TrustType` means no device claim reached the resource tenant, which points at the "device authentication fails" cases listed below rather than at the trust setting. Compare with a successful guest sign-in from the same partner.

## How does Conditional Access affect it?

- 530004 only appears because a device control in **your** policy applies to guests. Microsoft lists the controls: compliant device, hybrid joined device and approved client app.
- The approved client app control can't be satisfied by guests at all. Microsoft: *"This scenario isn't supported."*
- If you don't want to trust a partner's devices, the alternative is to exclude guests from the device policy and cover them with an MFA policy instead. Our suggestion; weigh it against your own risk.

## How do I fix AADSTS530004?

**For the guest user:** sign in from your work device in a normal browser window, not InPrivate or Incognito. If you still get the error, tell your contact in the organization you're visiting. Their admin has to change a setting. Your own IT may need to check that your device is compliant.

**For admins of the resource tenant (where the app lives):**
1. Go to **Entra ID** > **External Identities** > **Cross-tenant access settings**. Edit the **Default settings** inbound defaults, or under **Organizational settings** add the guest's home tenant and open its inbound access.
2. On the **Trust settings** tab (for an organization, choose **Customize settings** first), select **Trust compliant devices**, **Trust Microsoft Entra hybrid joined devices**, or both, to match your policy. Select **Save**.
3. If the failing policy uses **Require approved client app**, exclude guests from it.

Microsoft's troubleshooting article says to create the cross-tenant policy *"in the user's home tenant"*. The cross-tenant documentation describes trust settings as inbound settings that let *your* Conditional Access policies trust claims from an external organization. Our reading: the setting lives in the resource tenant, as a per-organization entry **for** the guest's home tenant. If you are the home tenant's admin, ask the resource tenant to configure it.

**For admins of the guest's home tenant:** make sure the device is actually compliant or hybrid joined in your tenant. Microsoft lists these causes of failed device authentication:
- *"When accessing using a browser in InPrivate or Incognito mode."*
- *"When using unsupported browsers or devices, particularly on mobiles."*
- *"When browser cookies are disabled."*
- *"When a desktop or native application doesn't support device authentication or doesn't use Microsoft Authentication Broker."*

## 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. [Error AADSTS530004 - AcceptCompliantDevice setting isn't configured for this organization](https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/error-code-aadsts530004-acceptcompliantdevice-setting-not-configured)
3. [Overview: Cross-tenant access with Microsoft Entra External ID](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview)
4. [Configure cross-tenant access settings for B2B collaboration](https://learn.microsoft.com/entra/external-id/cross-tenant-access-settings-b2b-collaboration)
5. [Conditional Access: Grant](https://learn.microsoft.com/en-gb/entra/identity/conditional-access/concept-conditional-access-grant)
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)

## Related codes

[AADSTS53000](https://brambrinkmeier.com/entra/aadsts/53000/), [AADSTS53001](https://brambrinkmeier.com/entra/aadsts/53001/), [AADSTS53003](https://brambrinkmeier.com/entra/aadsts/53003/), [AADSTS530002](https://brambrinkmeier.com/entra/aadsts/530002/), [AADSTS530003](https://brambrinkmeier.com/entra/aadsts/530003/)

## 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, "AADSTS530004: AcceptCompliantDevice setting isn't configured (fix)", https://brambrinkmeier.com/entra/aadsts/530004/ (CC BY 4.0), last updated 2026-10-30.