Frequently asked questions about MAM and app protection

MAM Overview

App protection policies are rules that ensure an organization's data remains safe or contained in a managed app. A policy can be a rule that is enforced when the user attempts to access or move "corporate" data, or a set of actions that are prohibited or monitored when the user is inside the app.

See the Android app protection policy settings and iOS/iPadOS app protection policy settings for detailed information on each app protection policy setting.

If you apply a MAM policy to the user without setting the device management state, the user gets the MAM policy on both the BYOD device and the Intune-managed device. You can also apply a MAM policy based on the device management state. So when you create an app protection policy, next to Target to apps on all device types, you'd select No. Then do any of the following:

• Apply a less strict MAM policy to Intune managed devices, and apply a more restrictive MAM policy to non MDM-enrolled devices.
• Apply an equally strict MAM policy to Intune managed devices as to 3rd party managed devices.
• Apply a MAM policy to unenrolled devices only.

For more information, see How to monitor app protection policies.

Any app that has been integrated with the Intune App SDK or wrapped by the Intune App Wrapping Tool can be managed using Intune app protection policies. See the official list of Intune-managed apps available for public use.

• The end user must have a Microsoft Entra account. See Add users and give administrative permission to Intune to learn how to create Intune users in Microsoft Entra ID.

• The end user must have a license for Microsoft Intune assigned to their Microsoft Entra account. See Manage Intune licenses to learn how to assign Intune licenses to end users.

• The end user must belong to a security group that is targeted by an app protection policy. The same app protection policy must target the specific app being used. App protection policies can be created and deployed in the Microsoft Intune admin center. Security groups can currently be created in the Microsoft 365 admin center.

• The end user must sign into the app using their Microsoft Entra account.

The Intune SDK development team actively tests and maintains support for apps built with the native Android, iOS/iPadOS (Obj-C, Swift), Xamarin, and Xamarin.Forms platforms. While some customers have had success with Intune SDK integration with other platforms such as React Native and NativeScript, we don't provide explicit guidance or plugins for app developers using anything other than our supported platforms.

The Intune App SDK can use the Microsoft Authentication Library for its authentication and conditional launch scenarios. It also relies on MSAL to register the user identity with the MAM service for management without device enrollment scenarios.

• The end user must have the Outlook mobile app installed to their device.

• The end user must have a Microsoft 365 Exchange Online mailbox and license linked to their Microsoft Entra account.

  Note

  The Outlook mobile app currently only supports Intune App Protection for Microsoft Exchange Online and Exchange Server with hybrid modern authentication and doesn't support Exchange in Office 365 Dedicated.

• The end user must have a license for Microsoft 365 Apps for business or enterprise linked to their Microsoft Entra account. The subscription must include the Office apps on mobile devices and can include a cloud storage account with OneDrive for Business. Microsoft 365 licenses can be assigned in the Microsoft 365 admin center following these instructions.

• The end user must have a managed location configured using the granular save as functionality under the "Save copies of org data" application protection policy setting. For example, if the managed location is OneDrive, the OneDrive app should be configured in the end user's Word, Excel, or PowerPoint app.

• If the managed location is OneDrive, the app must be targeted by the app protection policy deployed to the end user.

  Note

  The Office mobile apps currently only support SharePoint Online and not SharePoint on-premises.

Intune marks all data in the app as either "corporate" or "personal." Data is considered "corporate" when it originates from a business location. For the Office apps, Intune considers the following as business locations: email (Exchange) or cloud storage (OneDrive app with a OneDrive for Business account).

See Skype for Business license requirements. For Skype for Business (SfB) hybrid and on-premises configurations, see Hybrid Modern Auth for SfB and Exchange goes GA and Modern Auth for SfB on-premises with Microsoft Entra ID, respectively.

Multi-identity support is the ability for the Intune App SDK to only apply app protection policies to the work or school account signed into the app. If a personal account is signed into the app, the data is untouched.

Multi-identity support allows apps with both "corporate" and consumer audiences (i.e. the Office apps) to be released publicly with Intune app protection capabilities for the "corporate" accounts.

