{
  "schemaVersion": "1.0",
  "code": "50155",
  "name": "DeviceAuthenticationFailed",
  "title": "AADSTS50155: Device authentication failed (fix)",
  "url": "https://brambrinkmeier.com/entra/aadsts/50155/",
  "alternates": {
    "markdown": "https://brambrinkmeier.com/entra/aadsts/50155.md",
    "json": "https://brambrinkmeier.com/api/aadsts/50155.json",
    "html": "https://brambrinkmeier.com/entra/aadsts/50155/"
  },
  "description": "AADSTS50155: Entra ID couldn't authenticate the device, usually because it was deleted or disabled. Re-enable or re-register it. KQL included.",
  "summary": "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.",
  "inMicrosoftReference": true,
  "unlistedChecked": null,
  "meaningText": "Microsoft's description:\n\n> **DeviceAuthenticationFailed**: Device authentication failed for this user.\n\nThe 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.\"*\n\nWithout 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.\"*",
  "sections": [
    {
      "heading": "What does AADSTS50155 mean?",
      "text": "Microsoft's description:\n\n> **DeviceAuthenticationFailed**: Device authentication failed for this user.\n\nThe 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.\"*\n\nWithout 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.\"*"
    },
    {
      "heading": "Is it an attack?",
      "text": "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:\n\n| Pattern | Likely meaning |\n|---|---|\n| 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. |\n| 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.\"* |\n| 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.\"* |\n| 50155 after a user disabled their own device | Microsoft lists *\"User disables the device from the My Apps portal.\"* |\n| 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. |\n\nThe last row is the only one worth a security look. Even then, the failure means the device got no PRT."
    },
    {
      "heading": "How do I find it in my logs (KQL)?",
      "text": "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:\n\n```kusto\nunion withsource=SourceTable\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            Devices = dcount(tostring(Dev.deviceId))\n          by SourceTable\n```\n\nWhich 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\"*:\n\n```kusto\nunion\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| extend DeviceId = tostring(Dev.deviceId),\n         DeviceName = tostring(Dev.displayName),\n         OS = tostring(Dev.operatingSystem),\n         TrustType = tostring(Dev.trustType)\n| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),\n            IPs = make_set(IPAddress, 5), Apps = make_set(AppDisplayName, 5)\n          by UserPrincipalName, DeviceName, DeviceId, OS, TrustType\n| sort by Rows desc\n```\n\nDevices 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:\n\n```kusto\nAuditLogs\n| where TimeGenerated > ago(30d)\n| where Category == \"Device\"\n| where OperationName in (\"Delete device\", \"Update device\")\n| extend DeviceName = tostring(TargetResources[0].displayName),\n         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))\n| project TimeGenerated, OperationName, DeviceName, Actor, Result\n| sort by TimeGenerated desc\n```\n\n`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`."
    },
    {
      "heading": "How do I fix AADSTS50155?",
      "text": "**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.\n\n**For admins:**\n1. Find the device in the Microsoft Entra admin center. Microsoft's solution is to *\"Re-register the device based on the device join type.\"*\n2. **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.\n3. **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.\n4. **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.\n5. **Deleted, Microsoft Entra registered:** go to **Settings** > **Accounts** > **Access Work or School**, select the account, select **Disconnect**, then **Connect** and register again.\n6. Check `dsregcmd /status` afterwards. The PRT guide uses it to check the PRT state.\n7. 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."
    }
  ],
  "microsoftWording": {
    "text": "**DeviceAuthenticationFailed**: Device authentication failed for this user.",
    "source": "Microsoft's error code reference, as quoted on the page",
    "sourceUrl": "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes"
  },
  "securityReading": {
    "category": {
      "id": "device",
      "label": "Devices"
    },
    "kind": {
      "id": "failure",
      "label": "Failure"
    },
    "attackSignal": {
      "level": "low",
      "label": "Low: usually configuration or user error"
    },
    "mitre": [],
    "tables": [
      "SigninLogs",
      "AADNonInteractiveUserSignInLogs"
    ],
    "isItAnAttack": "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:\n\n| Pattern | Likely meaning |\n|---|---|\n| 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. |\n| 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.\"* |\n| 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.\"* |\n| 50155 after a user disabled their own device | Microsoft lists *\"User disables the device from the My Apps portal.\"* |\n| 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. |\n\nThe last row is the only one worth a security look. Even then, the failure means the device got no PRT.",
    "conditionalAccess": null
  },
  "kql": [
    {
      "title": null,
      "leadIn": "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:",
      "query": "union withsource=SourceTable\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            Devices = dcount(tostring(Dev.deviceId))\n          by SourceTable"
    },
    {
      "title": null,
      "leadIn": "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\"*:",
      "query": "union\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| extend DeviceId = tostring(Dev.deviceId),\n         DeviceName = tostring(Dev.displayName),\n         OS = tostring(Dev.operatingSystem),\n         TrustType = tostring(Dev.trustType)\n| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),\n            IPs = make_set(IPAddress, 5), Apps = make_set(AppDisplayName, 5)\n          by UserPrincipalName, DeviceName, DeviceId, OS, TrustType\n| sort by Rows desc"
    },
    {
      "title": null,
      "leadIn": "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:",
      "query": "AuditLogs\n| where TimeGenerated > ago(30d)\n| where Category == \"Device\"\n| where OperationName in (\"Delete device\", \"Update device\")\n| extend DeviceName = tostring(TargetResources[0].displayName),\n         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))\n| project TimeGenerated, OperationName, DeviceName, Actor, Result\n| sort by TimeGenerated desc"
    }
  ],
  "kqlSectionText": "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:\n\n```kusto\nunion withsource=SourceTable\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            Devices = dcount(tostring(Dev.deviceId))\n          by SourceTable\n```\n\nWhich 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\"*:\n\n```kusto\nunion\n    (SigninLogs | extend Dev = todynamic(DeviceDetail)),\n    (AADNonInteractiveUserSignInLogs | extend Dev = todynamic(DeviceDetail))\n| where TimeGenerated > ago(7d)\n| where ResultType == \"50155\"\n| extend DeviceId = tostring(Dev.deviceId),\n         DeviceName = tostring(Dev.displayName),\n         OS = tostring(Dev.operatingSystem),\n         TrustType = tostring(Dev.trustType)\n| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),\n            IPs = make_set(IPAddress, 5), Apps = make_set(AppDisplayName, 5)\n          by UserPrincipalName, DeviceName, DeviceId, OS, TrustType\n| sort by Rows desc\n```\n\nDevices 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:\n\n```kusto\nAuditLogs\n| where TimeGenerated > ago(30d)\n| where Category == \"Device\"\n| where OperationName in (\"Delete device\", \"Update device\")\n| extend DeviceName = tostring(TargetResources[0].displayName),\n         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))\n| project TimeGenerated, OperationName, DeviceName, Actor, Result\n| sort by TimeGenerated desc\n```\n\n`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`.",
  "fix": {
    "short": "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.",
    "steps": "**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.\n\n**For admins:**\n1. Find the device in the Microsoft Entra admin center. Microsoft's solution is to *\"Re-register the device based on the device join type.\"*\n2. **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.\n3. **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.\n4. **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.\n5. **Deleted, Microsoft Entra registered:** go to **Settings** > **Accounts** > **Access Work or School**, select the account, select **Disconnect**, then **Connect** and register again.\n6. Check `dsregcmd /status` afterwards. The PRT guide uses it to check the PRT state.\n7. 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."
  },
  "labReproduced": null,
  "labSectionText": null,
  "labRuns": [],
  "verification": "documentation",
  "related": [
    "50097",
    "53000",
    "53001",
    "135011"
  ],
  "coveredBy": [],
  "sources": [
    {
      "title": "Microsoft Entra authentication and authorization error codes",
      "url": "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes"
    },
    {
      "title": "Troubleshoot primary refresh token issues on Windows devices",
      "url": "https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-primary-refresh-token"
    },
    {
      "title": "Microsoft Entra device management FAQ",
      "url": "https://learn.microsoft.com/en-us/entra/identity/devices/faq"
    },
    {
      "title": "Microsoft Entra audit log activity reference",
      "url": "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-audit-activities"
    },
    {
      "title": "deviceDetail resource type (Microsoft Graph)",
      "url": "https://learn.microsoft.com/en-us/graph/api/resources/devicedetail?view=graph-rest-1.0"
    },
    {
      "title": "SigninLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
    },
    {
      "title": "AADNonInteractiveUserSignInLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadnoninteractiveusersigninlogs"
    }
  ],
  "published": "2026-10-30",
  "lastUpdated": "2026-10-30",
  "lastVerified": null,
  "license": "CC BY 4.0",
  "licenseUrl": "https://creativecommons.org/licenses/by/4.0/",
  "licenseNote": "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.",
  "attribution": "Bram Brinkmeier, \"AADSTS50155: Device authentication failed (fix)\", https://brambrinkmeier.com/entra/aadsts/50155/ (CC BY 4.0)",
  "microsoftErrorLookup": "https://login.microsoftonline.com/error?code=50155"
}