Windows enrollment looks simpler than it is. Entra ID join, hybrid join, and device registration are easy to conflate – they all result in a device appearing in your tenant, and the differences between them aren’t always obvious until something downstream behaves unexpectedly.
The distinctions matter because they determine what the device actually is, what authority it operates under, and what Intune can reliably do with it. Treating them as interchangeable is one of the more reliable ways to create troubleshooting problems that are hard to explain after the fact.
There are three Windows enrollment outcomes that matter in practice. Microsoft supports all three and Intune can interact with all three – but they don’t grant the same management authority, and they don’t behave the same way once a device is in the system.
Entra ID-joined devices are the model Intune is designed around. There’s no on-premises Active Directory dependency. Authentication goes straight to Entra ID. The device gets a Primary Refresh Token that evaluates continuously and behaves predictably. Policy evaluation is consistent. Conditional Access logic is clean. When a user signs in, the device is owned by the cloud identity plane – Intune is central, not supplemental.
This is the target state. Autopilot assumes it. New Intune capabilities land here first. If you’re designing a greenfield environment or working through a device refresh cycle, this is the outcome you’re building toward. Everything else in this series is either optimized for this model or managing the gap between where an environment currently is and where it needs to go.
Hybrid join is a compromise. That word matters – a compromise implies constraints, and those constraints become visible the further you push into cloud-native management.
Hybrid Entra ID-joined devices remain domain-joined to on-premises Active Directory. Entra ID represents the device through synchronization but doesn’t own it. Group Policy still applies and wins for overlapping configuration areas unless you’ve explicitly configured MDM to take precedence. Certain authentication flows require domain controller reachability – which matters for remote workers or devices shipped directly to users without VPN access.
Hybrid join is a legitimate transitional model for environments where on-premises dependencies are real and can’t be retired quickly. The constraint worth being honest about is that it limits what Intune can reliably own. Autopilot with hybrid join adds infrastructure dependencies and tighter timing requirements that don’t exist in the cloud-native model. These aren’t hypothetical concerns – they surface consistently in production at scale.
Device registration creates an Entra ID record and enables Conditional Access evaluation, but it doesn’t enroll the device into Intune for full management. The distinction is easy to miss and consequential when you do.
When a user adds a work account to a personal device, the device becomes registered – visible in your tenant, evaluable by Conditional Access, eligible for app protection policies. What it isn’t is managed. Full device configuration profiles don’t apply. Without clear enrollment restrictions, registered personal devices can accumulate in your tenant and create false confidence about what’s actually under management control.
The enrollment outcome determines what Intune can actually do with a device. Getting clarity on which outcome you’re targeting before a device arrives in the portal is what makes policy assignment, Autopilot, compliance evaluation, and Conditional Access behave the way you expect – rather than the way you assumed.
Intune Deployment Guide · Phase 3: Device Entry
‹ Previous: [3.2] Hybrid Devices: What Works, What Doesn’t, and Why It’s a Stopgap
Next: [3.2.2] Configuring Automatic Enrollment Scope ›
