Intune Assignments User Groups vs Device Groups: When you set up an Intune deployment, you need to choose a group to assign it to, either a user group or a device group. There isn’t one right or wrong option because both can work. What matters is knowing how each choice affects who gets the deployment and when it applies. Some deployment can only be applied to device group only while some deployments are more suited to target users rather than devices.
By the end of this post, you’ll understand when to use a user group and when to use a device group for any Intune deployment. I’ve also included a simple decision matrix to make this decision easier and quicker.
If you assign an Intune deployment to a device group, the settings/apps/policies etc. are applied at the device level and affect all users who sign in to that device. (Example: OS settings, Security settings, Autopilot, Shared/kiosk devices). Device based deployment writes to HKEY_LOCAL_MACHINE (HKLM) registry node.
If you assign an Intune deployment to a user group, the settings/apps/policies etc. are applied at the user level, and the experience follows the user across all their managed devices. (Example: Creating a desktop icon, deployment of LOB app for specific users etc.). User based deployment writes to HKEY_CURRENT_USER (HKCU) registry node.
Contents
Choosing the Right Group Type for Intune Deployments
- Microsoft 365 groups: Don’t use these types of groups for Intune assignments as they are more designed towards collaboration.
- Entra Security Groups (Static and Dynamic): Use Microsoft Entra security groups for Intune assignments; they’re designed for access control and support both users and devices. Use static groups for small pilot deployments or exclusions where you want manual control. Use dynamic groups when you need to apply a policy, app, or setting across larger user base, for grouping Autopilot devices, creating device category groups or for scope tags auto assignment to name a few scenarios.
Microsoft’s current recommendation is to use the All users and All devices virtual groups for policies and apps, instead of creating your own version of all users/all devices using Microsoft Entra dynamic groups and use filters to narrow down the targeting. For more details: filters-device-properties. For each tenant, there can be up to 200 filters. If you prefer to still use dynamic groups for your deployments, you can do so as dynamics groups are also fully supported. Microsoft Performance recommendation for grouping, targeting and filtering.
User Groups vs Device Groups
Below is a general matrix on what happens when you use a User group or a device group for Intune deployments.
| Criteria | User groups | Device groups |
|---|---|---|
| When it evaluates | After user signs in on a device | During device check-in, no user needed |
| Experience | Follows the person across devices | Consistent setup per device |
| Best for | Productivity apps, self-service catalog, per-user settings | Security policies, OS settings, Autopilot, shared or kiosk |
| Company Portal | Available apps are user-centric | Device targeting is not ideal for “Available” apps |
| Autopilot and ESP | Not evaluated before first sign-in | Evaluated during ESP. Critical for pre-provisioning |
| Shared devices and labs | Can spread to every device a user signs into | Strong fit since it applies to any user on the device |
| Licensing alignment | Per-user licenses | Per-device scenarios |
| Risk profile | App can install across many devices | Less personalization for multi-user devices |
When to use a Device Group?
When you want an Intune deployment to apply at the device level, the policy is enforced on the device itself, so it applies to every user who signs in on that device. For example, if you want to disable spell checking in Microsoft Edge for all users on a particular device, create a policy and assign it to a Microsoft Entra security group that contains the device. The policy sticks to the device and if a user moves to another machine, the policy will not be applied.
Assigning a policy to a device group is ideal for Shared, Kiosk, or lab devices when you need consistent settings regardless of who signs in.
Settings Catalog items that are device-scoped (and most Endpoint Security policies) apply via the device channel and write under machine hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current.
Use Cases
- Security Policies: Use device groups for Endpoint Security profiles, BitLocker, Firewall, Defender AV, ASR, Local user group membership, LAPS, Attack surface policies.
- OS configuration: Settings Catalog items that are device scope, hardening baselines, certificate profiles that are per device.
- Autopilot and ESP: Apps and policies that must install during device ESP or pre-provisioning, before any user signs in.
- Shared, kiosk, lab, VDI/AVD: Use device groups for Shared, Kiosk, VDI or Azure virtual desktop session host devices.
- Per-machine apps: Win32 apps installed in system context, drivers, OEM utilities, agents that must be present for every user.
- Updates: Windows Update for Business (WUfB) rings, feature updates, quality update policies.
- Mobile and macOS device scope: Android dedicated devices, iOS supervised device features, macOS system or kernel extension payloads.
Different Scenario for Using Device Groups
Below are some of the scenario’s for using a Device based Entra security group for Intune deployments.
| Scenario | Why device group |
|---|---|
| BitLocker, Firewall, Defender, ASR | Security must be applied at the device level, irrespective of who is signing on to the device. |
| Autopilot required apps | Must install during ESP before first sign in |
| Shared room PCs or kiosks | Any user should get the same apps and settings |
| AVD multi-session | Azure Virtual Desktop multi-session is a special scenario. With virtual machines, device CSPs must target device groups. User CSPs must target user groups. |
| Windows Update for Business | OS servicing is per device |
Few Examples of Device group Usage
- In a meeting room scenario, you want a locked down version of Edge for a device, regardless of who signs in. Create a policy and assign it to an Entra group with devices.
- Corporate Wi-Fi with device certificates: Create SCEP or PKCS device certificate and trusted root certificate profile, then a Wi-Fi profile that uses device auth. Add the PCs to a devices group and assign all three profiles to that group, so any user on those devices connects securely.
- When you want to standardize local admin password rotation with Windows LAPS. Create the LAPS policy, add eligible endpoints to a devices group, and assign the policy to that group, so password management applies uniformly to all users on those devices.
- When creating a profile to make changes in BIOS settings, use a device group.
When not to use a Device group
- Per user licensing apps and preferences: For apps with user-based licensing and a limited number of seats, deploy at the user level (not the device level) so only users in the target group receive the app and consume a license.
- BYOD/Personal devices: As you do not mange BYOD devices, its best to use a user group for intune app or policy deployments for personal devices.
- MAM/App Protection & Managed App Config: these are strictly user targeted (do not use device groups).
- Enrollment restrictions & access controls: user-driven controls (platform/device limits, Conditional Access) belong to user groups, not device groups.
When to use a User Group?
When you target an Intune deployment to a user group, it applies at the user level and follows the person across devices. For example, if you want to disable spell checking in Microsoft Edge for specific users wherever they sign in, create a user-scoped policy and assign it to a Microsoft Entra security group containing users. The setting travels with the user and does not affect other users on the same device.
Another example could be that when you want to configure any setting in OneDrive or Office app, this type of policy is generally applied to a user group. Example policy: OneDrive Auto sign-in, OneDrive KFM policy etc.
Settings Catalog items that are user-scoped apply via the user channel and write under user hive: HKEY_CURRENT_USER\SOFTWARE\Microsoft\PolicyManager\current.
When not to use a User group
- When you want to apply the setting at the device level. That means, it will be applicable to all users using the device.
- Before sign-in policies: Any policies that must be applied before the user signs in.
- Endpoint Security: BitLocker, Defender AV, Firewall, ASR, LAPS etc.
- Device-scoped Settings Catalog or ADMX (HKLM) items. It can be applied to the user group but recommendation is to assign it to device group.
- Windows Update for Business (rings, feature, expedite)
- Per-machine apps/agents: EDR, VPN (device tunnel), drivers, OEM utilities
- Device certificates and Wi-Fi/VPN profiles using device auth.
- DFCI/UEFI/BIOS or other firmware controls.
- Shared/kiosk/AVD multi-session devices where every user needs the same setup.
- Scripts/remediations that run as SYSTEM or write to HKLM.
- An app targeted to user would span all across their managed devices. if the intention is to install the app only on a particular device, then do not use a user group.
- When compliance must be enforced per device, independent of the user.
Best Practices
- Avoid Mixing of User & Device groups.
- Always test on Pilot users first before increasing the scope of the policy to other devices.
Decision Matrix for Selecting a Device Group vs User Group
Below is a decision matrix which can help you decide when to use a device group and a user group for Intune deployments.
| Scenario/Feature | Preferred target | Alternate target | Intent (if any) | Notes |
|---|---|---|---|---|
| Conditional Access (Entra ID) | User group | — | — | CA targets users. Include or exclude specific devices using filters |
| Windows Update for Business (rings, feature, expedite) | Device group | — | Required | OS servicing is per device; use filters by build/model/ring. |
| Compliance policies | Device group for corporate devices | User group for BYOD/contractors | — | Compliance state is per device; pair with Conditional Access to enforce. |
| Endpoint Security (BitLocker, Defender AV/Firewall, ASR, LAPS) | Device group | — | Required | Device-scoped security; ESP-friendly. |
| Device configuration – device scope (Settings catalog / ADMX / OMA-URI) | Device group | User group (applies after sign-in but still writes HKLM) | Required | Mirrors GPO device scope; predictable during ESP. |
| Device configuration – user scope (Settings catalog / ADMX) | User group | — | — | User preferences follow the person; writes HKCU. |
| Certificates + Wi-Fi/VPN | Device group for device auth & device tunnel | User group for user auth & user tunnel | Required | Match certificate scope to the Wi-Fi/VPN profile scope. |
| Applications – Win32, Required, system context (agents, drivers, shared/kiosk) | Device group | — | Required | Reliable during ESP. Keep intents consistent. |
| Applications – Company Portal Available | User group | Win32 can be device or user | Available | Portal is user-centric; Win32 is the exception. |
| Shared / Kiosk / VDI labs | Device group | — | Required | Consistent setup for any user who signs in. |
| Remove / Uninstall deprecated app | Match the original target | — | Uninstall | Use the same scope that installed it to avoid reinstall loops. |
| PowerShell / Shell scripts | Device group when run as SYSTEM | User group when run as User | — | Run context decides HKLM vs HKCU impact. |
| Proactive remediations | Device group when run as SYSTEM | User group when run as User | — | Scope broadly (All devices/users) + Filters. Use a small exclusion group if required. |
| DFCI / UEFI / BIOS (e.g., Surface) | Device group | — | Required | Firmware control is device-centric. |
| Windows LAPS | Device group | — | Required | Local admin password rotation is per device. |
| Defender for Endpoint onboarding / EDR sensor | Device group | — | Required | Treat onboarding and sensor settings as device posture. |
| Policy sets | Pick one model per set (device-centric or user-centric) | The other model | — | Avoid mixing user & device targeting in the same set. |
| App Protection (MAM) & Managed App Config | User group | — | — | MAM is user-targeted; often combined with Conditional Access. |
| Enrollment restrictions | User group | — | — | Platform/device limit restrictions are user-scoped. |
| Windows driver/firmware updates (WUfB driver mgmt) | Device group | — | Required | Update servicing is per device; align with WUfB rings. |
| macOS / iOS / iPadOS software updates | Device group | — | Required | Platform updates are device-centric. |
| Endpoint Privilege Management (EPM) | Device group | — | Required | Elevation policies apply per device; consistent for all users. |
| App configuration for managed devices (not MAM) | User group for roaming app prefs | Device group for shared/kiosk devices | — | User targeting for personal settings; device for shared devices. |
| Android Enterprise modes | Device group for Dedicated/COBO (company owned, business only) | User group for COPE (company owned, personally enabled) user apps | — | Security/policy to devices; user apps to users. |
| Windows 365 Cloud PCs (provisioning) | — | User group | — | Windows 365 provisioning uses user groups; post-provision Intune assignments follow normal rules. |
| M365 Apps / OneDrive / Teams | User group | – | Required | Per-user licensing and roaming UX. |
| Windows Autopilot Device Preparation (Autopilot v2) | Device group (selected in the DP profile for Enrollment Time Grouping) | User group (required in user-driven flow to identify eligible users) | Required (apps/scripts selected in the DP policy) | No device registration required; Microsoft Entra join only. Devices are added to the specified device group at enrollment and receive only the apps/scripts selected for OOBE; other device-group items come after. Autopilot profiles take precedence, so remove any Autopilot registration before using DP. |
| Windows Autopilot (classic v1) | Device group | — | Required | Supports user-driven, pre-provisioned, and self-deploying modes. device registration required; broader customization and ESP phases (device and user). If both v1 and DP exist, v1 profile wins. |
Settings Catalog Policy (Device Scope vs User Scope)
When a device check-in with Intune, it always presents a deviceID. A userID is sent only if a user is signed in at that time (or once they sign in and the next sync runs). Below screenshot shows an example of a settings catalog policy available for device scope and user scope both. Device scope policy will have (Device) at the end and user scope policy will have (User) at the end of its name.
- Device-scoped policy | Assigned to a device: When a device scoped policy is assigned to the device, all users get the policy setting.
- Device-scoped policy | Assigned to a user: After that user signs in and the device syncs, the device-level setting is applied to the machine and therefore affects all users on it.
- User-scoped policy | Assigned to a device: The user setting is enforced for anyone who signs in to that device (similar to a “loopback merge” effect).
- User-scoped policy | Assigned to a user: Only that specific user receives the setting, on any managed device they use.
- Settings that exist in both scopes (user and device): If both are assigned, the user-scope version takes precedence.
- Early check-ins without a signed-in user: Until a user profile exists, user-scoped settings can show as Not applicable; they evaluate once a user signs in and a sync occurs.
