Entra Device Identity: Join, Hybrid Join and Device Trust Security

Every Conditional Access rule that says "trusted device" rests on a device object in Microsoft Entra ID, and when those objects are the wrong type, stale, duplicated or created through a poorly controlled hybrid join path, the device signal stops meaning anything. A device identity is a directory object, like a user or application, created when a device is registered, joined or hybrid joined, and protected by a device key and certificate. This guide covers how to choose between registered, joined and hybrid joined, how hybrid join actually works and how to troubleshoot it, the roles that control devices, the on-premises dependencies that make hybrid join a tier zero concern, stale device cleanup, and how device state and compliance feed access decisions. It is written for identity and endpoint engineers running Entra ID. Attacker abuse of registration and the tenant settings that stop it are in the Rogue Device Registration, and the policy side is in the Conditional Access Guide; neither is repeated here.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Pick the join type by ownership and management. Registered for personal and mobile devices, Entra joined for organisation-owned Windows, and hybrid join only where on-premises Active Directory dependencies still require it; Microsoft describes hybrid join as an interim step toward Entra join.
• Hybrid join inherits on-premises risk. It depends on Entra Connect, the service connection point and, in federated domains, AD FS endpoints, so whoever controls those controls which devices become trusted.
• Hybrid joined is not compliant. "Require Microsoft Entra hybrid joined device" proves domain membership, not health; pair it with, or replace it by, "Require device to be marked as compliant".
• Clean stale devices with care. The activity timestamp only updates every 14 days or so, deleting a device deletes its BitLocker keys, and Autopilot devices must never be deleted from Entra ID directly.
• dsregcmd /status is the source of truth on the endpoint. AzureAdJoined, DomainJoined, DeviceAuthStatus, TpmProtected and AzureAdPrt tell you what the device really is and whether it can sign in.

How identity and access work for Entra devices

When a device registers, it creates a key pair, receives a device certificate and gets a device object with a DeviceId in the tenant. Registered and joined devices get single sign-on to cloud resources, and Entra joined devices also get SSO to on-premises resources. Device identities are the prerequisite for device based Conditional Access. The three states can coexist in one tenant.

Choosing a join type

• New organisation-owned Windows: Entra join with Autopilot and Intune avoids AD dependencies, line of sight requirements and Group Policy drift. See the Retiring Active Directory.
• Existing domain joined fleet: hybrid join gives cloud SSO and device based Conditional Access without rebuilding devices. Plan it as a bridge with an exit date.
• Servers: hybrid join supports Windows Server 2016, 2019 and 2022; as of November 2026 the Microsoft docs place Server Core outside device registration, so confirm options with Microsoft.
• Personal phones and tablets: registration plus app protection or compliance policies; never join a personal device.
• Small organisations without on-premises dependencies should go straight to Entra join. Large enterprises usually run all three states for years, which makes inventory and cleanup the main ongoing work.

How hybrid join works

Microsoft's configuration guidance lists Entra Connect 1.1.819.0 or later, default device attributes left in sync, and OU based filtering that includes the OUs holding computer objects. The Entra Connect wizard (Configure device options, then Configure Microsoft Entra hybrid join) writes the service connection point per forest and needs Hybrid Identity Administrator in Entra plus Enterprise Administrator in each forest.

• Managed domains (password hash sync, or pass-through authentication with seamless SSO): the device completes registration once Entra Connect has synchronised its computer object. A join attempt before sync shows Client ErrorCode 0x801c03f2 with DirectoryError in the join phase, which Microsoft documents as expected while sync is pending.
• Federated domains: AD FS must expose the WS-Trust windowstransport, usernamemixed and certificatemixed endpoints. The windowstransport endpoints must be intranet only and never published through the Web Application Proxy. On Windows 10 1803 or later, if instant join fails, Entra Connect sync completes it.
• Network: devices must reach enterpriseregistration.windows.net, login.microsoftonline.com and device.login.microsoftonline.com in system context. Authenticated proxies must authenticate the machine, not the user, and the two device endpoints must be excluded from TLS break and inspect or client certificate authentication fails.
• Line of sight: hybrid joined devices need periodic contact with domain controllers; device and user password changes and TPM resets break without it.
• Single forest, multiple tenants: SCP is then configured on the devices rather than in AD, and device writeback, group writeback, seamless SSO and on-premises Password Protection do not work.

Hybrid join edge cases

• UPN changes: Windows 10 builds before 2004 do not support UPN changes on hybrid joined devices; Microsoft's fix is an elevated dsregcmd /leave, after which the device rejoins automatically.
• Non-routable UPNs: routable UPNs work in federated (Windows 10 1703 or later) and managed (1803 or later) environments; non-routable UPNs work only in federated environments from 1803 and are not supported in managed ones.
• Staged rollout: moving from federation to cloud authentication with staged rollout needs Windows 10 1903 or later on hybrid joined devices.
• Virtual desktops: persistent and non-persistent VDI have their own device identity guidance; non-persistent pools in particular generate stale objects quickly if they register on every boot, so plan cleanup before go-live.
• Older Windows 10 builds: before 1803, remove any Entra registered state manually before enabling hybrid join to avoid dual state devices.

Troubleshooting with dsregcmd

The PRT that a joined device holds is covered in depth in the Entra ID Primary Refresh Token (PRT) Security Guide.

Admin roles and privileged access

