| title | Data Protection Framework Using App Protection Policies | |
|---|---|---|
| description | Learn how app protection policies ensure an organization's data remains safe or contained in a managed app, regardless of whether the device is enrolled. | |
| ms.date | 06/12/2025 | |
| ms.topic | concept-article | |
| ms.reviewer | beflamm | |
| ms.custom | ||
| ms.collection |
|
As more organizations implement mobile device strategies for accessing work or school data, protecting against data leakage becomes paramount. Intune's mobile application management solution for protecting against data leakage is app protection policies. These policies are rules that ensure an organization's data remains safe or contained in a managed app, regardless of whether the device is enrolled. For more information, see App protection policies overview.
When you configure app protection policies, the number of various settings and options enable organizations to tailor the protection to their specific needs. Due to this flexibility, it may not be obvious which permutation of policy settings are required to implement a complete scenario. To help organizations prioritize client endpoint hardening endeavors, Microsoft has introduced a new taxonomy for security configurations in Windows, and Intune is leveraging a similar taxonomy for its app protection policies data protection framework for mobile app management.
The app protection policies data protection configuration framework is organized into three distinct configuration scenarios:
-
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). An organization likely to be targeted by well-funded and sophisticated adversaries should aspire to this configuration.
As with any deployment of new software, features, or settings, Microsoft recommends investing in a ring methodology for testing validation prior to deploying the app protection policies data protection framework. Defining deployment rings is generally a one-time event (or at least infrequent), but IT should revisit these groups to ensure that the sequencing is still correct.
Microsoft recommends the following deployment ring approach for the app protection policies data protection framework:
| Deployment ring | Tenant | Assessment teams | Output | Timeline |
|---|---|---|---|---|
| Quality Assurance | Preproduction tenant | Mobile capability owners, Security, Risk Assessment, Privacy, UX | Functional scenario validation, draft documentation | 0-30 days |
| Preview | Production tenant | Mobile capability owners, UX | End-user scenario validation, user facing documentation | 7-14 days, post Quality Assurance |
| Production | Production tenant | Mobile capability owners, IT help desk | N/A | 7 days to several weeks, post Preview |
As the above table indicates, all changes to the app protection policies should be first performed in a preproduction environment to understand the policy setting implications. Once testing is complete, the changes can be moved into production and applied to a subset of production users, generally, the IT department and other applicable groups. And finally, the rollout can be completed to the rest of the mobile user community. Roll out to production may take a longer amount of time depending on the scale of impact regarding the change. If there's no user impact, the change should roll out quickly, whereas, if the change results in user impact, rollout may need to go slower due to the need to communicate changes to the user population.
When testing changes to an app protection policy, be aware of the delivery timing. The status of app protection policy delivery for a given user can be monitored. For more information, see How to monitor app protection policies.
Individual app protection policy settings for each app can be validated on devices using Microsoft Edge and the URL about:Intunehelp. For more information, see Review client app protection logs and Use Microsoft Edge for iOS and Android to access managed app logs.
The following App Protection Policy settings should be enabled for the applicable apps and assigned to all mobile users. For more information on each policy setting, see iOS app protection policy settings and Android app protection policy settings.
Microsoft recommends reviewing and categorizing usage scenarios, and then configuring users using the prescriptive guidance for that level. As with any framework, settings within a corresponding level may need to be adjusted based on the needs of the organization as data protection must evaluate the threat environment, risk appetite, and impact to usability.
Administrators can incorporate the below configuration levels within their ring deployment methodology for testing and production use by importing the sample Intune App Protection Policy Configuration Framework JSON templates with Intune's PowerShell scripts.
Note
When using MAM for Windows, see App protection policy settings for Windows.
To ensure that only apps supporting app protection policies access work or school account data, Microsoft Entra Conditional Access policies are required. These policies are described in Conditional Access: Require approved client apps or app protection policy.
See Require approved client apps or app protection policy with mobile devices in Conditional Access: Require approved client apps or app protection policy for steps to implement the specific policies. Finally, implement the steps in Block legacy authentication to block legacy authentication capable iOS and Android apps.
Note
These policies leverage the grant controls Require approved client app and Require app protection policy.
For each app protection policy, the Core Microsoft Apps group is targeted, which includes the following apps:
- Microsoft Edge
- Excel
- Office
- OneDrive
- OneNote
- Outlook
- PowerPoint
- SharePoint
- Teams
- To Do
- Word
The policies should include other Microsoft apps based on business need, additional third-party public apps that have integrated the Intune SDK used within the organization, as well as line-of-business apps that have integrated the Intune SDK (or have been wrapped).
[!INCLUDE app-protection-framework-level1]
[!INCLUDE app-protection-framework-level2]
[!INCLUDE app-protection-framework-level3]
Administrators can incorporate the above configuration levels within their ring deployment methodology for testing and production use by importing the sample Intune App Protection Policy Configuration Framework JSON templates with Intune's PowerShell scripts.