An admin runs a device audit, filters Entra ID by trust type, and finds forty devices sitting there as "Microsoft Entra registered." Their gut reaction: that sounds like the weak, unmanaged category — the one where anyone's laptop can show up half-configured. So they open a ticket to "convert" all forty into fully Entra joined devices. Two days later, a support queue fills up with users who can no longer get to Outlook or SharePoint from their personal phones and home PCs. Nothing was compromised. The admin just tried to fix something that was never broken — a BYOD access pattern, not a security hole.
This mix-up is common enough that it deserves its own post. There are three Microsoft Entra device trust types — joined, hybrid joined, and registered — and they are not tiers of the same ladder where "joined" is the gold standard and "registered" is the consolation prize. They solve three different problems. Confusing them is how you end up breaking BYOD access for an entire team while chasing a security improvement that was never on the table.
The problem — trust type gets misread as a security rating instead of a use-case label
Here's the exact symptom. An admin opens the Microsoft Entra admin center, goes to Devices > All devices, and sorts by the Join Type column. They see a mix of Microsoft Entra joined, Microsoft Entra hybrid joined, and Microsoft Entra registered. Because "registered" sounds like the least-committed option — no domain join, no full enrollment requirement — it gets treated as the least trustworthy one.
The instinct that follows is predictable: force those "registered" devices through full Entra join or hybrid join so they're "properly managed." In practice that means either asking users to wipe and re-provision personal devices through Autopilot (which they will refuse, because it's not their device to hand over), or trying to push a domain-join policy at a personal Android phone or iPad, which simply isn't a supported target for that trust type at all.
Why it happens — three trust types solve three different ownership and management problems
The confusion comes from treating "Entra joined," "Entra hybrid joined," and "Entra registered" as points on a single spectrum from "insecure" to "secure." They aren't. Each one answers a different question: who owns this device, and what job does the organization need it to do?
Microsoft Entra registered (also called Workplace joined) exists for bring-your-own-device and mobile scenarios. Per Microsoft's own documentation, it is "registered to Microsoft Entra ID without requiring organizational account to sign in to the device." Device ownership can be user or organization, the user signs in with their own local account (a personal Microsoft account, a local Windows account, or the device's native sign-in), and the device gets a Microsoft Entra account layered on top purely for accessing organizational resources. It supports single sign-on to cloud resources, Conditional Access when the device is enrolled into Intune, and Conditional Access via app protection policy even when it isn't.
Microsoft Entra joined is for organization-owned devices, cloud-only or hybrid. Definition, straight from Microsoft: "joined only to Microsoft Entra ID requiring organizational account to sign in to the device." Device ownership is organization, users sign in with their Microsoft Entra account directly, and it supports single sign-on to both cloud and on-premises resources, full Conditional Access, and self-service password reset with Windows Hello PIN reset from the lock screen.
Microsoft Entra hybrid joined is for organizations that still run on-premises Active Directory. Definition: "joined to on-premises Microsoft Windows Server Active Directory and Microsoft Entra ID requiring organizational account to sign in to the device." Device ownership is again organization. The device is domain-joined the traditional way and then auto-registered into Entra ID via Microsoft Entra Connect or AD FS. Critically, hybrid joined devices need periodic network line of sight to your on-premises domain controllers — without it, per Microsoft's guidance, "devices become unusable."
| Trust type | Graph trustType value | Device ownership | Identity source | Key SSO/sign-in scope |
|---|---|---|---|---|
| Microsoft Entra registered | Workplace | User or organization | Local/personal account + layered Entra account | SSO to cloud resources; CA via Intune enrollment or app protection policy |
| Microsoft Entra joined | AzureAd | Organization | Microsoft Entra account (cloud-only or synced) | SSO to cloud and on-premises resources; full Conditional Access |
| Microsoft Entra hybrid joined | ServerAd | Organization | On-premises AD account, synced to Entra ID | SSO to cloud and on-premises; requires periodic domain controller reachability |
trustType values (Workplace, AzureAd, ServerAd) come directly from the Microsoft Graph device resource definition, not from marketing terminology. They're what actually gets stored on the device object and what you filter on in PowerShell or Graph queries — the admin center just relabels them as "registered," "joined," and "hybrid joined" for readability.None of these three is a hardened or weakened version of another. A registered personal phone with Intune app protection policies enforcing encryption and PIN requirements on the Outlook app can be a perfectly reasonable security posture for BYOD email access — arguably a better one than trying to force full management onto a device the organization doesn't own and has no legal right to fully control.
Microsoft's own worked examples make the point better than abstract definitions do. A user wants to access a benefits enrollment tool from their home PC, and the organization requires that tool to only be accessed from an Intune-compliant device — the user registers their home PC with Microsoft Entra ID, enrolls it in Intune, and the required compliance policies get enforced. Same trust type, different example: a user tries to access organizational email on a rooted personal Android phone, the org has an Intune compliance policy blocking rooted devices, and the employee is stopped cold. In both cases the device is Microsoft Entra registered — the trust type isn't what determined the outcome, the compliance policy applied on top of it did.
Ownership also shifts the supported operating system list in ways that matter operationally. Microsoft Entra registered devices span Windows, macOS, iOS, Android, and specific Linux distributions (Ubuntu 22.04/24.04 LTS and RHEL 8/9 LTS at time of writing) precisely because BYOD covers whatever hardware a user already owns. Microsoft Entra joined and hybrid joined devices are scoped to Windows 11/10 (non-Home editions), specific Windows Server versions, and — for Entra join specifically — macOS 13+ and a narrower Linux list, because those are organization-owned fleets being provisioned deliberately rather than devices arriving however a user happens to own them.
How to verify — check what trust type a device actually has before assuming anything
Don't guess from the device name or from what you remember provisioning it as. Confirm the real trust type using either the device itself or Microsoft Graph.
On the device itself, the fastest local check is dsregcmd /status, run from an elevated or standard command prompt on the Windows machine in question. It reports the join state directly.
From the admin side, the Entra admin center shows the same information per device without needing console access to the machine.
For scripted, tenant-wide verification instead of one device at a time, query the Microsoft Graph device resource's trustType property directly with Get-MgDevice.
trustType is set once at registration time and is read-only through the API — you can't just "flip" a device from Workplace to AzureAd by editing the property. Changing trust type means re-provisioning the device through a different join flow (Autopilot, bulk enrollment, OOBE) — it is not a settings toggle, and that's exactly why forcing "registered" devices into "joined" causes so much disruption.The fix — pick the right trust type for the scenario, not the "most secure-sounding" one
The right fix here usually isn't a technical change to existing devices at all — it's recognizing that the trust type already in place matches the scenario, and building the correct Conditional Access and Intune app protection controls around it instead of trying to convert it.
- Sign in to the Microsoft Entra admin center.
- Select Identity > Devices > All devices.
- Filter or sort by the Join Type column and identify which devices show Microsoft Entra registered.
- Select one of those devices, then check Owner under device properties — a personal device will typically show an individual user, not a bulk-provisioning identity.
- If the owner is a real person and the device type is a phone, tablet, or personally-owned PC, this is very likely intentional BYOD access. Stop here — do not convert.
- If you genuinely need stronger controls on that access, go to Intune admin center > Apps > App protection policies and apply or tighten a policy targeting the relevant Microsoft 365 apps instead of the device itself.
If a device really was meant to be an organization-owned, fully managed machine and it ended up registered by mistake — for example, a user set it up themselves before IT could provision it through Autopilot — the correct remediation is to re-provision it through the intended join flow, not to modify the existing device object.
- Confirm with the user that the device is organization property, not personal.
- In the Intune admin center, go to Devices > Windows > Windows devices, locate the existing registered device record, and remove it if it will be wiped and re-enrolled.
- Register the device's hardware hash with Windows Autopilot, or add it to the appropriate bulk-enrollment/Group Policy autojoin configuration for hybrid join.
- Reset or reimage the device so it goes through Out-of-Box Experience (OOBE) again, this time completing Microsoft Entra join or hybrid join instead of a personal Workplace Join.
- Confirm the resulting trust type with
dsregcmd /statusorGet-MgDevicebefore considering the device fully migrated.
Proof it worked — see the real distribution of trust types across the tenant, not just one device
Once you understand what each trust type is for, the useful operational question isn't "is this device secure enough" — it's "does our tenant's actual trust type distribution match what we expect, given how many BYOD users versus corporate-owned machines we have." A skewed distribution — say, far more Workplace devices than expected — is worth investigating, but the investigation is "why are so many corporate devices unmanaged," not "registered devices are inherently risky."
The companion script for this post, Get-EntraDeviceTrustTypeReport.ps1, is read-only. It calls Get-MgDevice -All against the tenant, groups every device object by its trustType property, and reports both a summary count per type and a full per-device table. It makes no writes anywhere — no Update-MgDevice, no Remove-MgDevice, nothing that touches a device record.
Get-EntraDeviceTrustTypeReport.ps1 is free and open source. It's a genuinely read-only script — no writes to Autopilot, Intune, or Entra ID.
trustType value it doesn't recognize (only Workplace, AzureAd, and ServerAd are documented) and separately reports devices where trustType is blank or null, rather than silently grouping them away or guessing at what they mean. Run it before making any tenant-wide decision about device trust posture — a spreadsheet guess is not a substitute for the actual distribution.References
- What are Microsoft Entra registered devices? — Microsoft Learn
- What is a Microsoft Entra joined device? — Microsoft Learn
- What is a Microsoft Entra hybrid joined device? — Microsoft Learn
- device resource type (trustType property) — Microsoft Graph v1.0 reference
- Get-MgDevice — Microsoft Graph PowerShell reference