Entra Device Management: MFA, SSO, Conditional Access, and User Management Guide 2026
Why Entra Device Management Breaks , and Why Microsoft's Error Messages Don't Help
I've seen this exact scenario play out on dozens of enterprise networks: an IT admin carefully sets up Entra Device Management, conditional access policies look right on paper, MFA is enabled, and then a user calls in saying they can't get past the sign-in screen. The error message says something vague like AADSTS50097 or AADSTS50020, and suddenly you're digging through logs wondering what went wrong and where.
Here's the thing, Entra Device Management isn't a single product with a single toggle. It's an ecosystem. You're actually dealing with device identity objects in Microsoft Entra ID, three distinct join states, conditional access policy evaluation, MFA claims, token refresh logic, and platform-specific brokers. When any one of those layers misbehaves, the error surfaces at the user's login prompt, with no context about which layer actually failed.
Microsoft Entra ID stores device identities the same way it stores user or group objects. Each device gets an object in the directory, and that object carries attributes like compliance state, join type, and last activity timestamp. Administrators make access decisions, including conditional access enforcement and Intune enrollment, based on those attributes. So if a device's identity object is stale, missing, or misconfigured, every downstream policy breaks.
There are three ways a device gets an identity in Entra ID, and this is where most confusion begins:
- Microsoft Entra registration, used for personal BYOD scenarios, phones, and tablets. Trust is scoped to the user profile only.
- Microsoft Entra join, for organization-owned Windows 10/11 machines and Windows Server 2019+ VMs running in Azure. Creates a full device-level trust.
- Microsoft Entra hybrid join, for orgs still running on-premises Active Directory. Think of this as a transitional state toward a full cloud-first Entra join.
The join type matters enormously. A registered device cannot satisfy conditional access policies that require a compliant or Entra joined device. I've watched helpdesks spend hours troubleshooting what looks like an MFA loop, only to discover the machine was registered instead of joined, usually because someone enrolled it through the Settings app instead of through the provisioning flow.
Linux environments add another layer of complexity. As of March 2026, the Microsoft Identity Broker for Linux has been completely rewritten from a Java-based to a C++-based architecture. If you're upgrading from version 2.0.1 or earlier, users must re-register and re-enroll their devices. Miss that step, and sign-in will fail with no obvious error.
I know this is frustrating, especially when the fix turns out to be something the error message never hinted at. That's exactly why this guide exists. Let's work through it systematically. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep on Group Policy, registry edits, or re-provisioning devices, run this diagnostic command. It tells you instantly what join state the machine is in and whether the device object in Entra ID is healthy:
dsregcmd /statusOpen an elevated command prompt and run that. You're looking for the Device State section. Here's what the key fields mean:
AzureAdJoined : YES, the machine is properly Entra joined. Good.AzureAdJoined : NO+WorkplaceJoined : YES, the device is only registered, not joined. This breaks device-based conditional access.AzureAdJoined : NO+WorkplaceJoined : NO, the device has no Entra identity at all.DomainJoined : YES+AzureAdJoined : NO, this is a hybrid join candidate that hasn't synced yet.
If you're on Linux and running the Microsoft Identity Broker 3.0.x, Microsoft added a dedicated dsreg command-line tool in the 3.0.1 release specifically for device registration management and diagnostics. Run it with:
dsreg --statusAlso check the service name. In version 3.0.1, the device broker was renamed from linux_devicebroker to microsoft-identity-devicebroker. If your monitoring or startup scripts still reference the old name, the broker won't start and every SSO attempt will fail silently.
systemctl status microsoft-identity-devicebrokerOn Windows, after running dsregcmd /status, scroll down to the SSO State section and check AzureAdPrt : YES. The PRT is the Primary Refresh Token, it's the credential that lets Windows do seamless SSO to cloud and on-premises resources without prompting for MFA on every sign-in. If AzureAdPrt : NO, SSO is broken regardless of what your policies say.
dsregcmd /status output also contains a Diagnostic Data section at the bottom. Look for the field AzureAdPrtUpdateTime, if it's more than a few hours old during an active session, the token refresh is failing. That usually points to a network issue blocking login.microsoftonline.com or a misconfigured proxy, not an Entra configuration problem.
The first thing to confirm is that your device actually has a valid identity object sitting in the Entra ID directory. It sounds basic, but I've seen organizations where devices get stuck in a limbo state, the machine thinks it's joined, but the corresponding object in the directory was deleted by an overzealous cleanup script or a stale device purge policy.
Go to the Microsoft Entra admin center at entra.microsoft.com. Navigate to Identity > Devices > All devices. Search for the device by name. If it doesn't show up, the device object is gone and you need to re-join the machine.
If it does show up, check two things: the Join type column and the Enabled status. A device can exist in the directory but be disabled, which immediately blocks all token issuance for that device. Click the device, scroll to Properties, and confirm Enabled: Yes.
Also check the Activity tab. If Last sign-in activity is months old, you may be looking at a stale device identity. Microsoft's guidance on managing stale devices recommends using this timestamp to identify and clean up inactive objects, but be careful: a device that's been offline for a while is not the same as one that's been actively failing.
From PowerShell, you can query the device object directly using the Microsoft Graph PowerShell module:
Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -Filter "displayName eq 'YOURMACHINENAME'" | Select-Object Id, DisplayName, AccountEnabled, TrustType, ApproximateLastSignInDateTimeIf this returns nothing, the object is missing. If AccountEnabled is False, re-enable it from the Entra admin center. If TrustType shows Workplace when you expected AzureAd, the device was registered instead of joined, that's a re-join operation, not a policy fix.
The Primary Refresh Token is the heart of Entra Device Management single sign-on. When it's healthy, users get SSO to Microsoft 365, Azure resources, and on-premises apps without re-entering credentials. When it's missing or expired, every app prompts for MFA again and again, which users experience as "the login loop."
You already checked dsregcmd /status and found AzureAdPrt : NO. Here's how to fix it.
First, rule out a clock skew issue. Kerberos and token validation are extremely sensitive to time drift. If the device clock is more than 5 minutes off from the domain controller or from Microsoft's servers, token validation fails with error AADSTS70011. Run this to force a time sync:
w32tm /resync /forceThen check your network connectivity to Microsoft's authentication endpoints. The PRT refresh requires access to login.microsoftonline.com and device.login.microsoftonline.com. SSL inspection proxies frequently break this. Run:
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443If that fails or shows TcpTestSucceeded: False, your firewall or proxy is the problem.
For a corrupted PRT state, the nuclear option is to clear the token cache and force re-authentication. Sign out of the Windows account, then at an elevated prompt run:
dsregcmd /leave
dsregcmd /joinThis disconnects and re-joins the device. The user will need to sign in again with MFA the first time to seed a new PRT. After that, SSO should work normally. Watch dsregcmd /status and confirm AzureAdPrt : YES appears within a few minutes of sign-in.
Conditional access is where most Entra Device Management configurations go wrong at the policy level. The intent is clear, only allow access from managed, compliant devices, but the policy conditions are easy to misconfigure, and a wrong setting can either lock out all users or silently allow access that should be blocked.
In the Microsoft Entra admin center, go to Protection > Conditional Access > Policies. Create a new policy or open an existing one.
Under Conditions > Device platforms, select the platforms you want to target. Don't select "Any" unless you truly mean it, that will catch mobile devices too.
Under Grant, you have two device-related options worth knowing:
- Require device to be marked as compliant, relies on Intune compliance policies being assigned and evaluated. The device must have a healthy Intune enrollment.
- Require Microsoft Entra hybrid joined device, for orgs still running on-premises AD, this lets domain-joined machines through even without Intune.
A common mistake: enabling "Require compliant device" without first assigning Intune compliance policies. Every device will show as non-compliant by default until a policy evaluation runs. To check this, go to Intune > Devices > Compliance policies and verify policies are assigned to the correct groups.
Use the What If tool inside Conditional Access to test your policies before enabling them. Go to Conditional Access > What If, enter a specific user and device, and see which policies apply and what the grant result is. This has saved me from locking out entire departments more than once.
# PowerShell: Check device compliance state via Graph
Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'YOURMACHINENAME'" | Select-Object ComplianceState, LastSyncDateTimeMFA in the context of Entra Device Management is not the same as just "turning on MFA." The device join state affects how MFA claims are evaluated, and getting this wrong produces one of the most confusing user experiences in enterprise IT: an MFA prompt that keeps looping even after the user successfully authenticates.
When a device is properly Entra joined and has a valid PRT, Windows passes an MFA claim embedded in that token. This satisfies conditional access MFA requirements without the user being prompted at all. That's the seamless SSO experience the platform promises. But if the PRT is missing, or if the claim is too old, the policy evaluator demands fresh MFA, and depending on your policy configuration, it might keep asking.
To configure MFA requirements in Conditional Access, go to Protection > Conditional Access, open your policy, and under Grant select Require multifactor authentication. You can combine this with device compliance requirements using "Require one of the selected controls" or "Require all of the selected controls" depending on your security posture.
For phishing-resistant MFA, which is now critical for high-value admin accounts, Entra Device Management on Linux now supports SmartCard and Certificate Based Authentication (CBA) as of version 3.0.1, along with FIDO2 keys with a PIV profile. This is called Phish Resistant MFA (PRMFA). To enable it:
- Go to Protection > Authentication methods
- Enable Certificate-based authentication and configure your PKI trust chain
- For FIDO2, enable Passkeys (FIDO2) and scope it to your target group
If users are hitting error AADSTS50076, "Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication", their PRT MFA claim has expired and they need to complete fresh MFA. This is expected behavior, not a bug. But if it happens constantly, your conditional access sign-in frequency setting is too aggressive. Find it under Session > Sign-in frequency in your CA policy.
This step is specifically for organizations running Linux devices, Ubuntu LTS or RHEL, with the Microsoft Identity Broker. The 3.0.1 release in March 2026 was a major architectural shift, and if you upgraded without following the migration steps, every Linux device in your fleet is likely failing authentication silently.
The old broker was Java-based. The new one is written in C++. This isn't a minor update, the entire service architecture changed. Device certificates moved from the keychain to /etc/ssl/private. The service names changed. The D-Bus interface changed. If any of your scripts, monitoring tools, or startup configurations reference old names, they need updating.
First, confirm your broker version:
dpkg -l microsoft-identity-broker # Ubuntu
rpm -q microsoft-identity-broker # RHELIf you're on 3.0.x but users are still failing authentication, check whether re-enrollment happened. After the upgrade, every user must re-register and re-enroll. This is non-negotiable per Microsoft's official guidance. Have users run:
dsreg --leave
dsreg --joinVerify the new service is running under its correct name:
systemctl status microsoft-identity-devicebrokerNote: there is no longer a separate microsoft-identity-broker user service. The user broker is now an executable invoked over D-Bus, not a persistent daemon. If your monitoring alerts on the absence of that service, update your monitoring, it's supposed to be gone.
For device certificates, check that /etc/ssl/private contains the expected files after enrollment. The broker creates a device certificate per tenant, a session transport key per tenant, and a deviceless key. If those files are missing or have wrong permissions, enrollment failed mid-way.
To install the broker correctly on Ubuntu production:
sudo apt install curl gpg
curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo install -o root -g root -m 644 microsoft.gpg /usr/share/keyrings
rm microsoft.gpg
sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/ubuntu/$(lsb_release -rs)/prod $(lsb_release -cs) main" >> /etc/apt/sources.list.d/microsoft-ubuntu-$(lsb_release -cs)-prod.list'
sudo apt update
sudo apt install microsoft-identity-brokerOnce the service is healthy, re-run dsreg --status and confirm the device shows a valid join state and tenant association.
Advanced Entra Device Management Troubleshooting
Reading the Right Event Logs
When dsregcmd /status points to a problem but doesn't tell you why, Event Viewer is your next stop. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > AAD. The most useful channel is Operational. Filter for Event ID 1098 (device registration failures) and 1097 (successful registrations). Error code 0x801c0021 in these logs means the device registration endpoint is unreachable, check your firewall rules for enterpriseregistration.windows.net.
For Hybrid Join specifically, check the User Device Registration logs under the same path. Event ID 304 is a hybrid join attempt, and Event ID 306 tells you whether it succeeded. If you see 306 with error 0x801c03f2, the SCP (Service Connection Point) in your on-premises AD isn't configured correctly.
Service Connection Point for Hybrid Join
Hybrid join depends on a Service Connection Point object in your on-premises Active Directory. When a domain-joined machine boots, it queries AD for this object to find the Entra tenant ID. If the SCP is missing or points to the wrong tenant, hybrid join silently fails. Check it:
Get-ADObject -Filter {objectClass -eq "serviceConnectionPoint" -and Name -eq "62a0ff2e-97b9-4513-943f-0d221bd30080"} -Properties * | Select-Object keywordsThe keywords field should contain your tenant ID and domain name. If it's empty or wrong, run the Azure AD Connect configuration wizard and re-run the hybrid join configuration steps.
Group Policy for Entra Device Management
For Windows 10/11 hybrid join, the relevant GPO setting lives at Computer Configuration > Administrative Templates > Windows Components > Device Registration. Enable "Register domain joined computers as devices". Without this, domain-joined machines will never attempt hybrid join, even if the SCP is perfectly configured.
Also check that the MDM enrollment GPO isn't conflicting. If you have both GPO-based enrollment and Autopilot configured for the same devices, they can fight each other and produce incomplete enrollment states.
Conditional Access Policy Conflicts
When a user hits an access block that you can't explain, pull the sign-in logs. In Entra admin center, go to Identity > Monitoring & health > Sign-in logs. Find the failed sign-in, click it, and open the Conditional Access tab. This shows every policy that evaluated, whether it applied, and what the grant result was. It's the single most useful troubleshooting screen in the entire Entra portal.
Escalate to Microsoft Support if you see persistent error AADSTS700016 (application not found in tenant) after device join, or if your PRT consistently fails to acquire even after re-joining on multiple machines, that's a tenant-level configuration issue that requires Microsoft's backend tooling to diagnose. Also escalate if hybrid join works in your dev environment but fails in production despite identical GPO and SCP configuration; tenant-side replication lag can cause this and only Microsoft can verify it.
Prevention & Best Practices for Entra Device Management
Getting Entra Device Management set up correctly is one thing. Keeping it healthy across a fleet of hundreds or thousands of devices is another challenge entirely. Here's what I've seen work in practice for organizations that run tight, low-incident Entra deployments.
First: treat device identity hygiene as a regular maintenance task, not a one-time setup. Microsoft's documentation explicitly recommends building a process to find and remove stale device objects. A device that was decommissioned six months ago but still has an active identity object in Entra ID is a security gap, especially if it was Entra joined with device-level trust. Build a monthly review into your IT calendar.
From PowerShell, you can pull all devices that haven't signed in within 90 days:
$cutoff = (Get-Date).AddDays(-90)
Get-MgDevice -All | Where-Object {$_.ApproximateLastSignInDateTime -lt $cutoff} | Select-Object DisplayName, ApproximateLastSignInDateTime, TrustTypeSecond: use named locations in Conditional Access to create a baseline of "trusted networks." This lets you apply stricter MFA policies to sign-ins from unknown locations while keeping the experience smooth for users on your corporate network. Go to Protection > Conditional Access > Named locations and define your office IP ranges.
Third: don't skip the What If tool before deploying any new Conditional Access policy. Every time. I've watched a misconfigured policy go live and block the entire IT department because it accidentally included admin accounts. Test with real user and device combinations before you enable in production.
For Linux deployments, pin your microsoft-identity-broker package to the stable channel and never use insiders-fast on production machines. The insiders-fast channel can contain breaking changes, Microsoft documents this explicitly. Set up package hold rules:
sudo apt-mark hold microsoft-identity-broker # Ubuntu- Run
dsregcmd /statuson every new device before users start working, catch join failures before they become support tickets. - Enable the Microsoft Entra sign-in health workbook in your Entra admin center to get automated alerts on authentication anomalies across your fleet.
- Set up a monthly stale device cleanup script using Microsoft Graph PowerShell, aim to disable devices inactive for 60 days and delete at 90 days after review.
- Document your Conditional Access policy intent in the policy description field, six months from now, you or your successor will thank you for it.
Frequently Asked Questions
What is a device identity in Microsoft Entra ID and why does it matter?
A device identity is an object in Microsoft Entra ID, similar to a user or group object, that represents a specific physical or virtual machine. Administrators use it to make access decisions: conditional access policies check the device's join state and compliance status before granting access to apps or resources. Without a device identity, the device is treated as an unmanaged endpoint and will be blocked by most modern zero-trust policies. Device identities are also the prerequisite for Mobile Device Management through Intune and for device-based SSO that doesn't require a password prompt on every sign-in.
What's the difference between Microsoft Entra registered vs. Entra joined devices?
Entra registration creates a trust tied to a specific user profile on the device, it's designed for BYOD scenarios like personal phones or home laptops where the user wants to access company resources without giving the organization full control of the machine. Entra join creates a full device-level trust for the entire machine, not just one user profile. Joined devices can satisfy stricter conditional access policies, benefit from SSO to on-premises resources, and are the correct choice for organization-owned Windows 10/11 machines. If your device is registered when it should be joined, conditional access policies requiring a "compliant device" or "Entra joined device" will block access even if the user's credentials are perfectly valid.
What is enterprise state roaming and how does it work with Entra Device Management?
Enterprise State Roaming lets users sync their Windows settings and app data across multiple Entra joined devices, so if someone gets a new laptop, their browser settings, desktop preferences, and certain app configurations follow them automatically. It's different from regular consumer Microsoft account sync because it keeps enterprise data in Azure storage under your tenant's control, with the option to apply data governance and retention policies. To enable it, go to Identity > Devices > Enterprise State Roaming in the Entra admin center and enable it for your target users or groups. The device must be Entra joined (not just registered) for Enterprise State Roaming to work.
Why do my Linux users keep getting prompted for MFA after I upgraded to Microsoft Identity Broker 3.0.x?
The 3.0.x release introduced a fundamental architectural change, from a Java-based to a C++-based broker, that requires every user to re-register and re-enroll their device after the upgrade. If they didn't do that, the broker has no valid device certificates and can't produce an authenticated device identity token, which forces full MFA on every sign-in. Have each user run dsreg --leave followed by dsreg --join and then complete one MFA sign-in to seed the new certificate chain. Also verify the service is running as microsoft-identity-devicebroker, not under its old name, and that device certificates exist in /etc/ssl/private.
How do I fix Entra Hybrid Join when it works in dev but fails in production?
The most common culprit here is a Service Connection Point misconfiguration in your production Active Directory, or a firewall blocking enterpriseregistration.windows.net in the production network segment that your dev environment doesn't have. Start by running dsregcmd /status on a failing machine and check the Diagnostic Data section for the specific error code. Then check Event Viewer under Applications and Services Logs > Microsoft > Windows > User Device Registration for Event ID 304/306 with error details. If the SCP is correct and network access is confirmed, the issue may be Azure AD Connect sync lag, device registrations can take up to 30 minutes to propagate in some tenant configurations.
Can I use phishing-resistant MFA with Linux devices managed through Entra?
Yes, as of the 3.0.1 Microsoft Identity Broker release in March 2026, Linux devices fully support Phish Resistant MFA (PRMFA). You can authenticate using a SmartCard, Certificate Based Authentication (CBA), or a FIDO2 key with a PIV profile. To set this up, go to Protection > Authentication methods in the Entra admin center, enable Certificate-based authentication, and configure your PKI trust chain. For FIDO2, enable Passkeys under the same menu and scope it to the user group that includes your Linux users. The Linux broker version 3.0.1 also introduced DUNA cross-platform support and DUNA iOS CBA, expanding phishing-resistant options beyond the desktop.