AADSTS50155 Device Authentication Failed | Quick Fixes

What Does AADSTS50155 Device Authentication Failed Mean?

This message appears when Microsoft Entra ID rejects the device step of the sign-in flow. The account might be fine, the password might be correct, yet the device cannot pass its own check. The result is a failed sign-in even though the user feels they did everything right.

In plain terms, aadsts50155 device authentication failed tells you that Microsoft Entra ID does not accept this Windows device as trusted for that account. That trust link depends on a device object in the cloud directory, certificates on the device, and a healthy link between the device and your tenant. When any of those pieces fall out of line, this error shows up in sign-in logs and users see prompts that never succeed.

Most cases fall into a few patterns. The device entry might be disabled or deleted in Microsoft Entra ID, the device might still be joined to an old tenant, or it might never have completed its join. Network issues and stale primary refresh tokens can also block device proof. The good news is that each pattern has a clear path to test and fix.

Common Causes Of The AADSTS50155 Device Error

The same aadsts50155 device error code string can hide different root causes. Reading the sign-in log and checking the device record narrows the field quickly. These are the patterns that admins see most often.

Device Object Disabled Or Deleted

For managed Windows devices, the device record in Microsoft Entra ID acts like a passport. When an admin disables or deletes that record, the device cannot finish sign-in against cloud resources. From the user side it looks like a normal login, yet the service refuses the device token behind the scenes.

Device Not Registered Or Stuck In Pending State

Hybrid joined setups rely on sync between on-premises Active Directory and Microsoft Entra ID. When the object has synced but registration never finishes, the portal can show a Pending status. That state leaves the device unable to present a valid device ticket during sign-in.

Device Joined To Another Tenant Or Domain

Sometimes a laptop started life in a different tenant, then later moved to a new one without a clean reset. The device still carries its older join, so when a user signs in with an account from the new tenant the cloud directory sees a mismatch. This mismatch leads straight to device authentication failure.

Outdated Primary Refresh Token Or Time Issues

Joined devices rely on a primary refresh token that renews in the background. When that token expires and cannot refresh, or when device time drifts far from real time, the token no longer passes checks. Users then hit prompts for credentials, and device validation can fail with code 50155.

Local Network, Proxy, Or Broker Problems

Some cases trace back to a local broker such as WebView2 or a network stack that blocks required endpoints. The device reaches the sign-in page but never finishes the device proof step. The sign-in log still records aadsts50155, yet the fix lies closer to the desktop than the cloud.

AADSTS50155 Device Authentication Failure Fixes You Can Try

Once you understand which pattern fits, you can work through a set of targeted fixes. Start with checks that give you quick answers, then move toward steps that change the device state in more detail. Always test on a single device before you roll changes across many machines.

Step 1: Confirm The Sign-In Log Details

The sign-in log in Microsoft Entra admin center is your starting point. Filter by the user, then open a failed entry with code 50155. Note the device name, device ID, and any extra message tied to the error. Match those values with what the user sees on the screen so you are sure you are working on the right device.

• Open sign-in logs — In the Microsoft Entra admin center, go to Sign-in logs and filter by the affected user.
• Locate error 50155 — Sort by date, pick a failed entry, and confirm the error code and device details.
• Capture context — Note IP details, client app, and conditional access result for later checks.

Step 2: Check Device Status In Microsoft Entra ID

Next, move to the device list. Search for the device name or device ID from the log entry. Confirm that the device exists, that it belongs to the expected tenant, and that its state is marked as enabled, not disabled or pending.

• Search the device — In the Devices blade, search by name or device ID from the log.
• Review state — Check whether the device is enabled, disabled, pending, or stale.
• Confirm ownership — Ensure the device shows the right tenant and join type for this user.

Step 3: Repair Hybrid Or Cloud Join

For domain joined or hybrid machines, device join issues often sit between on-premises directory, sync, and cloud. A quick way to see current join state is the dsregcmd tool. You can run it from a command prompt with admin rights on the device.

