When a board member asks "Are we protected?", the answer depends on more than just having security tools deployed—it hinges on whether those tools can actually enforce policies on every device accessing your resources. The distinction between Microsoft Entra Joined and Entra Registered devices fundamentally shapes what controls you can apply, which authentication methods you can enforce, and how confidently you can answer that question.
What are the security differences?
Microsoft Entra Joined devices use organizational accounts to sign in at the Windows OS level, binding the device identity to every logon and enabling device-bound cryptographic tokens protected by TPM hardware. Entra Registered devices maintain local or personal accounts for OS sign-in, adding organizational identity only for app-level access.
This architectural difference cascades into everything else:
- Joined devices support passwordless authentication at the Windows lock screen, enforce BitLocker encryption silently, and satisfy Conditional Access policies requiring compliant devices by default.
- Registered devices deliver app-level protection through MAM policies and require explicit MDM enrollment to meet device compliance requirements.
From a security posture perspective, Joined devices are first-class organizational assets with full visibility and control. Registered devices are guests in your environment—protected at the application boundary but fundamentally outside your device management sphere unless you explicitly enroll them.
Definitions and key concepts
Before understanding how these join states differ operationally, let's establish the foundational concepts that shape their security architectures.
Microsoft Entra Joined
A device registration state where the device joins only to Microsoft Entra ID and requires an organizational account to sign in. The organization owns the device, controls local administrator access, and enforces device-wide policies.
Microsoft Entra Registered (Workplace Joined)
A device registration state where the device registers to Microsoft Entra ID without requiring an organizational account for OS sign-in. Typically used for BYOD scenarios where users maintain personal control over the device.
Hybrid Joined
Devices joined to both on-premises Active Directory and Microsoft Entra ID, inheriting characteristics of both environments—mentioned here for context but outside this comparison's scope.
Primary Refresh Token (PRT)
A key artifact of Microsoft Entra authentication specially issued to Microsoft first-party token brokers to enable single sign-on across applications. The PRT carries device and user claims evaluated during Conditional Access policy enforcement.
TPM Protection
A hardware component built into a device that provides hardware-based security functions for user and device secrets. When available, cryptographic keys securing the PRT are bound to the TPM, preventing token theft and replay attacks.
Device Compliance vs MAM
Device compliance policies require MDM enrollment and assess the entire device against security baselines (encryption status, OS version, firewall state). Mobile Application Management (MAM) or app protection policies enforce controls only within managed applications—no device enrollment required.
Conditional Access Controls
Policy gates that evaluate signals (user, device, location, risk) before granting access to resources. Two critical controls for device identity: "Require device to be marked as compliant" (device-level) and "Require app protection policy" (app-level).
Device Filters (trustType)
A Conditional Access condition that allows administrators to target specific devices using supported operators and device properties. The trustType property differentiates between AzureAD (Joined), ServerAD (Hybrid Joined), and Workplace (Registered) devices.
Comparison matrix
The following table consolidates the key differences across security capabilities, authentication methods, and management scope:
Identity and token protections
The security model for each join state is built on fundamentally different token issuance and protection mechanisms.
OS Sign-in and SSO architecture
The most consequential difference between join states manifests at boot.
For Entra Joined devices, a PRT is issued during Windows sign-in when a user signs in with their organization credentials, with the CloudAP plugin serving as the primary authority. This means organizational identity is established before any application launches, and every subsequent app or browser session inherits that trusted device context.
For Entra Registered devices, a PRT is issued when a user adds a secondary work account, with the WAM plugin serving as the primary authority. Windows itself remains signed in with a personal account. The organizational PRT exists only for application-level SSO (Microsoft 365 apps, Edge, Teams) but Windows logon itself has no organizational awareness.
This architectural distinction determines where trust begins. Joined devices establish organizational trust at the foundation layer (OS); Registered devices bolt it on at the application layer.
PRT/device-bound keys and TPM
During device registration, the dsreg component generates two sets of cryptographic key pairs:
- Device key (dkpub/dkpriv) and
- Transport key (tkpub/tkpriv)
When the device has a functioning TPM, these private keys are bound to the hardware.
When Microsoft Entra ID issues a PRT, it also issues an encrypted session key to the device, encrypted with the public transport key. Only the private transport key, secured in the TPM, can decrypt this session key. The session key acts as the Proof-of-Possession key for any requests sent to Microsoft Entra ID.
The practical implication: Even if an attacker extracts a PRT from memory, they cannot use it without also proving possession of the session key, which requires access to the TPM-secured private key. This binds the PRT to the physical device, mitigating credential theft and token replay attacks.
Both join states benefit from TPM protection when available, but Joined devices have stronger guarantees because the organizational PRT is established at OS sign-in with hardware-backed credentials like Windows Hello for Business.
Strong authentication at the Windows logon screen
Token architecture determines backend security; authentication methods determine the user experience at the lock screen.
Passwordless and SSPR
Here's where the architectural difference becomes user-facing.
FIDO2 security keys require Microsoft Entra joined or hybrid joined Windows devices, as does self-service password reset (SSPR) from the Windows lock screen. Registered devices cannot satisfy these scenarios because Windows itself doesn't authenticate against Entra ID—only applications do.
This limitation extends to Windows Hello for Business in its full implementation. While Registered devices can use Windows Hello (the consumer version) for local sign-in, they miss the organizational integration, on-premises SSO capabilities, and centralized PIN reset that WHfB provides to Joined devices.
For organizations pursuing passwordless authentication strategies, this is a hard gate: BYOD devices in Registered state cannot participate in passwordless Windows logon.
Conditional access: What you can enforce
Understanding join states matters most when translating them into enforceable access policies.
Device-based enforcement
The question that matters: Can you require compliant devices?
The answer: Yes, for both join states, if the device is MDM-enrolled and reporting compliant. The "Require device to be marked as compliant" control requires devices accessing resources be marked as compliant with Intune compliance policies.
The catch: Microsoft Entra registration can be accomplished when accessing a work application for the first time, but device compliance requires MDM enrollment. Registration alone provides device identity for Conditional Access evaluation, but without enrollment, there's no compliance status to evaluate.
Scenario examples:
- Joined device with compliance: Device is Entra Joined, automatically enrolled in Intune via Windows Autopilot, compliance policy evaluates encryption + firewall + AV state → passes "Require compliant device" gate
- Registered device with MDM: User adds work account to personal iPhone, prompted to enroll in Intune, device meets iOS compliance policy → passes "Require compliant device" gate
- Registered device without MDM: User adds work account to personal Windows PC, registration succeeds, no enrollment → fails "Require compliant device" gate
App-level enforcement for BYOD
When you cannot or will not enroll personal devices, app protection policies provide the alternative.
Organizations can use "Require app protection policy" or "Require approved client app" to protect data without enrolling the device. These controls enforce encryption of org data within the app, prevent copy/paste to unmanaged apps, require app-level PIN, and enable selective wipe—all without touching personal data or requiring device management.
This is the typical BYOD model for Registered devices: registration + MAM + no enrollment.
Targeting by join state
Conditional Access "Filter for devices" allows administrators to use trustType to include or exclude Entra Joined, Registered, or Hybrid Joined devices.
Example policy logic:
- Policy A: Require MFA for all access except from devices where
device.trustType -eq "AzureAD"(Joined devices) - Policy B: Block access to finance systems except from devices where
device.trustType -in ["AzureAD", "ServerAD"](Joined or Hybrid Joined only) - Policy C: Require app protection for all access from devices where
device.trustType -eq "Workplace"(Registered devices)
This granular targeting allows you to architect risk-appropriate controls: high-trust for managed endpoints, low-trust for BYOD.
Endpoint management depth and policy coverage
Join state doesn't just affect authentication—it determines the entire scope of device management capabilities.
Entra Joined (org-owned)
Joined devices are organizational assets under full MDM management. Administrators can enforce organization-required configurations like requiring storage to be encrypted, password complexity, software installation, and software updates.
BitLocker can be silently enabled on Entra Joined devices without user interaction, with recovery keys automatically escrowed to Entra ID and Intune The device must meet specific prerequisites (Windows 10 1803+ for admin users, 1809+ for standard users, UEFI BIOS mode, TPM 1.2+) but when configured correctly, encryption happens transparently.
This silent enablement eliminates the traditional barrier of user consent for disk encryption and ensures consistent coverage across the fleet. Registered devices cannot achieve this because they lack the OS-level organizational management required.
Policy scope for Joined devices extends to every security baseline component: Windows Firewall rules, Microsoft Defender ATP configuration, update rings, compliance policies, configuration profiles, application deployment, local administrator rights management.
Entra Registered (BYOD by default)
Microsoft Entra registration provides device identity and SSO, but device-wide controls require explicit MDM enrollment and compliance policies. Without enrollment, protection is limited to app-scoped MAM policies with selective wipe capabilities.
For many BYOD scenarios, this is appropriate: Employees use personal devices to access email and Teams, org data stays encrypted within those apps, personal data remains private and unmanaged. When employees leave, you wipe org data from the apps without touching personal photos, messages, or settings.
However, if compliance requirements demand device-level assurance—encryption status, OS patch level, jailbreak detection—you must enroll Registered devices into MDM. At that point, the device becomes partially managed: you can enforce compliance checks and limited configuration policies while still respecting personal device ownership boundaries.
Local administrator governance (Windows)
For Entra Joined devices, administrators can use Entra roles to manage local administrator membership. You can assign Entra users or groups to the local Administrators group on all Joined devices, centrally controlling who has elevated privileges on endpoints.
This model doesn't extend to Registered devices because they maintain local account management. The device owner remains in control of local administrator access—appropriate for personal devices, but a blind spot for security teams accustomed to centralized privilege governance.
Deciding between join states
The decision ultimately maps to device ownership, data classification, and risk tolerance:
Choose Entra Joined when:
- Organization owns the device
- Handling sensitive or regulated data (HIPAA, PCI DSS, SOX)
- Passwordless authentication is required
- Compliance policies must be enforced at device level
- BitLocker encryption is mandatory
- Centralized local admin control is necessary
Choose Entra Registered when:
- Employee or contractor owns the device (BYOD)
- Accessing primarily low-risk applications (email, calendar, chat)
- App-level data protection via MAM is sufficient
- Cannot or will not enforce device management
- Supporting iOS/Android mobile devices
Choose Entra Registered + MDM Enrollment when:
- BYOD scenario but compliance gates are required
- Need device-level encryption validation
- Auditors require device compliance evidence
- Access to high-value resources from personal devices
The underlying principle: Match the control depth to the data classification and threat model. Joined devices provide defense in depth; Registered devices provide flexible access with application-boundary protection.
For organizations using Prelude, this device state visibility integrates directly into continuous control monitoring: identifying devices missing from your management platforms, flagging misconfigured compliance policies, and mapping your actual device coverage against threat intelligence. The join state isn't just a technical attribute—it's the foundation of your endpoint security posture.
