# AADSTS50155: Device authentication failed (fix)

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

**Short answer:** AADSTS50155 means Microsoft Entra ID couldn't authenticate the user's device, so it can't issue a Primary Refresh Token. Microsoft's main cause is a device that was deleted or disabled in Entra ID. The fix is to re-enable or re-register the device. Attack value is low, but 50155 from a device you disabled because it was lost is worth a look.

**Fix:** Admin: find the device in the Entra admin center. Re-enable it if it was disabled, or re-register it for its join type (for example `dsregcmd /forcerecovery` on an Entra joined device). Don't re-enable a lost or stolen device. User: tell IT what the device message says.

| Field | Value |
|---|---|
| Code | AADSTS50155 |
| Microsoft name | DeviceAuthenticationFailed |
| Category | Devices |
| Type | Failure |
| Attack signal | Low: usually configuration or user error |
| Where to look | `SigninLogs`, `AADNonInteractiveUserSignInLogs` |
| In Microsoft's error reference | Yes |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS50155 mean?

Microsoft's description:

> **DeviceAuthenticationFailed**: Device authentication failed for this user.

The device tried to prove its identity to Microsoft Entra ID and failed. Microsoft's Primary Refresh Token (PRT) troubleshooting guide gives the cause: *"Microsoft Entra ID can't authenticate the device to issue a PRT"*, and *"The device might have been deleted or disabled."*

Without a PRT, single sign-on on the Windows device stops working. The device FAQ describes what users see: a message that *"Your organization has deleted the device"* or *"Your organization has disabled the device"*. It explains why: *"The validity of the PRT is based on the validity of the device itself."*

## Is it an attack?

Usually not. Microsoft's device FAQ lists how a device ends up deleted or disabled, and none of them is an attack on the sign-in:

| Pattern | Likely meaning |
|---|---|
| 50155 for one user right after an admin cleaned up stale devices | The device object was deleted or disabled. Benign. Re-register or re-enable it. |
| 50155 for a hybrid joined device after an OU change in Entra Connect | Microsoft: *"An administrator removes the devices OU out of sync scope resulting in the devices being deleted from Microsoft Entra ID."* |
| 50155 for a hybrid joined device whose computer account was disabled on-premises | Microsoft: disabling the computer account on-premises results *"in the device being disabled in Microsoft Entra ID."* |
| 50155 after a user disabled their own device | Microsoft lists *"User disables the device from the My Apps portal."* |
| 50155 from a device you disabled because it was lost or stolen | Microsoft says admins do this *"for stale, lost, or stolen devices to prevent unauthorized access."* The control is working. Our reading: someone is still using that device, so check who and from where. |

The last row is the only one worth a security look. Even then, the failure means the device got no PRT.

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

Microsoft doesn't document which sign-in table 50155 is logged in. Check where it lands. `DeviceDetail` is `dynamic` in `SigninLogs` but `string` in `AADNonInteractiveUserSignInLogs`, so the query normalises it before the union:

```kusto
union withsource=SourceTable
    (SigninLogs | extend Dev = todynamic(DeviceDetail)),
    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))
| where TimeGenerated > ago(7d)
| where ResultType == "50155"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            Devices = dcount(tostring(Dev.deviceId))
          by SourceTable
```

Which devices and users fail. `deviceId`, `displayName`, `operatingSystem` and `trustType` are properties of the Graph `deviceDetail` type; Microsoft notes the device ID and name are *"Populated for devices registered in Microsoft Entra"*:

```kusto
union
    (SigninLogs | extend Dev = todynamic(DeviceDetail)),
    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))
| where TimeGenerated > ago(7d)
| where ResultType == "50155"
| extend DeviceId = tostring(Dev.deviceId),
         DeviceName = tostring(Dev.displayName),
         OS = tostring(Dev.operatingSystem),
         TrustType = tostring(Dev.trustType)
| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            IPs = make_set(IPAddress, 5), Apps = make_set(AppDisplayName, 5)
          by UserPrincipalName, DeviceName, DeviceId, OS, TrustType
| sort by Rows desc
```

Devices that were deleted or disabled in the directory recently, to match against the list above. `Delete device` and `Update device` are activities in the `Device` category of the audit log. Matching on the device name is our approach: the audit log identifies the device by its object, and we haven't checked that this ID equals the `deviceId` in sign-in logs:

```kusto
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "Device"
| where OperationName in ("Delete device", "Update device")
| extend DeviceName = tostring(TargetResources[0].displayName),
         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))
| project TimeGenerated, OperationName, DeviceName, Actor, Result
| sort by TimeGenerated desc
```

`Update device` covers more than disabling, so open the row's `TargetResources` to see what changed. `ResultType` in the sign-in tables is a **string** column, so compare it with `"50155"`, not `50155`.

## How do I fix AADSTS50155?

**For the user:** tell your IT team the device shows *"Your organization has deleted the device"* or *"has disabled the device"*. You can't fix it alone if the device was disabled; an admin has to re-enable it.

**For admins:**
1. Find the device in the Microsoft Entra admin center. Microsoft's solution is to *"Re-register the device based on the device join type."*
2. **Disabled device:** an admin can enable it again in the Microsoft Entra admin center. For hybrid joined devices synced with Entra Connect, Microsoft notes they are *"automatically re-enabled during the next sync cycle"*, so disable those in on-premises AD instead.
3. **Deleted, Microsoft Entra hybrid joined:** in an elevated command prompt run `dsregcmd.exe /debug /leave`, then sign out and sign in to trigger the scheduled task that registers the device again.
4. **Deleted, Microsoft Entra joined:** in an elevated command prompt run `dsregcmd /forcerecovery`, select **Sign in** in the dialog, finish the sign-in, then sign out and back in.
5. **Deleted, Microsoft Entra registered:** go to **Settings** > **Accounts** > **Access Work or School**, select the account, select **Disconnect**, then **Connect** and register again.
6. Check `dsregcmd /status` afterwards. The PRT guide uses it to check the PRT state.
7. If the device was disabled because it was lost or stolen, don't re-enable it. Use the second query to see which IPs it still signs in from.

## Evidence

Not reproduced in the lab yet; the page is based on Microsoft's documentation.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes)
2. [Troubleshoot primary refresh token issues on Windows devices](https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-primary-refresh-token)
3. [Microsoft Entra device management FAQ](https://learn.microsoft.com/en-us/entra/identity/devices/faq)
4. [Microsoft Entra audit log activity reference](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-audit-activities)
5. [deviceDetail resource type (Microsoft Graph)](https://learn.microsoft.com/en-us/graph/api/resources/devicedetail?view=graph-rest-1.0)
6. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
7. [AADNonInteractiveUserSignInLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadnoninteractiveusersigninlogs)

## Related codes

[AADSTS50097](https://brambrinkmeier.com/entra/aadsts/50097/), [AADSTS53000](https://brambrinkmeier.com/entra/aadsts/53000/), [AADSTS53001](https://brambrinkmeier.com/entra/aadsts/53001/), [AADSTS135011](https://brambrinkmeier.com/entra/aadsts/135011/)

## 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, "AADSTS50155: Device authentication failed (fix)", https://brambrinkmeier.com/entra/aadsts/50155/ (CC BY 4.0), last updated 2026-10-30.