Because Outlook has a combined email view of both personal and "corporate" emails, the Outlook app prompts for the Intune PIN on launch.

The Personal Identification Number (PIN) is a passcode used to verify that the correct user is accessing the organization's data in an application.

Intune prompts for the user's app PIN when the user is about to access "corporate" data. In multi-identity apps such as Word/Excel/PowerPoint, the user is prompted for their PIN when they try to open a "corporate" document or file. In single-identity apps, such as line-of-business apps managed using the Intune App Wrapping Tool, the PIN is prompted at launch, because the Intune App SDK knows the user's experience in the app is always "corporate."

The IT admin can define the Intune app protection policy setting 'Recheck the access requirements after (minutes)' in the Microsoft Intune admin center. This setting specifies the amount of time before the access requirements are checked on the device, and the application PIN screen is shown again. However, important details about PIN that affect how often the user will be prompted are:

• The PIN is shared among apps of the same publisher to improve usability: On iOS/iPadOS, one app PIN is shared amongst all apps of the same app publisher. On Android, one app PIN is shared amongst all apps.
• The 'Recheck the access requirements after (minutes)' behavior after a device reboot: A "PIN timer" tracks the number of minutes of inactivity that determine when to show the Intune app PIN next. On iOS/iPadOS, the PIN timer is unaffected by device reboot. Thus, device restart has no effect on the number of minutes the user has been inactive from an iOS/iPadOS app with Intune PIN policy. On Android, the PIN timer is reset on device reboot. As such, Android apps with Intune PIN policy will likely prompt for an app PIN regardless of the 'Recheck the access requirements after (minutes)' setting value after a device reboot.
• The rolling nature of the timer associated with the PIN: Once a PIN is entered to access an app (app A), and the app leaves the foreground (main input focus) on the device, the PIN timer gets reset for that PIN. Any app (app B) that shares this PIN won't prompt the user for PIN entry because the timer has reset. The prompt will show up again once the 'Recheck the access requirements after (minutes)' value is met again.

For iOS/iPadOS devices, even if the PIN is shared between apps from different publishers, the prompt will show up again when the Recheck the access requirements after (minutes) value is met again for the app that isn't the main input focus. So, for example, a user has app A from publisher X and app B from publisher Y, and those two apps share the same PIN. The user is focused on app A (foreground), and app B is minimized. After the Recheck the access requirements after (minutes) value is met and the user switches to app B, the PIN would be required.

The Intune PIN works based on an inactivity-based timer (the value of 'Recheck the access requirements after (minutes)'). As such, Intune PIN prompts show up independently from the built-in app PIN prompts for Outlook and OneDrive which often are tied to app launch by default. If the user receives both PIN prompts at the same time, the expected behavior should be that the Intune PIN takes precedence.

The PIN serves to allow only the correct user to access their organization's data in the app. Therefore, an end user must sign in with their work or school account before they can set or reset their Intune app PIN. This authentication is handled by Microsoft Entra ID via secure token exchange and isn't transparent to the Intune App SDK. From a security perspective, the best way to protect work or school data is to encrypt it. Encryption isn't related to the app PIN but is its own app protection policy.

As part of the app PIN policy, the IT administrator can set the maximum number of times a user can try to authenticate their PIN before locking the app. After the number of attempts has been met, the Intune App SDK can wipe the "corporate" data in the app.