• Run dsregcmd /status — Open Command Prompt as admin and run this command to print join details.
• Check AzureAdJoined — Confirm this flag shows YES and that TenantId matches your tenant.
• Rejoin if needed — If join flags look wrong, disconnect and join again through Settings.

Step 4: Refresh The Primary Refresh Token

If logs show token issues, or users see repeated prompts after password changes, a stale primary refresh token might be in play. You can refresh it by locking the device, signing back in, connecting to the network, and signing out and back in once more. Correct time settings on both device and domain controller also help.

• Sync time — Ensure Windows time matches a reliable time source and that time zone settings are correct.
• Trigger token refresh — Lock the screen, sign back in, then sign out and sign back in with network access.
• Check logs again — After a new sign-in, confirm whether error 50155 still appears.

Step 5: Test With Different Client Paths

Sometimes the aadsts50155 device authentication failed response only appears through one flow, such as a WebView based client, while a system browser works. That pattern points toward local broker issues instead of directory data.

• Try system browser — Sign in through the system browser instead of embedded web views.
• Bypass proxy — Test from a network without an outbound proxy that inspects TLS traffic.
• Update client stack — Make sure authentication libraries and WebView components are current.

How To Read Logs And Confirm The AADSTS50155 Error

Good log habits turn this error from a vague message into a precise signal. A short log review often saves hours of trial and error on the device side.

In the Microsoft Entra admin center, sign-in logs show each attempt with fields for user, app, device, location, and result. When error 50155 appears, expand the entry and note the failure reason. Look for phrases that mention device state, join type, or token issues. Those clues tell you which of the earlier cause categories fits best.

Many admins like to export sign-in data to CSV so they can sort by error code, device, and user. A short filter on 50155 entries lets you spot patterns, such as one subnet, a single build version, or a specific hardware model.

On the device, Windows event logs add local detail. Under Applications and Services Logs for Microsoft, you can find entries related to device registration and primary refresh token. Match timestamps between cloud logs and local logs to see whether the device fails before or after the cloud call. That match guides your next steps toward directory data, local join state, or network components.

Preventing Repeat AADSTS50155 Device Authentication Problems

Once you have fixed a batch of aadsts50155 device error cases, it makes sense to harden your setup so the same patterns do not repeat. Small checks at build time and during device lifecycle management cut down on surprise failures later.

During provisioning, ensure each device joins the correct tenant and domain, and that it completes its Microsoft Entra registration before shipment. Use consistent naming standards so you can find entries in the portal quickly. For hybrid setups, watch sync health and look for long pending queues that hint at deeper directory sync issues.

Over time, clean up stale or unused devices in Microsoft Entra ID. Disable first, confirm that no one signs in, then remove devices only when you are confident they are retired. That pattern keeps the directory tidy without blocking active users by mistake.

Alert rules that watch for spikes in aadsts50155 device error entries help too. When several devices in one group start throwing this error, you can react early and plan a controlled fix.

Regular checks on time services, certificate lifetimes, and client library versions also help. When those basics stay current, devices keep a healthy primary refresh token and are less likely to throw device authentication errors during daily sign-ins.

When To Reset Or Rebuild A Problem Device

Sometimes every soft fix still leaves a stubborn aadsts50155 device authentication failed error. Logs match, joins look correct, yet sign-in will not pass the device step. At that stage you have to decide when a full reset is the faster route.

If the device once belonged to another tenant, or if it has a long history of manual tweaks, rebuilding often clears hidden joins and certificates. Before you reset, verify that user data is backed up or redirected, and that you have a clear build process ready.

After a reset, join the device cleanly to the right tenant, confirm that it appears in Microsoft Entra ID with an enabled state, and then sign in with a test account. Watch the first sign-in closely in both local and cloud logs. A clean run without aadsts50155 is your signal that the underlying device trust link is healthy again for daily work.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback