AADSTS50155: Device authentication failed (fix)

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:

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”:

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:

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.