• Cloud Device Administrator: a privileged role for managing devices in Entra ID, including disabling and deleting device objects, which Microsoft lists alongside Intune Administrator for stale device cleanup. Make it PIM eligible.
• Intune Administrator: manages all of Intune, including the compliance policies that decide whether a device is marked compliant. Whoever can loosen a compliance policy can make every device "trusted".
• Microsoft Entra Joined Device Local Administrator: members are added to the local Administrators group on every Entra joined device. Keep it small and replace standing local admin with Windows LAPS. See the Rogue Device Registration for the related device settings.
• Hybrid Identity Administrator and on-premises Enterprise Admins: required to configure hybrid join and able to change the SCP; treat as tier zero.

Integrations, API tokens and service accounts

Hybrid join ties device trust to the on-premises sync path. A foothold on the sync server or SCP would let an attacker influence which computer objects become hybrid joined devices. Protect the Entra Connect server, its sync accounts and the AD FS servers as tier zero; the Microsoft Entra Connect and Cloud Sync Hardening Guide covers how.

• Automation identities: stale device scripts call Microsoft Graph to update and remove devices; run them as a managed identity or certificate based app with only the device permissions they need, and log every removal.
• MDM partners: a non-Microsoft MDM can mark Windows devices compliant, which makes that integration's service principal a source of trust; review its permissions and owners.
• Device objects as identities: devices authenticate with a certificate and key, ideally TPM protected. They are non-human identities that need lifecycle, ownership and cleanup like any other.

Logging and detection

• Audit log, Device Registration Service and Core Directory: device added, device updated, device disabled and device deleted events, with the initiating actor. Alert on deletions by anyone other than the cleanup identity and on bulk changes.
• Sign-in logs: the device ID, join type and compliance state recorded per sign-in. Sign-ins from devices that are hybrid joined but non-compliant, or from unknown devices to sensitive apps, deserve review. See the Entra ID Sign-In and Audit Log Detection Guide.
• Inventory drift: computer objects in synced OUs that never reach hybrid joined, often stuck in a pending state, and duplicate device names with different DeviceIds after reimaging.

Hardening baseline

1. Decide the target state per device class and record it, so hybrid join has an owner and an end date.
2. Pilot hybrid join with targeted deployment on a group that spans roles and device types before enabling the SCP for everyone; roll back by removing the pilot devices from scope.
3. Remove inspection from device registration endpoints and give proxies machine context authentication.
4. Require compliance, not just join, for sensitive applications: use "Require device to be marked as compliant" (Intune for any OS, or a non-Microsoft MDM for Windows), and only fall back to hybrid joined with an "or" where compliance is not yet deployed. Remember device-code flow cannot satisfy device state controls. The Device Trust and Posture Guide covers building the compliance policy.
5. Clean stale devices on a schedule: list devices older than 90 days, back up BitLocker recovery keys, retire MDM devices in Intune first, disable for a grace period, then delete those still disabled and inactive at 120 days. Exclude Autopilot devices, and clean hybrid joined devices in on-premises AD so sync removes them.
6. Lock down local admin with Windows LAPS and a minimal Joined Device Local Administrator assignment.
7. Prefer TPM backed keys: TPM 1.2 is treated as no TPM from Windows 10 1903; plan hardware refresh accordingly.

Common misconfigurations

• Treating hybrid joined as healthy: a domain joined device with no endpoint protection still passes "Require Microsoft Entra hybrid joined device".
• Deleting instead of disabling: deletion is irreversible, removes BitLocker keys and can break Autopilot reprovisioning.
• Short stale thresholds: anything under about 21 days catches active devices because of the 14 day timestamp update window.
• Old images: Sysprep images captured from an already hybrid joined device (before 1809) create duplicate or broken registrations.
• Dual state devices: devices left both Entra registered and hybrid joined on older Windows 10 builds confuse policy evaluation; remove the registered state.
• Exposed WS-Trust endpoints: publishing windowstransport through the Web Application Proxy breaks Microsoft's guidance and exposes the federation path.

Framework mapping

Practitioner checklist

• Record the intended join state for each device class and an exit date for hybrid join.
• Confirm Entra Connect version, device attributes and OU scope before enabling hybrid join.
• Keep AD FS windowstransport endpoints intranet only and exclude device endpoints from TLS inspection.
• Use dsregcmd /status to verify join state, DeviceAuthStatus, TpmProtected and AzureAdPrt during rollout.
• Require compliant devices for sensitive apps rather than hybrid join alone.
• Run stale device cleanup with a 90 day disable and 120 day delete cycle, backing up BitLocker keys and excluding Autopilot devices.
• Make Cloud Device Administrator and Intune Administrator PIM eligible and alert on device deletions.
• Protect Entra Connect, AD FS and the SCP as tier zero.

Standards and references

• Microsoft Learn: What is device identity in Microsoft Entra ID?
• Microsoft Learn: Plan your Microsoft Entra hybrid join implementation
• Microsoft Learn: Configure Microsoft Entra hybrid join
• Microsoft Learn: Troubleshoot devices by using the dsregcmd command
• Microsoft Learn: How to manage stale devices in Microsoft Entra ID
• Microsoft Learn: Conditional Access grant controls
• Microsoft Learn: Microsoft Entra built-in roles
• MITRE ATT&CK: Account Manipulation, Device Registration

Related NHI Mgmt Group resources: Rogue Device Registration · Conditional Access Guide · Entra ID Primary Refresh Token (PRT) Security Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide