App Protection Policies are the mechanism that makes MAM work – they define what managed applications can and can’t do with corporate data. Getting the design right matters because a policy that’s too restrictive creates user friction that drives people to workarounds, and a policy that’s too permissive provides the appearance of data protection without the substance.
The starting point for any APP design is understanding what you’re protecting and from what. Corporate data moving to personal storage, personal apps, or unmanaged contexts is the primary concern. A user copying an email attachment from Outlook to their personal Dropbox, sharing a document to WhatsApp, or taking a screenshot of sensitive data in a managed app – these are the behaviors that APP is designed to prevent. The policy settings map directly to these scenarios.
Data transfer controls are the core of any APP configuration. Cut, copy, and paste restrictions define whether data can move between managed and unmanaged apps – blocking paste from managed to unmanaged apps prevents corporate data from leaving the managed application boundary. Save-as restrictions define where documents can be saved – restricting saves to approved cloud storage locations like OneDrive and SharePoint keeps data in managed locations. The “Send org data to other apps” setting is the most critical single control – set to “Policy managed apps” it ensures corporate data can only be transferred to other Intune-managed applications. Allowing transfers to all apps or to no apps are both wrong for most scenarios. Policy managed apps is the right middle ground.
Access controls define what’s required to open a managed app. PIN requirements, biometric authentication, and work account authentication can all be required before accessing corporate data within a managed application. The balance here is between security and friction – requiring a PIN every time a user opens Outlook on their phone creates enough friction that some users stop using the managed app entirely. Configure access requirements that are meaningful without being punishing. A PIN after 30 minutes of inactivity is more defensible than a PIN on every app open, and produces less user resistance.
An APP that users route around defeats itself. The goal is protection that’s invisible to compliant users and effective against the data loss scenarios you’re actually worried about.
Conditional launch settings define what happens when a device doesn’t meet requirements – when the OS is below a minimum version, when the device is jailbroken or rooted, when the account has been inactive too long, or when sign-in risk is elevated. The response options range from blocking app access to wiping corporate data from the app. Wipe is a significant action – it removes all corporate data from the managed application on the device without touching personal data. For jailbroken or rooted devices, immediate wipe is the right response because the device’s security model has been fundamentally compromised. For OS version requirements, a warning period before blocking is more appropriate – users need time to update before losing access.
Platform differences require separate policy configurations. iOS and Android both support MAM, but the available settings and their behavior differ. Some settings that exist on Android don’t have iOS equivalents, and vice versa. Create separate APP configurations for iOS and Android rather than attempting a single policy that applies to both – the platform-specific behavior differences are significant enough that a shared policy invariably misconfigures one platform to accommodate the other. Android also carries two prerequisites that generate most of the “APP isn’t applying” tickets: Company Portal must be present on the device for policy delivery, even now that it no longer performs enrollment, and devices must be registered in Entra ID for Microsoft 365 apps to keep receiving MAM policy. Neither is a policy setting, and both fail silently from the admin’s chair.
App Protection Policies apply to the application, not the device. A user with a jailbroken personal phone and a compliant corporate phone will have APP apply on both – the policy follows the identity, not the device state.
Selective wipe is the operational capability that APP enables which MDM can’t provide for unenrolled devices. If a user leaves the organization or loses their device, Intune can wipe corporate data from all managed applications on that device without touching personal data. The wipe removes the corporate account and all associated data from the managed apps while leaving the user’s personal apps, photos, and data completely intact. For personal device scenarios, this is the appropriate remediation – and it only works because the data is contained within the managed application boundary that APP enforces.
The rollout sequence for APP follows the same pattern as everything else in this series – report-only equivalent first. Deploy the APP and monitor the sign-in logs and app protection reports in the Intune console before connecting it to Conditional Access enforcement. Understand which users and devices are being evaluated, whether the policy settings match your intent, and whether any settings are producing unexpected behavior. Then connect Conditional Access to require app protection policy for mobile access to corporate resources. The protection is real whether or not CA is enforcing it, but CA enforcement is what ensures users can’t access corporate data through unmanaged apps by simply not using the managed ones.
Intune Deployment Guide · Phase 9: Mobile and BYOD
‹ Previous: [9.4.3] Building iOS BYOD Onboarding: Web Device Enrollment and Account-Driven User Enrollment
Next: [9.5.1] Operating MAM: Version Floors, Conditional Launch, and Selective Wipe ›
