AADSTS53001: Device not domain joined
Short answer: AADSTS53001 means a Conditional Access policy requires a domain-joined (hybrid joined) device and the device signing in isn't one. The password was already accepted. Usually it is a user on a personal or cloud-only device. From an unknown device on an unfamiliar IP, it means a working credential is being used outside your estate.
| Code | AADSTS53001 |
|---|---|
| Microsoft name | DeviceNotDomainJoined |
| Category | Devices |
| Type | Failure |
| Attack signal | Medium: worth a look in context |
| MITRE ATT&CK | T1078.004 Valid Accounts: Cloud Accounts |
| Where to look | SigninLogs, AADNonInteractiveUserSignInLogs |
| Microsoft lookup | login.microsoftonline.com/error?code=53001 |
What does AADSTS53001 mean?
Section titled “What does AADSTS53001 mean?”DeviceNotDomainJoined: Conditional Access policy requires a domain joined device, and the device isn’t domain joined. Have the user use a domain joined device.
In practice this is the Conditional Access grant control that requires a hybrid joined device (on-premises domain joined and registered in Entra ID). Conditional Access only runs after the first factor succeeds, so the credential was accepted before this block. ConditionalAccessStatus on these rows is failure.
Is it an attack?
Section titled “Is it an attack?”Usually not. Typical causes are a user on a home PC or phone, an Entra-joined (cloud-only) laptop hitting a policy written for hybrid-joined machines, or a hybrid join that hasn’t finished syncing.
The security reading is the same as 53000 (non-compliant device): the code proves a working credential was used from a device that isn’t one of yours.
| Pattern | Likely meaning |
|---|---|
| Known user, Entra-joined corporate device | Benign. Policy expects hybrid join; device is cloud-joined. |
| New device, hybrid join pending | Benign. Wait for sync or check the join state. |
| Unregistered device (empty device ID), unfamiliar IP or country | Investigate. Someone has the password and is using it off-estate. |
| 53001 after a 50126 run from the same IP | The spray found a correct password. The device policy is the only thing that stopped it. |
A device-based grant is a strong control against stolen credentials and against adversary-in-the-middle phishing, because the attacker’s machine is not joined to your domain. When a 53001 row shows AuthenticationRequirement as multiFactorAuthentication and the MFA step as satisfied, the password and MFA layers were already passed and the device requirement was the only layer that held. For a legitimate user on a personal device that is friction; for an unknown device on an unfamiliar IP it means the earlier layers didn’t stop whoever holds the credential.
How do I find it in my logs (KQL)?
Section titled “How do I find it in my logs (KQL)?”53001 from devices that aren’t registered in Entra at all:
SigninLogs| where TimeGenerated > ago(7d)| where ResultType == "53001"| extend DeviceId = tostring(DeviceDetail.deviceId), TrustType = tostring(DeviceDetail.trustType), OS = tostring(DeviceDetail.operatingSystem), Country = tostring(LocationDetails.countryOrRegion)| summarize Attempts = count(), IPs = make_set(IPAddress, 10), Countries = make_set(Country, 5), Apps = make_set(AppDisplayName, 5), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by UserPrincipalName, DeviceId, TrustType, OS| extend Unregistered = isempty(DeviceId)| sort by Unregistered desc, Attempts descDid the same IP fail passwords first? That pattern means a spray succeeded:
let deviceBlocked = SigninLogs | where TimeGenerated > ago(1d) | where ResultType in ("53001", "53000") | distinct IPAddress;SigninLogs| where TimeGenerated > ago(1d)| where IPAddress in (deviceBlocked)| where ResultType in ("50126", "50053", "53000", "53001", "0")| summarize Users = dcount(UserPrincipalName), Results = make_set(ResultType) by IPAddress| where Users > 1| sort by Users descFor AADNonInteractiveUserSignInLogs, DeviceDetail and LocationDetails are string columns: use parse_json(DeviceDetail).trustType. The property names used here 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?
Section titled “How does Conditional Access affect it?”- 53001 is produced by Conditional Access. The Conditional Access tab on the sign-in shows which policy blocked it.
- If your fleet is moving to Entra-joined devices, a hybrid-join-only policy will produce 53001 for legitimate corporate devices. Combining “hybrid joined” with “compliant device” as alternatives is the common fix.
- As with 53000, pairing the device control with MFA as “require one of” lets a phished MFA result through. Keep a device requirement on its own for admin roles.
How do I fix AADSTS53001?
Section titled “How do I fix AADSTS53001?”For the user: sign in from your corporate, domain-joined computer. If you are already on one, ask IT to check that its join to Entra ID has completed.
For admins:
- Open the sign-in, note the policy and the device. An empty device ID means an unregistered device.
- If the device is unknown and the IP unfamiliar, treat the password as compromised: reset it, revoke sessions, and check the same IP for other users.
- If it is a legitimate cloud-joined device, adjust the policy to accept compliant devices too, rather than excluding the user.