Intune app protection policies

Intune app protection policies (APP) — sometimes called Mobile Application Management without enrolment (MAM-WE) — protect corporate data inside specific apps on personal mobile devices without managing the device itself. They're the right answer for the bring-your-own-device problem: keep work data safe, leave personal data alone.

The model

When a user opens Outlook, Teams, or another Intune-aware app on their personal phone and signs in with their work account, Intune evaluates the app protection policy for that user and that app. The policy then enforces controls inside the app:

• Encrypt all data stored by the app.
• Require a PIN or biometric on app launch.
• Block copy/paste out to non-protected apps.
• Block screenshots in some scenarios.
• Force "open in" to managed apps — files open only in Word or Excel, not in third-party apps.
• Block saving to local device storage or non-corporate cloud storage.
• Remote wipe of corporate data inside the app on demand, leaving personal data untouched.
• Require app version minimums (block sign-in on outdated apps).
• Conditional launch — block sign-in if the device has root/jailbreak, doesn't meet OS minimums, or is offline too long.

Apps that support it

Microsoft's first-party mobile apps all support APP: Outlook, Teams, Word, Excel, PowerPoint, OneDrive, OneNote, Edge for iOS/Android, Power BI, Authenticator, To Do, Planner, Yammer. A long list of third-party apps also support it via the Intune App SDK (or Wrapping Tool) — Adobe Acrobat, Box, Cisco Webex, ServiceNow, many others.

If an app supports APP, Intune can enforce policy inside it; if it doesn't, the work account simply can't sign in (when conditional launch is configured to require APP).

Conditional Access integration

In Entra ID Conditional Access, you can require that mobile access to Microsoft 365 happens only through approved client apps with APP. The combination is the gold standard for personal-device access:

• Conditional Access: require approved client app + app protection policy.
• Result: a user on their personal iPhone can only access Microsoft 365 through Outlook, Teams, etc., with PIN/biometrics/encryption/etc. enforced. Native iOS Mail simply won't authenticate.

MAM vs MDM

The choice isn't binary; it's per-device-population:

• Corporate-owned devices → MDM (full Intune enrolment) gives you broad device control.
• Personal devices → MAM (APP only, no enrolment) keeps user trust while protecting data.

Many organisations run both: MDM for company iPhones, APP for personal Android. Conditional Access decides which path each user takes.

Licensing

App protection policies require an Intune licence — included in Microsoft 365 E3, E5, F3, F1, Business Premium, and the Intune standalone SKU.

For organisations that don't fully manage every device but still want corporate data protected on phones, APP is one of the highest-value controls in Microsoft 365.

A worked example: BYOD baseline for a 300-user tenant

A firm allows BYOD for iOS and Android on Outlook, Teams, OneDrive, and Word/Excel/PowerPoint, no MDM enrolment. The app protection policy that lands cleanly:

• Data protection. Restrict cut/copy/paste to policy-managed apps. Restrict Save-as to OneDrive for Business and SharePoint only. Block screen capture on Android; iOS honours the block only in Managed Home Screen contexts, so don't over-promise that one.
• Access requirements. App PIN on launch (6-digit numeric minimum), biometric alternate, PIN reset after 5 failed attempts. Wipe app data at 10 failed attempts.
• Conditional launch. Require app version at or above the last two Microsoft releases; block jailbroken/rooted devices; timeout offline access at 12 hours; enforce OS version floors (iOS 17+, Android 12+).
• Conditional Access companion policy. Require approved-client-app OR app-protection-policy for the mobile Microsoft 365 apps. This is what makes MAM actually enforce — without the CA policy, MAM is opt-in.
• Rollout. Report-only in the CA policy for two weeks; monitor sign-in log for "grant control not satisfied" reasons; publish a two-line user comms on what will change. Enforce after the noise settles.

Not in this baseline (deliberately): SafetyNet strict integrity checks (fail rate on some devices), full mobile threat defense integration (extra product cost).

Decision matrix: MAM only, MDM only, or both

| Situation | Posture | | --- | --- | | BYOD, users won't tolerate enrolment | MAM only | | Corporate device, wants full-device management | MDM + MAM (MAM policies still apply to the M365 apps on the enrolled device) | | Frontline shared device | MDM in shared-device mode — MAM's per-user model doesn't fit | | High-security role on corporate device | MDM + MAM + Defender for Endpoint mobile | | Contractor with their own laptop, sensitive work | App protection for Windows (in preview/GA where available) + Conditional Access | | Personal device just needing Outlook mail | MAM with approved-client-app CA — no enrolment |

When MAM is the wrong tool

• You need to enforce a wallpaper, Wi-Fi profile, or VPN. That's MDM. MAM has no line of sight to device-level configuration.
• You need location-aware controls. MAM can't do geo-fencing. Pair with Conditional Access named locations or Global Secure Access.
• You need remote-wipe of the whole device. Selective wipe (of app data only) is the MAM ceiling. Full-device wipe requires enrolment.
• The user has a third-party mail client. MAM only enforces on policy-managed apps, and third-party clients are not in that set. Restrict client via CA or accept the risk.
• You're paranoid about local-storage exfil. Modern iOS/Android app-container isolation is strong, but a fully compromised device can bypass MAM. Combine with mobile threat defense if the risk profile demands it.

MSP checklist

• Two baselines per client, iOS and Android policies with identical semantics but device-specific quirks called out.
• Pair every MAM policy with a CA app-protection policy. MAM without the CA gate is a documentation-only control.
• Version-floor bumps quarterly. iOS majors ship in September, Android in August-September; move the floor to the current minus one within 60 days.
• Diagnostics. Teach client support to open the M365 app > Settings > Send feedback / diagnostic reports — the CompanyPortal logs are where "PIN prompt won't dismiss" actually gets diagnosed.
• Report card. Monthly per-client: users with app-protection status non-compliant, devices below OS floor, users with recent MAM check-in failures. Anomalies are usually a build rollout mismatch, not a security incident.