Automatic enrollment scope is the front door. Everything downstream – policy assignment, Conditional Access evaluation, compliance reporting – depends on what comes through it. This article covers how to configure it deliberately, using conservative defaults that are easy to expand and difficult to accidentally over-scope.
This is a configuration guide. It assumes familiarity with the design concepts in [3.1] Automatic Enrollment: Letting Devices In on Purpose and [3.2.1] Windows Enrollment Methods Explained. Where those articles explain the why, this one covers the how.
The MDM auto-enrollment user scope in Entra ID determines which users can trigger Intune enrollment during Entra ID join or interactive sign-in. This evaluation happens before a device appears in Intune – it’s the gate, not the fence. Only user group membership is evaluated at this stage. Intune assignment filters are not supported here.
Set MDM user scope to Selected, not All. Assign a licensing-based group – something like Licenses-Intune_Enabled or Licenses-E3_Users. Licensing already represents an intentional decision about who is an employee, who should access corporate data, and who is expected to have a managed device. Using the licensing group as the enrollment gate means break-glass accounts, service accounts, and privileged admin identities are excluded by default – because they typically aren’t licensed for Intune.
[Screenshot: Entra ID → Mobility (MDM and MAM) → Microsoft Intune → MDM user scope]
Using All users allows any authenticating identity to enroll devices. Enrollment scope is easy to expand later. It is rarely easy to retract cleanly.
Platform scoping and enrollment restrictions define what kinds of devices eligible users are allowed to enroll. Without this layer, a well-scoped user can still enroll a personal laptop, a home Mac, or an Android phone you never intended to manage.
Block personal device ownership by default across all platforms. This isn’t about preventing BYOD forever – it’s about setting a clear trust boundary at the moment a device enters management. Personal devices introduce ambiguity that doesn’t resolve cleanly after the fact. Ownership metadata can be adjusted, but once a personal device is enrolled, user expectations around monitoring and privacy are difficult to walk back. Enrollment mistakes are asymmetric: allowing personal devices by default and removing them later is significantly more disruptive than enabling personal enrollment deliberately when a real use case exists.
[Screenshot: Intune → Devices → Enrollment → Enrollment restrictions → Device type restrictions]
Exceptions exist and are valid. macOS BYOD with user-approved enrollment, Android Enterprise work profiles for personal devices, and contractor scenarios all have legitimate personal enrollment use cases. Configure those as separate restriction profiles scoped to specific groups – not as defaults that apply to everyone.
Device limits set a per-user ceiling on how many devices can be enrolled. The default is often too permissive. Set limits that reflect realistic expectations for your environment – most standard users don’t need more than two or three enrolled devices. Limits reduce blast radius from accidental over-enrollment and add a safety net during testing phases, but they don’t replace proper scope configuration. If device limits are doing the heavy lifting, enrollment scope is already too broad.
[Screenshot: Intune → Devices → Enrollment → Enrollment restrictions → Device limit restrictions]
Enrollment configuration should be group-driven, not toggle-driven. Start with static assigned groups for your initial enrollment scope, validate behavior, then introduce dynamic groups once membership rules are well understood. Document the purpose of each enrollment group – six months from now, someone needs to know why it exists before they change it.
The same failure patterns appear in almost every environment: test users left in enrollment scope, temporary exceptions never removed, personal devices enrolled before restrictions were in place. Each traces back to enrollment scope that was too broad from the start.
Review enrollment configuration periodically – it’s not a set-and-forget decision. Check device ownership distribution, join type distribution, and watch for unexpected personal devices appearing in the device list. Unexpected devices indicate a scope problem, not a provisioning problem. Catching that early costs minutes. Catching it after a hundred personal devices have enrolled costs considerably more.
[Screenshot: Intune → Devices → All devices – filtered by ownership and join type]
Intune Deployment Guide · Phase 3: Device Entry
‹ Previous: [3.2.1] Windows Enrollment Methods Explained
Next: [3.2.3] Hybrid Entra ID Join: How It Actually Works and How to Fix It When It Doesn’t ›