MAM (on iOS/iPadOS) currently allows application-level PIN with alphanumeric and special characters (called 'passcode') which requires the participation of applications (i.e. WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for iOS/iPadOS. Without this, the passcode settings aren't properly enforced for the targeted applications. This was a feature released in the Intune SDK for iOS/iPadOS v. 7.1.12.

In order to support this feature and ensure backward compatibility with previous versions of the Intune SDK for iOS/iPadOS, all PINs (either numeric or passcode) in 7.1.12+ are handled separately from the numeric PIN in previous versions of the SDK. Therefore, if a device has applications with Intune SDK for iOS/iPadOS versions before 7.1.12 AND after 7.1.12 from the same publisher, they'll have to set up two PINs.

That being said, the two PINs (for each app) aren't related in any way i.e. they must adhere to the app protection policy that's applied to the app. As such, only if apps A and B have the same policies applied (with respect to PIN), user may set up the same PIN twice.

This behavior is specific to the PIN on iOS/iPadOS applications that are enabled with Intune Mobile App Management. Over time, as applications adopt later versions of the Intune SDK for iOS/iPadOS, having to set a PIN twice on apps from the same publisher becomes less of an issue. Please see the note below for an example.

IT administrators can deploy an app protection policy that requires app data to be encrypted. As part of the policy, the IT administrator can also specify when the content is encrypted.

See the Android app protection policy settings and iOS/iPadOS app protection policy settings for detailed information on the encryption app protection policy setting.

Only data marked as "corporate" is encrypted according to the IT administrator's app protection policy. Data is considered "corporate" when it originates from a business location. For the Office apps, Intune considers the following as business locations: email (Exchange) or cloud storage (OneDrive app with a OneDrive for Business account). For line-of-business apps managed by the Intune App Wrapping Tool, all app data is considered "corporate."

Intune can wipe app data in three different ways: full device wipe, selective wipe for MDM, and MAM selective wipe. For more information about remote wipe for MDM, see Remove devices by using wipe or retire. For more information about selective wipe using MAM, see the Retire action and How to wipe only corporate data from apps.

Wipe removes all user data and settings from the device by restoring the device to its factory default settings. The device is removed from Intune.

See Remove devices - retire to read about removing company data.

Selective wipe for MAM simply removes company app data from an app. The request is initiated using the Microsoft Intune admin center. To learn how to initiate a wipe request, see How to wipe only corporate data from apps.

If the user is using the app when selective wipe is initiated, the Intune App SDK checks every 30 minutes for a selective wipe request from the Intune MAM service. It also checks for selective wipe when the user launches the app for the first time and signs in with their work or school account.

Intune app protection depends on the identity of the user to be consistent between the application and the Intune App SDK. The only way to guarantee that is through modern authentication. There are scenarios in which apps may work with an on-premises configuration, but they're neither consistent nor guaranteed.

Yes! The IT administrator can deploy and set app protection policy for the Microsoft Edge app. The IT administrator can require all web links in Intune-managed apps to be opened using the Microsoft Edge app.

Company Portal app and Intune app protection

Intune app protection policies for access will be applied in a specific order on end user devices as they try to access a targeted app from their corporate account. In general, a block would take precedence, and then a dismissible warning. For example, if applicable to the specific user/app, a minimum Android patch version setting that warns a user to take a patch upgrade will be applied after the minimum Android patch version setting that blocks the user from access. So, in the scenario where the IT admin configures the min Android patch version to 2018-03-01 and the min Android patch version (Warning only) to 2018-02-01, while the device trying to access the app was on a patch version 2018-01-01, the end user would be blocked based on the more restrictive setting for min Android patch version that results in blocked access.

When dealing with different types of settings, an app version requirement would take precedence, followed by Android operating system version requirement and Android patch version requirement. Then, any warnings for all types of settings in the same order are checked.

The Intune service will contact Google Play at a non-configurable interval determined by service load. Any IT admin configured action for Google Play’s device integrity check setting will be taken based on the last reported result to the Intune service at the time of conditional launch. If the Google's device integrity result is compliant, no action is taken. If the Google's device integrity result is non-compliant, the IT admin configured action will be taken immediately. If the request to Google Play’s device integrity check fails for any reason, the cached result from the previous request will be used for up to 24 hours or the next device restart, which ever comes first. At that time Intune App Protection Policies will block access until a current result can be obtained.

The instructions on how to do this varies slightly by device. The general process involves going to the Google Play Store, then clicking on My apps & games, clicking on the result of the last app scan which will take you into the Play Protect menu. Ensure the toggle for Scan device for security threats is switched to on.

Intune leverages Google Play Integrity APIs to add to our existing root detection checks for unenrolled devices. Google has developed and maintained this API set for Android apps to adopt if they don't want their apps to run on rooted devices. The Android Pay app has incorporated this, for example. While Google doesn't share publicly the entirety of the root detection checks that occur, we expect these APIs to detect users who have rooted their devices. These users can then be blocked from accessing, or their corporate accounts wiped from their policy enabled apps. 'Check basic integrity' tells you about the general integrity of the device. Rooted devices, emulators, virtual devices, and devices with signs of tampering fail basic integrity. 'Check basic integrity & certified devices' tells you about the compatibility of the device with Google's services. Only unmodified devices that have been certified by Google can pass this check. Devices that will fail include the following:

• Devices that fail basic integrity
• Devices with an unlocked bootloader
• Devices with a custom system image/ROM
• Devices for which the manufacturer didn't apply for, or pass, Google certification
• Devices with a system image built directly from the Android Open Source Program source files
• Devices with a beta/developer preview system image

See Google's documentation on Play Integrity API for technical details.

Google Play Integrity API checks require the end user being online, atleast for the duration of the time when the "roundtrip" for determining attestation results executes. If end user is offline, IT admin can still expect a result to be enforced from the 'jailbroken/rooted devices' setting. That being said, if the end user has been offline too long, the 'Offline grace period' value comes into play, and all access to work or school data is blocked once that timer value is reached, until network access is available. Turning on both settings allows for a layered approach to keeping end user devices healthy which is important when end users access work or school data on mobile.

Both the 'Play integrity verdict', and 'Threat scan on apps' settings require Google determined version of Google Play Services to function correctly. Since these are settings that fall in the area of security, the end user will be blocked if they have been targeted with these settings and aren't meeting the appropriate version of Google Play Services or have no access to Google Play Services.

Intune app protection policies allow control over app access to only the Intune licensed user. One of the ways to control access to the app is to require either Apple's Touch ID or Face ID on supported devices. Intune implements a behavior where if there's any change to the device's biometric database, Intune prompts the user for a PIN when the next inactivity timeout value is met. Changes to biometric data include the addition or removal of a fingerprint, or face. If the Intune user doesn't have a PIN set, they're led to set up an Intune PIN.

The intent of this is to continue keeping your organization's data within the app secure and protected at the app level. This feature is only available for iOS/iPadOS, and requires the participation of applications that integrate the Intune APP SDK for iOS/iPadOS, version 9.0.1 or later. Integration of the SDK is necessary so that the behavior can be enforced on the targeted applications. This integration happens on a rolling basis and is dependent on the specific application teams. Some apps that participate include WXP, Outlook, Managed Browser, and Yammer.

Intune app protection policy cannot control the iOS share extension without managing the device. Therefore, Intune encrypts "corporate" data before it's shared outside the app. You can validate this by attempting to open the "corporate" file outside of the managed app. The file should be encrypted and unable to be opened outside the managed app.

Intune app protection policies for access will be applied in a specific order on end user devices as they try to access a targeted app from their corporate account. In general, a wipe would take precedence, followed by a block, and then a dismissible warning. For example, if applicable to the specific user/app, a minimum iOS/iPadOS operating system setting that warns a user to update their iOS/iPadOS version will be applied after the minimum iOS/iPadOS operating system setting that blocks the user from access. So, in the scenario where the IT admin configures the min iOS/iPadOS operating system to 11.0.0.0 and the min iOS/iPadOS operating system (Warning only) to 11.1.0.0, while the device trying to access the app was on iOS/iPadOS 10, the end user would be blocked based on the more restrictive setting for min iOS/iPadOS operating system version that results in blocked access.

When dealing with different types of settings, an Intune App SDK version requirement would take precedence, and then an app version requirement, followed by the iOS/iPadOS operating system version requirement. Then, any warnings for all types of settings in the same order are checked. We recommend the Intune App SDK version requirement be configured only upon guidance from the Intune product team for essential blocking scenarios.

See also

• Deploy Intune
• Create a rollout plan
• Android mobile app management policy settings in Microsoft Intune
• iOS/iPadOS mobile app management policy settings
• App protection policies policy refresh
• Validate your app protection policies
• Add app configuration policies for managed apps without device enrollment
• How to get support in Microsoft Intune