Introduction
Managing mobile apps in enterprise environments requires more than just applying security settings. You need a clear strategy for protecting corporate data—especially when users access it from both managed and BYOD devices. In this post, I’ll walk through key Intune App Protection Policy use cases, explain how to apply different policy levels, and show how Conditional Access can help enforce secure app usage.
This Data Protection framework with App Protection policies provides a structured approach to identifying and managing organization data within apps, helping IT professionals enforce consistent security behaviors across platforms and user scenarios. By categorizing data as organizations, personal, or neutral, the framework enables precise policy enforcement, such as restricting data sharing, applying encryption, or triggering selective wipe based on the data’s origin and user sensitivity. It’s a foundational concept that supports secure BYOD strategies and ensures that organization information remains protected, even on unmanaged devices. Microsoft has very good starting point to look at, but most often there’s more.
Blog series overview
Guide to Intune App Protection Policies: Part 1 – Overview
Guide to Intune App Protection Policies: Part 2 – Intune MAM
Guide to Intune App Protection Policies: Part 3 – Data Protection Framework with App Protection policies
First steps
The first step is to clarify the scope of App Protection Policies (APP): which applications require APP, and how to enforce its use effectively. There are multiple different methods of assigning APP for application, my Part 2 – Intune MAM post tells about managed apps and that is actually very important piece of information.
When we know about managed application, it’s quite simple to build APP for those apps. Still we need to identify different use cases. Do organization support BYOD (bring-your-own-device) managed devices or would MAM-WE be enough? Organizations using both corporate-owned and BYOD models must assess the relevance of MAM-WE in their setup. Begin by identifying the applications available for each device category. Usually they are same apps! For MAM-WE i definitely recommend clarifying different use cases before building any policies.
Role of Conditional Access policies
Conditional access policies functions only as a enforcer. Conditional access policy for accessing M365 using Mobile device and Grant Control “require app protection policy” enforces users to use applications that are part of the App Protection policy. Be careful with this control! For instance, assigning the App Protection Policy to all Microsoft apps allows Conditional Access to enforce its requirement across supported applications. This effectively requires users to use certain apps; Reading mail requires Outlook, other applications are then out of scope and blocked by Conditional Access policy. Most common issue for Email clients is that most uses do other things on email clients, like syncs contacts and calendard. This policy will stop using those features! Outlook for mobile has similar features, but there are limitations!
- Outlook for Android supports both calendar and contacts sync
- Outlook for iOS/iPadOS supports only contacts sync
Similarly, browser usage is limited to Microsoft Edge to ensure compliance with App Protection Policies.
Consider other applications that are not part of M365. New CA policy for specific Cloud resource to require App Protection policy and additional App protection policy for mobile application. Just make sure Mobile application fully supports App Protection policies!
Planning Access for Microsoft 365 and Beyond
The big question here is where do you actually allow access: App Protection policies, on policy itself or Conditional Access policies or both?
Always communicate with end users before making changes like this. It’s something I fully recommend.
- If CA policy has “All cloud resources” and control “require app protection policy”, that would require App protection policy for all mobile applications and all mobile applications has to support APP.
- If CA policy has “Microsoft 365” or other similar resource, that would require App Protection policies for all apps that will access Microsoft 365 or the other similar resources.
- if APP has only “All Microsoft Apps” and CA policy has “All cloud resources” and control “require app protection policy”, this will grant access only when accessing any Microsoft 365 service with any Microsoft mobile application.
- if APP has “All applications” and CA policy has “Microsoft 365” and control “require app protection policy”, this will grant access only when accessing any Microsoft 365 service with any APP capable application
How do i build and enforce APP, please continue reading!
Data Protection framework using App Protection policies
When starting with Data Protection framework using App Protection policies, there are different “levels” of settings from Microsoft:
- Level 1 enterprise basic data protection – Microsoft recommends this configuration as the minimum data protection configuration for an enterprise device.
- Level 2 enterprise enhanced data protection – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration is applicable to most mobile users accessing work or school data. Some of the controls may impact user experience.
- Level 3 enterprise high data protection – Microsoft recommends this configuration for devices run by an organization with a larger or more sophisticated security team, or for specific users or groups who are at uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). Organizations facing threats from well-funded and sophisticated adversaries should implement this configuration.
Now these are just scenarios from Microsoft. I personally plan these by using “managed or unmanaged” device:
- Level 1 enterprise basic data protection managed or unmanaged device – For all users as starting point for a managed orunmanaged device!
- Level 2 enterprise enhanced data protection managed device – For a selected users with managed device!
- Level 2 enterprise enhanced data protection unmanaged device – For selected users as a starting point with unmanaged device!
- Level 3 enterprise high data protection managed device – For VIP users with managed device!
NOTE! These takes into account both managed and unmanaged devices! If organization does not support at all unmanaged devices, you can lose them, just make sure to use Conditional access policy to require device to be managed.
Let’s think about different users cases
These sample cases is build only for accessing Microsoft 365 services using either managed on unmanaged mobile devices.
Level 1 enterprise basic data protection managed device
Apply the policy to every Intune-licensed user with either a managed or unmanaged device. Most often, this policy does not change much, end users do not see any changes, but this policy has “under the hood” features like encrypting organization data!
- For All Intune licensed users as a “base” policy.
Level 2 enterprise enhanced data protection managed device
Assign this policy to selected users. This policy will enforce more restrictions than level 1 and there’s end user impact. Moving organization data and copying text restrictions, saving locations restrictions and so on.
- For selected users, this could be middle management or IT-personnel or everyone that handles sensitive and confidential information. It’s up to the organization decide selected users.
Level 2 enterprise enhanced data protection unmanaged device
A policy that is most often starting policy unmanaged device for all users. Define which services are permitted on unmanaged devices based on your organization’s policy. Conditional access policy requires app protection policy. Really simple way of allowing unmanaged devices to use only M365 services.
- Example: Frontline workers, information workers with own devices, temporary employees. The list continues to live and is up to the organization devices what to allow for unmanaged devices eventually.
Level 3 enterprise high data protection managed device
A very restrictive policy for VIP users. This policy has a significant impact on user experience and is assigned only to a small group of high-priority users. Lot’s of data copy and move restrictions, offline and OS version restrictions. Devices has to be running latest OS and offline usage is minimal. Organisations usually restrict this policy to core Microsoft 365 services, including email access via Outlook and communication through Microsoft Teams.
Example users for both unmanaged and managed devices: organization management, organization leadership, Member of the Board, Board of Directors and so on.
NOTE! For other cloud resources and apps than Microsoft 365, i do recommend to building separate Level 2 to Level 3 policies. How many policies is needed depends on mobile application APP capabilities and data security requirements that organization wants to achieve.
App Protection policies from Level 1 to Level 3
Next a sample policies that I mostly use when designing and building App protection policies. These samples are for a organization that supports both MDM+MAM and MAM-WE features. These settings primary focuses on organization data protection using Microsoft 365. Level 1 has always all applications, Level 2 and 3 only Microsoft applications on both managed and unmanaged devices. I do recommend to create additional policies for other applications, maybe even policy per app. That totally depends on the application APP capabilities. All Levels might have similar settings from lower levels, idea is to restrict more on higher levels. Some settings are totally new on the higher levels.
Feel free to download my sample policies for Android and iOS/iPadOS as .json file.
Android Level 1 enterprise basic data protection
Data transfer, Encryption and functionality
Data transfer:
- Block Backup org data as we do not want any org data to a users personal backup services.
- Require Approved keyboards, use default list as a starting point
Access requirements and Conditional launch
Access requirements:
- Most user want to use biometrics, so these setting defines how and what kind of biometrics.
- Require Class 3 biometrics.
- Timeout of 1440 means that time out is so long to get access to PIN, it's always biometrics.
- App PIN when device PIN is set is optional. Administrators can enforce device PIN with device configuration policies, no need to set it here.
Conditional launch:
- Offline grace period of 24hours should be enough to establish Internet connection.
- Block access blocks application access only, even on offline access.
- Wipe data wipes organization data from apps, same as "selective wipe" on Intune.
Apple iOS/iPadOS Level 1 enterprise basic data protection
Data transfer, Encryption and functionality
Data Transfer:
- Block Backup org data as we do not want any org data to a users personal backup services.
Access requirements and Conditional launch
Access requirements:
- Most user want to use biometrics, so these setting defines how and what kind of biometrics.
- Timeout of 1440 means that time out is so long to get access to PIN, it's always biometrics.
- App PIN when device PIN is set is optional. Administrators can enforce device PIN with device configuration policies, no need to set it here.
Conditional launch:
- Offline grace period of 24hours should be enough to establish Internet connection.
- Block access blocks application access only, even on offline access.
- Wipe data wipes organization data from apps, same as "selective wipe" on Intune.
Assignment of Level 1 App Protection policies
As the level 1 is “starting App Protection policy”, goal is to assign it to all users. Always assign App Protection Policies to user groups. Assigning them to device groups isn’t supported. App protection policy assignments are missing Intune built-in groups, All devices and All users. Hence, we need to have dynamic user group. For All users, i usually plan first pilot users and they are part of the group. To support this configuration, I’ve created a dynamic group called “intune-du-All Intune licensed”. Below a dynamic query for that. Query uses service plan ID to dynamically add users as members. Microsoft has really good document about different service plans and ID’s
user.assignedPlans -any (assignedPlan.servicePlanId -eq "c1ec4a95-1f05-45b3-a911-aa3fa01094f5" -and assignedPlan.capabilityStatus -eq "Enabled")
As Level 1 for both Android and Apple iOS/iPadOS is designed to be applied to all users devices, regardless of management state, filters are not used.
Level 2 enterprise enhanced data protection
Level 2 App Protection policies have Level 1 settings as a starting point, but as this is for selected users and only when using all Microsoft mobile apps, we beef up DLP features and access of applications. I do recommend to create different policies for managed and unmanaged devices to have better control and clarity when there’s change request for example unmanaged level 2 APP.
Android Level 2 enterprise enhanced data protection M365 – both managed and unmanaged
Data transfer, Encryption and functionality
Data Transfer:
- Saving copies to selected services includes: SharePoint, OneDrive only.
- In some cases, photo library has to be added as accepted saving location.
- Cut and copy character limit is 100, should be enough for addresses or URLs.
- Sometimes screen capture and Google assistant has to be allowed.
- Restricting web content to Microsoft Edge browser only requires Edge to be deployed as managed app. If it's missing, user is informed to install it.
Access requirements and Conditional launch
Access requirement:
- Minimum PIN length 8.
- Pin reset after 90 days.
- Previous PIN values 12, that's 3 years. Most often matched with device lifecycle.
Conditional launch:
- Offline grace period of 30 days, wipe data.
- Disabled account on Entra will block access to apps when device is online.
- Min OS version of 13.0 with Android is not this simple, but just making sure that currently supported Android version is minimum.
- Some of available settings has manufacturer dependencies, like Samsung Knox.
Apple iOS/iPadOS Level 2 enterprise enhanced data protection M365 – both managed and unmanaged
Data transfer, Encryption and functionality
Data Transfer:
- Policy managed apps with open-in/share filtering only shows policy managed apps.
- Saving copies to selected services includes: SharePoint, OneDrive only.
- In some cases, photo library has to be added as accepted saving location.
- Cut and copy character limit is 100, should be enough for addresses or URLs.
- Sometimes screen capture has to be allowed, but most often screen capture is blocked for added data security.
Functionality:
- Restricting web content to Microsoft Edge browser only requires Edge to be deployed as managed app. If it's missing, user is informed to install it.
Access requirements and Conditional launch
Access requirement:
- Minimum PIN length 8.
- Pin reset after 90 days.
Conditional launch:
- Offline grace period of 30 days, wipe data
- Disabled account on Entra will block access to apps when device is online.
- Min OS version requires more internal processes, as Apple devices gets lot's of updates. Currently Apple supports iOS 18.x and on iPadOS 17.x. To have policies for supported OS, separate policies for iOS and iPadOS is currently needed and correct device filters applied based on models.
- Min OS version could be user also just to warn users about too old OS for unmanaged devices.
Assignment of Level 2 App Protection policies – managed and unmanaged
For Level 2 App Protection policies for managed and unmanaged devices, organization decides user scope for these policies. We also need Assignment filter to include only managed or unmanaged devices.
On Assignment filters, there's option for Managed Apps. This is only used on App protection policies.
For managed devices, we need two different filters based on device platforms.
NOTE! Android might require additional filters for different management models:
- Android Enterprise.
- Android device admin (for China).
- Android AOSP.
- Corporate-owned dedicated devices with Azure AD shared mode (Or Entra shared mode?).
Now the assignment is pretty straight forward, an Entra security group to assign policies to selected group members and a device filter with managed devices on both Android and iOS/iPadOS.
No exclusions even on Level 1, as by design most restrictive App Protection settings is enforced.
Level 3 enterprise high data protection
Due to its strict configuration, Level 3 App Protection Policy should be applied exclusively to VIP users with Intune MDM-enrolled devices. This policy will definitely have user impact and is going to maximize data security on VIP users. Also these policies has limitations what is the manufacturer of Android device. This sample uses Samsung device as reference. Same as Level 2, I do recommend to create different policies for managed and unmanaged devices to have better control and clarity when there’s change request for example unmanaged level 3 APP.
Android Level 3 enterprise high data protection M365 – managed only
Data transfer, Encryption and functionality
Data Transfer:
- Transferring telecommunication data or messaging data is restricted to known Samsung apps. this can also be "any policy managed app", but then IT-admin has to deploy both applications and they have to support APP.
- Receiving data is also restricted to policy managed apps only with exception services.
Functionality:
- Blocking sync to native apps and printing
- Now all org notifications ore blocked.
Access requirements and Conditional launch
Access requirements:
- PIN reset for 30 days and remembering 24 previous PIN's is 2 years.
- Work or school account credentials for access is really restrictive, as user needs to type credentials when opening app. Might bee too restrictive, plan carefully.
Conditional launch:
- More wipe data settings, Offline (days), disabled account and jailbroken/rooted
- Using both min and max OS version. limiting too old devices and beta version is crucial.
Apple iOS/iPadOS Level 3 enterprise high data protection M365 – managed only
Data transfer, Encryption and functionality
Data Transfer:
- Transferring telecommunication data or messaging data is restricted to known Apple apps.
- Receiving data is also restricted to policy managed apps only with exception services.
- 3rd party keyboards are now blocked.
Functionality:
- Blocking sync to native apps and printing
- Now all org notifications ore blocked.
Access requirements and Conditional launch
Access requirements:
- PIN reset for 30 days and remembering 24 previous PIN's is 2 years.
- Work or school account credentials for access is really restrictive, as user needs to type credentials when opening app. Might bee too restrictive, plan carefully.
Conditional launch:
- More wipe data settings, Offline (days), disabled account and jailbroken/rooted
- Using both min and max OS version. limiting too old devices and beta version is crucial.
Assignment of Level 3 App Protection policies – managed
For Level 2 App Protection policies for managed devices, organization decides user scope for these policies. When deploying APP to devices already in use by VIP users, prior communication is essential to ensure a smooth transition.
For Both Android and iOS/iPadOS APP assignment is really simple, a Entra group with VIP users as member is enough
NOTE! No assignment filters but like mentioned before, VIP users devices has to be managed! When there are no device filter, this policy will deploy to unmanaged devices also!
Conclusion
App Protection Policies (APP) are a key part of securing corporate data on both managed and unmanaged devices. By aligning APP levels with Conditional Access and user roles, IT admins can build a flexible and effective data protection strategy. Start with Level 1 as a baseline for all users, and scale up to Levels 2 and 3 for users handling more sensitive data or using unmanaged devices.
It’s important to understand your organisation’s device landscape and user needs before rolling out policies. Also, don’t forget to communicate changes clearly to end users—especially when restrictions may impact their daily work. With the right planning, APP can help you protect organization data without compromising usability.