Devices or Users: When to target which policy type in Microsoft Endpoint Manager (Intune)
A new reader question came across my desk the other day. In truth, it is not the first time I have answered this question, but I realized that I could probably repeat myself less if I simply write an article and publish it. The question is:
When working in Microsoft Endpoint Manager (Intune), how do I determine whether to assign policies to devices or users?
Before we describe the best practices here I think it is important to review a little bit of information about security groups. Groups in Azure AD come in five flavors:
- Microsoft 365 Groups (Users only)
- Static Security groups comprised of Users
- Static Security groups comprised of Devices
- Dynamic Security groups comprised of Users
- Dynamic Security groups comprised of Devices
First, just know that you should use Security groups to assign policies and profiles within Intune (I would not use Microsoft 365 Groups). Eliminating that option right off the bat, let’s narrow it down further by determining when it would be best to recommend targeting Users vs. Devices.
Unfortunately, there is no one size fits all here; so we have to give the classic consultant answer: “It depends.” On what does it depend? A couple of factors:
- Are you trying to control an experience based on who the user is, or what device they are using?
- What type of policy or profile are we working with?
Let’s start with the second question first. The type of policy or profile you are working with may answer the question for you.
Compliance policies
When it comes to Compliance policies, I always target users. Is it possible to assign a compliance policy to a security group comprised of devices? Yes. But I do not recommend it. If you assign these policies to devices, you will find that there are two compliance results for every device (well, actually three if you include the built-in policy).
- The “system account” will receive a compliance status
- The user who signs into the device will also receive a compliance status
Unfortunately, this can lead to errors when it reports on the overall compliance of the device. I have even seen strange occurrences where both the user and the system account showed up as ‘Compliant,’ but the built-in compliance policy showed as ‘Not Compliant.’ This is even more confusing because literally the only thing that policy is measuring is whether there is a compliance policy being applied (and obviously there is). Because of these inconsistencies and issues, I do not recommend assigning Compliance policies to devices. Also notice that we are not given the option to assign to “All devices” but only “All users” (unlike Configuration profiles).
In general, I like to think of Compliance policies as the bare minimum that you would require for ANY endpoint to connect and start working with your systems. And so I do not have different compliance requirements for different types of devices. Whether they are corporate, personal, etc.–it doesn’t matter. Therefore I would normally just create one compliance policy for each device platform that I support, and then assign these to All users, or at least a security group that represents all of my licensed users (the members who are licensed to use Intune).
Device Configuration and Endpoint Security profiles
Next up: Device Configuration profiles (including Update rings) and Endpoint Security profiles. Here we return to our first question: Are you trying to control an experience based on who the user is, or which device they are using?
So the obvious use case for targeting devices is something like kiosk devices, or lab computers. No matter who sits down and logs into that machine, you want the experience to be identical. And it may be a different experience than what is expected when the user is picking up their own device (even to work with the same applications). In that case, you would want to create a device-based security group and apply the profiles accordingly.
Another use case for device targeting (using a Dynamic group) is where you have an organization that is managing a mix of corporate-owned and personal devices within the same device platform. For example, you might have corporate owned iPhones and some personal iPhones. In that case, there are likely different requirements for the one group versus the other. For example, your corporate profile might block manual unenrollment, whereas the personal profile would not.
Therefore, it makes sense to create two dynamic security groups: one that applies to deviceOwnership = Personal and the other to deviceOwnership = Company. When you assign your BYOD profiles, you would target the former group, and when you assign company profiles, you would target the latter.
One of the downsides to using dynamic security groups is that I have noticed it can sometimes take extra time (minutes to hours) for the membership to update. This normally isn’t too big of a deal and often will go unnoticed. But there are likely to be some helpdesk calls in your future that are resolved by nothing more than “waiting it out.”
Applications
Pretty much the same logic can be applied when you are assigning applications to devices. Should this user get the same applications regardless of which device they use? Or do they get a different set of apps depending on which device they are interfacing with?
The only thing to be mindful of is the difference between apps that you deploy as Required versus apps that you deploy as merely Available.
If it is a Required application, it means that the app is not just ‘available’ in the company app store, but it will be automatically and forcefully installed over the air (the user has no choice in the matter). You will notice that in the case of Required, you can assign the application to devices or users, but for Available applications you may only assign those to users.
Generally speaking, I would only assign to the device in the instance of a kiosk or lab situation. Otherwise I target the users.
App protection (MAM)
Remember that App protections policies (a.k.a. MAM) can be used either with or without enrollment of the actual device. This already implies that you should be targeting user objects rather than device objects. When a user signs into an application, these policies are applied at the application layer, and the device does not really play into the equation.
Conditional Access
Similar to Compliance and App protection policies, I always target users here, and not devices. The first thing to note is that when you use the device-based controls such as Compliant device and Hybrid Azure AD Joined device, this will already cover the distinction between managed and unmanaged endpoints. I am usually only interested in restricting access if I have less control over an endpoint (or its applications in the case of MAM).
The second point is that when Conditional Access is being asked to evaluate device compliance, I like to have this tied to the same group of users for whom compliance is actually being measured. The devices are not being targeted by my Compliance policies, and therefore I will not be targeting the devices with my Conditional Access policies. I will target the appropriate users in both cases (e.g. those who are licensed to use the features).
Autopilot profiles
When you assign Autopilot profiles, the advice is the opposite from Compliance and Conditional Access. Here, the profiles are only assigned to devices, not users. Notice again that we can select specific device groups, or just choose All devices (but there is no All users option).
And that makes sense. Autopilot is all about pre-provisioning devices. While there is a lot more to autopilot, for the purposes of this discussion, this is all we have to say about it.
Conclusion
So there you have it, clear as mud, right? This graphic is a summary:
And in case you are curious about my “standard approach,” I normally target users for the majority of my policies and profiles (except Autopilot of course). I find that this keeps it very simple for SMB’s. For example, it is almost always the case that Windows devices are company-owned, while mobile devices are personal/BYOD. Therefore I just have BYOD-friendly policies assigned to all of the users to support their mobile devices (and macOS where the need exists), and then I have a ‘corporate’ baseline for Windows computers that I likewise apply to all the users. I normally only allow web access on personal Windows devices (if at all).
Nevertheless in some cases it becomes important to distinguish between personal and corporate devices. In those cases I would recommend using the dynamic device groups to tailor the policies to the BYOD vs. company-owned groups, as appropriate.
Comments (32)
This was much appreciated and overdue, thank you!
Nice overview thanks. I got caught the first time i looked at App Protection Policies and had them assigned to my dynamic device group until i realized they only work with users. MS could do better here by restricting or having more tool tips when selecting groups i feel.
Thanks for sharing this. I am curious What you target (compliance but also device config) policies to when it involves shared win10 devices where multiple Users log in and in “theory” receive the same policies.
Whether you apply to devices or users won’t matter if they should receive the same policies anyway. Just note that we have seen issues with compliance assigned to devices instead of users.
For testing my BYOD Conditional Access and App Protection polices I applied them to a user group. I now want to apply to everyone in my organization. I created a dynamic security group that contains all users with an email address. I switched my Conditional Access and App Protection policies to use this group, but the policies don’t seem to be getting applied. Do Dynamic groups not work with these policies?
The only dynamic user groups I have used so far have been based on other attributes such as Department field, and I haven’t had any issues there. But, if targeting all your users, just assign to “All users” and exclude the stuff you don’t want such as guests and emergency access accounts. That’s what I do for my baselines (policies that are applied broadly to everyone).
Alex, every time I read one of your posts it happens to be a question where I am struggling to determine the best approach.
What about MDM Security Baselines? Would you target them at users or devices… if device groups then you end up with the system account and user account both appearing in much the same way as for compliance policies… but if applied to “All users” or a user group how do you avoid it applying to BYOD?
Couple of things: The MDM baselines are a bit messy in my opinion, because they don’t actually save me time or headache in management down the road, in fact they add to the headaches typically, because I almost always have to create custom policies anyway, I generally use these as a guide for creating those policies myself. Now, even so, it is still okay to have the system and user account both showing up, it is just that with Compliance policies I have found this to be more impactful to users when it can’t decide whether a device is compliant or not. Therefore I always have to target users for compliance. The same effect is not a concern with baselines (which are basically applied the same way as config profiles or endpoint security profiles).
Great post on a subject that is critical but rarely discussed. The MS documentation is completely lacking.
Question: How would you recommend controlling aspects of the user experience prior to logon (ie; guest access. wifi) in an environment where devices are shared. Is this a use-case for a policy tied to a device group?
Device config profiles can be assigned to device groups, yes. There is config template specifically for shared computers also.
Hey Alex,
Awesome write-up. The best I’ve found yet on this topic.
We’re struggling with compliance in Intune. Our employees have both BYOD and company devices, and we have different security requirements for each scenario. For example, we don’t want to enforce BitLocker on BYOD machines.
We want to take your advice to deploy compliance policies to user groups. We have seen more accurate results this way. But given that our users have both company and BYOD devices, it seems that our only option is to deploy separate compliance policies to a “BYOD” device group and to a “Company Device” device group.
Do you know of a good way to tackle this scenario?
Yes. Right now the solution is to ask your compliance policies to do less, and your config profiles to do more. E.g. do not enforce BitLocker via Compliance but rather config profile assigned to corporate devices.
Great article, Alex. I was wondering one thing, if our W10 devices are AAD hybrid joined and we apply InTune policies based on users and these users are signing in with on-prem AD accounts, the policy seems to still apply to other users who sign into the PC after them (e.g. device control policies). From what I can see, even policies targeted at users get added to the HKLM registry hive instead of just the current user. Am I right?
When you have shared computers there are additional considerations. There is a policy template that you can deploy specifically for shared computers for example. By default Intune expects 1-1 user to device assignment unless you explicitly tell it that the machine is shared or kiosk.
Thanks for the reply, Alex. I was wondering how other organizations might manage this scenario on dedicated-user W10 devices when an admin needs to connect to perform some tasks that might need to bypass an InTune device control or config setting that’s been applied to the primary user. Historically, we’d manage this with GPOs that would not apply to certain admin accounts.
Great read, thank you for your time.
We are trying to achieve… “If device isn’t within a trusted zone or isn’t setup with bitlocker then block access” basically we would like it so any “static devices” (PC’s) Will be blocked access if they leave the “trusted zone” but we have a handful of laptops which we are happy to access office 365 resources IF they are configured with bitlocker.
Now I wasn’t sure how to handle the compliance policy/configure conditional access. Multiple users have both PC’s within the office and laptops they’ll use remotely. Making me unsure what to target at device or user level. Can anyone suggest the best way around this?
Compliance policy for Windows 10 and later (and these are always targeted to Users): the compliance policy should require BitLocker and other settings you would like enforced, I would also suggest you include a grace period of at least 1 day (under Actions for noncompliance). Your CA policy would be for Windows device access, and the parameters would target the same users as your compliance policy, and for cloud apps I assume you would be selecting just Office 365 in this case. Then you can optionally use the conditions to include any location, excluding your trusted locations. You must include just the Windows devices from Device platforms. As well, you can choose whether you want this applied only to client apps or also to browsers. Then your access control would be configured to require device compliance. That would give you the result described.
Awesome article…
For Windows 365 Cloud PC’s I assume some security polices like Bitlocker and Windows Hello account protection are not needed . Would you just set the assignment to all devices but then exclude a dynamic group of CloudPC’s? Since you can’t use filtering in Endpoint Security you would have to target Devices.
Similarly for Compliance policies, you would want a separate one for CloudPC’s so would you create a kind of cross cross assignment…
Physical device compliance policy –> All users –> Filter out CloudPC’s (device.model -contains “CloudPC”)
CloudPC’s device compliance policy –> All users –> Filter out non-cloudPC’s (device.model -notContains “CloudPC”)
It seems like you can mix and match users / devices if using filtering so this would allow user assigned compliance policies to makes things less prone to errors but still apply different compliance policies to different user devices.
Thank you for the article Alex. I am quite new to InTune and am struggling with having a different setup for a different satellite location where the rules, apps and mandatory URLs will be different. I enrolled about 100 iOS devices under a Dynamic Device group and it seems that i might need to change it to an “Assigned User” so when user A enrolls all the devices it will know which profile to pull. Changing membership type from Dynamic Device to Assigned User, would it un-enroll the existing devices? In AirWatch that i previously used, I was able to create organizations and enrollment users assigned to those organizations, so it will know automatically which profile to load based on that user, but haven’t figured this out yet in InTune and appreciate any insight you might offer.
Thanks for the article, Alex.
For Attack Surface Reduction rules – Go with User or Device Groups?
Device seems like it makes more sense but it comes up with numerous errors regarding System accounts, so User is the way to go?
This article is a tad outdated as there are some additional options/considerations now with device filters and so on. But in general, I will always prefer to target users unless there is a specific requirement not to (i.e. controlling experiences because of what the device itself is as opposed to who the user is–as in kiosk devices or “lab” or “classroom” devices).
Hi, is there any danger of using user assigned groups to other devices? I have configured profiles, policies etc for Android enterprise fully managed devices, however when I use dynamic groups the pin is not enforced during enrollment and it only shows as an update in the intune app on the phone afterwards which means the user can just bypass setting up a pin. I can’t get around this and even microsoft states this is the case. When I use user assigned gourps eveything works perfectly during enrollment, however I am worried that these configurations and policies will follow the users onto other devices for example personal devices with the company portal on them. This has happened n the past on apple devices and a s a result a personal device was wiped. I have tested this for Android and there doesn’t appear to be any effect but I don’t want 1000 devices going out with this as a risk.
You should assign to user groups whenever possible. Nowadays you can use device filters to target or exclude devices by ownership. For example you can have a device filter to exclude personally owned devices so that you can say “This policy applies to all users except on personally owned devices.”
Interesting. One thing this doesn’t address is multi-user devices. There is still no apparent way to have/register a device as compliant, then have conditional access (MS docs specifically say Conditional Access isn’t possible as a feature for some unknown reason) to limit Compliant devices to be able to use MS Cloud apps. Then it seems a mystery how to just register a multi-user device, think conference room shared computer where all ADS users need to login and do work but the device needs to be compliant and multiple users that somehow doesn’t catch all users/devices in the trap. Found no way to workaround and have Conditional Access based on compliance for a shared computer without hosing up all users and blocking access. Any ideas on this appreciated. Objective is to limit not just users using MFA to O365 cloud app, but also, a CA policy that requires a device to be marked as compliant…AND it is a shared device. The rest works. But as soon as you try to setup a shared device, you are just blocked and not way to have Devices or Groups of devices as part of CA, it isn’t an option. Thx
Great article, this is exactly what I needed. but I’m a bit curious about why you don’t recommend office 365 group?
I just stepped into a cloud admin position and I’m doing some cleaning up on intune, updating some policies and configs.
They’re 100s of dynamic groups in there for all departments in over 40 locations and they are all Microsoft 365 groups.
and 1 device group per location which most of the policies are applied to.
Should I create new dynamic security user groups and reassign those policies since you don’t recommend 365 groups?
Microsoft 365 groups are not meant to be used for security policies, but rather to give access to specific types of Microsoft resources (groups). It is a special type of group that provisions a site, and other resources (e.g., optionally you can “Teamify” the group to create a team in MS Teams). To assign policies to users or devices you would normally create security groups for that purpose. The only time I ever assign to device groups rather than user groups is if I am trying to target something about those devices specifically like if they are kiosks or lab computers that should be treated differently from other devices. Otherwise, security policies, apps, etc. I will always make “user-centric,” and the groups then usually contain users not devices.
What is the recommendation for ASR rules for today? I feel like everything points to device assignment rather than user for this one.
i disagree with never targeting devices with compliancy policies. what if your compliancy policy is make sure bitlocker is enabled and secure boot is enabled too. if you target a user that a laptop and a desktop and perhaps one is older and cant do secure boot. now the user is not compliant correct?
Couple of notes on this: in the early days, it was not even possible to assign Compliance policies to devices, you HAD to target users only. Then eventually they made it so you can target devices, but I ran into all kinds of problems with it. So that is why, at the time (this article was written back in 2021), I advised against it. These days, it may be working better for folks, and it is of course supported, if you have the need. Last comment: hopefully nobody still has devices that old, which cannot use BitLocker or Secure Boot :)
Microsoft Cloud PCs and many Virtual machines are a good example of devices that do not support Bitlocker. The only method I can think of is to create a filter for those devices, target devices and filter exclude those. If you were to target users, then they would be included.
Hi Alex,
What do you recommend if deploying a wifi policy to user or device groups?