An app protection policy is the only control you have on a device you do not own, and its whole job is to draw a line inside the app between work data and everything else. The concept is settled in [9.1] BYOD, MAM, and Drawing the Line. This is the build: the three groups of settings, the protection level I start from, and the one assignment trick that decides whether the policy actually applies to the devices you meant.
Three groups, and what each one defends
Every app protection policy is built from three groups of settings, and the fastest way to reason about them is to name what each one protects. Data protection governs where work data can go once it is inside a managed app: which apps it can be shared with, whether it can be saved locally, whether it can be cut and pasted into a personal chat, whether it is encrypted at rest. Access requirements govern who gets to open the work data in the first place: the app PIN, its length and complexity, whether a fingerprint or face substitutes for it, and how long access survives before it is rechecked. Conditional launch governs the state the device and the app must be in before the door opens at all, and what happens when they fail: warn, block, or wipe the work data. Data protection is the boundary, access requirements are the lock, and conditional launch is the tripwire.
Start from a level, then deviate on purpose
Microsoft publishes a three-tier data protection framework, and I build from it rather than hand-picking forty settings from a blank policy. The tiers are cumulative, so level 2 is level 1 plus a set of tightenings, and level 3 is level 2 plus more. All three target the core Microsoft apps as one app group. Starting from a named level gives you a defensible baseline and a short list of intentional deviations, which is a far better artifact than a policy nobody can explain a year later.
| Level | Posture | Who it is for |
|---|---|---|
| Level 1 (enterprise basic) | Encryption required, PIN required (numeric, minimum length 4), jailbroken or rooted devices blocked, selective wipe on 90 days offline. Data still flows to all apps. | The floor. Everyone, as the minimum you would defend in an audit. |
| Level 2 (enterprise enhanced) | Adds the real DLP: send org data to policy-managed apps only, block backup, block save-as except to OneDrive and SharePoint, paste-in only, minimum OS enforced at N-1, offline wipe tightened to 30 days. | My default for any user touching sensitive data, which is most of them. |
| Level 3 (enterprise high) | Adds friction for high-risk roles: minimum PIN length 6, simple PIN blocked, printing blocked, third-party keyboards blocked, jailbroken or rooted devices wiped rather than blocked. | Executives, finance, anyone a motivated adversary would target by name. |
Most organizations should live at level 2 for the general population and reserve level 3 for the roles that warrant the friction. Level 1 is the line below which I would not sign off, not a destination.
Conditional launch is the part that enforces itself
Conditional launch is where the policy stops being a set of preferences and becomes an actual control, because each condition is paired with an action that fires without an administrator in the loop. This is the section worth getting deliberate about, because the difference between warn, block, and wipe is the difference between a nag, a locked door, and a decision you cannot take back.
| Condition | What I set it to |
|---|---|
| Jailbroken or rooted device | Block at level 2, Wipe at level 3. Integrity failure is not a warning. |
| Max PIN attempts | 5, then wipe the work data. The device belongs to the user; the data does not. |
| Offline grace period | Block access after the block window, wipe after 30 days offline at level 2. A device that has not checked in for a month is a device you no longer control. |
| Minimum OS version | Enforced at N-1 and set to Warn first, then Block once the population has had a patch cycle to catch up. |
| Minimum app version | Warn, so you can push a floor without locking people out mid-day. Set per-app floors deliberately; there is no single global minimum. |
| Disabled account | Wipe. A deprovisioned identity should not leave readable work data behind on a personal phone. |
On Android the device-integrity signal now comes from the Play Integrity verdict, which replaced the older SafetyNet attestation. Configure the current setting and treat any lingering SafetyNet option as legacy. This is also where the platforms genuinely differ: Android carries the screen-capture and Google Play Protect controls that iOS has no equivalent for, so a policy that looks identical across both platforms is quietly doing less on one of them.
The assignment is the whole trick
App protection applies regardless of enrollment, which is the entire point: the same policy engine covers an unmanaged personal phone and a fully enrolled corporate one. That strength is also the trap, because if you assign one policy to everyone you either over-restrict your managed fleet or under-protect the unmanaged one. The pattern that works is to assign to a broad user group and split behavior with an app protection policy filter keyed to the device management state: a strict policy for unmanaged devices, a more permissive one for Intune-managed devices where the platform is already carrying the load.
Two platform facts decide whether that filter actually fires. On iOS the managed-device filter only recognizes a device as managed when the app receives the IntuneMAMUPN and IntuneMAMOID values through app configuration; since the 2409 service release those are delivered automatically to the core Microsoft apps on enrolled iOS, but a custom or line-of-business app still needs them configured by hand. On Android the Company Portal must be present for app protection to apply at all, and Microsoft now requires the device to be registered with Microsoft Entra ID to keep receiving MAM policy for the Microsoft 365 apps. Neither of these is optional plumbing. If the filter silently treats a managed device as unmanaged, your users get the strict experience you meant for personal phones, and the tickets will find you.
Before you assign
- Pick a starting level (2 for the population, 3 for high-risk roles) and record every deviation from it.
- Build one policy for unmanaged and one for managed, and assign both to the same user group with opposing management-state filters.
- Confirm the iOS apps receive IntuneMAMUPN and IntuneMAMOID, by hand for any custom or line-of-business app.
- Confirm Company Portal is deployed on Android and that Entra device registration is in place for the Microsoft 365 apps.
- Set conditional launch actions before you widen the assignment: wipe on disabled account, wipe on max PIN attempts, block on integrity failure.
- Pair the policy with Conditional Access so an unprotected app cannot reach the data in the first place.
Do that and app protection stops being a checkbox and becomes the thing it is supposed to be: a work boundary that holds on a device you were never going to manage. The design thinking behind the policy lives in [9.5] App Protection Policies, and the operational half, version floors and selective wipe once it is running, is in [9.5.1] Operating MAM.
Intune Deployment Guide · Phase 9: Mobile and BYOD
‹ Previous: [9.1] BYOD, MAM, and Drawing the Line
Next: [9.2] Fully Managed Mobile: Android vs iOS ›
