App Protection Policies - Filter Edition
Examining the support of Filters in App Protection Policies, and what you need to do to create or migrate!
So hot off the press here it's not even on the What's New in Intune yet!
Background
App Protection Policies
App Protection Policies (APP's - not at all confusing, there guys...) are a way of applying access rules and restrictions on applications to help secure corporate data. Apps that can benefit from APP's need to support the Intune SDK, but all of the important Microsoft apps for iOS and Android have supported these for some time.
While you can (and probably should, depending on your implementation) apply App Protection to corporately-owned, managed mobile devices, the single biggest benefit of APP's are to secure corporate data access on non-managed, BYOD devices via MAM-WE. They "containerise" the corporate data at the app level, don't impact personal-context app usage (e.g. having both a corporate and personal email account in the Outlook app), and enforce security requirements the device has to meet to allow access to the corporate data:
I personally haven't come across a single reason to be enrolling personal mobile devices into Intune, and times I have seen them for "reasons", they have either been poorly implemented, provided a rubbish user experience, or both. I've seen far more instances of users pushing back on enrolling their personal phones being managed by their companies, and in a worse-case (misconfiguration or mis-management) scenario could even see their personal data deleted!
There's some amazing documentation on implementing App Protection Policies from scratch, complete with a 3-level guidance framework depending on your requirements.
Like any framework, they can be used as reference, and are not set in stone. Apply what's appropriate for your environment!
Filters
The second part here are Filters. If you've not read up on Filters, go do that first and come back. It's fine. I'll wait.
Excellent, now we're all up to speed, let's have a look at creating a new policy using filters.
Policy Creation and Changes
App Protection Policies used to be configured in a relatively simplistic way, asking if you wanted to target apps on all device types, or be more specific, allowing different policies for Managed vs. Unmanaged devices.
If you go to create a new APP now, you straight-up won't see that option any more, being presented purely with the apps drop-down.
The magic really happens now come the Assignments page, which... Well, it looks exactly the same as every other Settings Catalog-backed policy assignments page!
The reason for this is due to the new options available via the Filters page (accessible via the Devices, Apps or Tenant Administration blade). You'll first be met with two options, which if I'm being honest, confused me when I first saw them. Managed devices, and Managed apps.
"Managed Devices" is basically the same Filter experience as previous, whereas "Managed Apps" is where we'd be looking to create a special new filter for our App Protection Policies. We have options just for Android and iOS/iPadOS, and have a number of properties to build out our rules from, most importantly, deviceManagementType, which totally blows the filter possibilities wide open, allowing granular control of APP filtering on multiple different enrolment methods!
Look at all those different enrolment methods we can choose to apply policy to!?
Having created a new Unmanaged Android Devices APP filter, we can head back to the App Protection Policy Assignment screen, choose an appropriate user group, and configure the filter to Include the new filter as shown below.
The end result is a BYOD-focused App Protection Policy whereby any corporately managed devices would be subject to no (or a differently filtered) APP, and any unmanaged (MAM-WE) devices get hit by our unmanaged policy.
Note that an appropriate Conditional Access policy that requires an app protection policy is still needed to enforce the use of app protection. Additionally as per MC540749, the below is all that's required and the "Require approved client app" grant control is being retired as of March 2026.
Migration of Existing Policies
So what happens if you don't want to completely recreate your App Protection Policies and just want to change to the new way of scoping? Microsoft has you covered, and the informational tooltips are pretty verbose about what you need to do:
Simply set your existing app target to Yes, save the policy, and head to the assignments page to apply your group and filter as above.
It's worth noting (as shown in the assignments page) that if you don't change the apps target above, the filter will apply as well as that target, potentially causing some weird behaviour depending on how you've got things configured.
IMPORTANT NOTE!
This is a one-time deal, and once you've saved the policy, you're unable to go back and re-configure the device type option that may have previously been set:
Assuming you had some sort of JSON backup of your policies, you could potentially re-import that to get the configuration back, but why do that when you could move them to the new way of filtering?
Speaking of backing up your configuration, wouldn't it be great to have native import/export functionality within Intune?
OH WAIT!
The beginnings of an import/export capability for Settings Catalog settings was demoed at @mmsmoa and is something being worked on. No timelines or commitments to share (@MikeDanoski may have more to share), but we are aware of and tracking this request.
— Jason Sandys (@JasonSandys) May 22, 2023
