What actually happens when a device enrolls into Intune

 

Most people picture Intune enrollment as three steps: device shows up, you hit enroll, Intune takes over. In reality there's a whole chain of handoffs between identity, MDM, policy assignment, and compliance before a device is actually "managed." If you troubleshoot Intune for a living, knowing this chain is what separates "just re-enroll it" from actually finding where things broke.

Here's the flow end to end.

1. Identity comes first

Before anything else, the device or user authenticates against Microsoft Entra ID. Depending on the scenario, the device lands in one of three states:

• Entra Joined
• Entra Hybrid Joined
• Entra Registered

This identity state decides what's even possible later in the chain, so it's always the first thing worth checking when enrollment looks stuck.

2. Something has to trigger enrollment

Enrollment doesn't just happen on its own. It gets kicked off through one of several paths:

• Windows Settings
• Company Portal
• Windows Autopilot
• Group Policy
• Automatic MDM enrollment
• Co-management

Worth noting because the trigger method often explains why a device behaves differently than another one in the same policy scope.

3. The actual MDM enrollment

Once triggered, Windows establishes an MDM enrollment with Intune. This is the point where the management relationship is actually created — the thing that makes it possible to push down:

• Security policies
• BitLocker
• Wi-Fi/VPN profiles
• Certificates
• Configuration profiles
• Compliance policies

4. Device check-in

From here the device starts talking to Microsoft's cloud services to pull down management instructions. The path looks like:

Device → Microsoft Cloud → Intune → Device

This check-in is ongoing, not one-time — it's how the device keeps getting updated instructions after the initial enrollment.

5. Policy processing

Intune evaluates a combination of user, device, assignment, filters, and platform to figure out which policies actually apply. Once that's resolved, the applicable policies get delivered to the device, and Windows MDM/CSP takes over processing the configuration locally.

6. Application management

For workloads like Win32 apps, PowerShell scripts, and remediations, the Intune Management Extension (IME) becomes a critical piece. If IME isn't healthy on the endpoint, these workloads silently stop working even though the device still looks "compliant" on paper.

7. Compliance evaluation

The device gets checked against whatever compliance requirements apply — things like:

• BitLocker status
• Firewall status
• Antivirus status
• OS version

That compliance state then feeds directly into Microsoft Entra Conditional Access, which is often the point where a broken link earlier in the chain actually becomes visible to a user — they get blocked from a resource with no obvious explanation.

The troubleshooting mindset

Enrollment isn't "enroll, then apply policy." It's a chain:

Entra ID → MDM Enrollment → Intune → Assignment → Check-in → MDM/CSP → IME → Compliance → Conditional Access

Understanding this chain — not just the "Intune manages devices" headline version — is the actual foundation for troubleshooting enrollment and policy issues instead of guessing.