Daily Intune News
Aboutmerill.net
Microsoft Intune
App management

Frequently Asked Questions about MAM and App Protection - Microsoft Intune | Microsoft Learn

9 November 2026Doc update+27 / −27 lines

In brief

The FAQ was revised with capitalization, formatting, terminology, SDK guidance wording, and updated page metadata.

What Intune admins need to know

Administrators can continue using the FAQ as a reference; no action is specified.

This summary was assembled from the tracked documentation change. Verify important details in the full Microsoft Learn article.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

Frequently asked questionsAsked Questions about MAM and app protectionApp Protection - Microsoft Intune | Microsoft Learn

This article provides answers to some frequently asked questions on Intune mobile application management (MAM) and Intune app protection.

What are app protection policies?

App protection policies are rules that ensure an organization's data remains safe or contained in a managed app. A policy is a rule that Intune enforces when the user tries to access or move "corporate" data. It can also define actions that Intune blocks or monitors while the user is in the app.

What are examples of app protection policies?

Is it possible to have both MDM and MAM policies applied to the same user at the same time, for different devices?

If you apply a MAM policy to the user without setting the device management state, the user gets the MAM policy on both the personal device, also known as a bring-your-own-device (BYOD), 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 choose one of the following options:

  • 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 and to non-Microsoft managed devices.

  • The end user must have a Microsoft Entra account. For more information on how to create Intune users in Microsoft Entra ID, see Add users and give administrative permission to Intune.

  • The end user must have a license for Microsoft Intune assigned to their Microsoft Entra account. For more information on how to assign Intune licenses to end users, see Manage Intune licenses.

  • The end user must belong to a security group 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.

What if I want to enable an app with Intune App Protection but it isn't using a supported app development platform?

The Intune SDK development team actively tests and maintains support for apps built with the native Android, iOS/iPadOS (Obj-C, Swift), .NET and MAUI platforms. Some customers successfully integrate the Intune SDK with other platforms, such as React Native and NativeScript. However, Microsoft doesn't provide guidance or plugins for platforms other than the supported ones.

Does the Intune APP SDK support Microsoft Authentication Library (MSAL)?

Why is a managed location (that is, OneDrive) needed for Office?

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

What are the other requirements to use Skype for Business?

What is the purpose of multi-identity support?

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

What about Outlook and multi-identity?

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

What is the Intune app PIN?

When is the user prompted to enter their PIN?

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."

How often are users prompted for the Intune PIN?

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, importantImportant details about PIN that affect how often users are prompted are:

  • The PIN is shared among apps of the same publisher to improve usability: On iOS/iPadOS, one app PIN is shared among all apps of the same app publisher. On Android, one app PIN is shared among 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 is 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: OnceAfter 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 doesn'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.

On iOS/iPadOS devices, apps from different publishers can share the same PIN. However, when the Recheck the access requirements after (minutes) value is reached, Intune prompts the user for a PIN if the app wasn'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.

Note

In order to verify the user's access requirements more often (that is, PIN prompt), especially for a frequently used app, reduce the value of the 'Recheck the access requirements after (minutes)' setting.

How does the Intune PIN work with built-in app PINs for Outlook and OneDrive?

The Intune PIN works based on an inactivity-based timer (thetimer, 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.

Is the PIN secure?

The PIN serves to allow only the correct user to access their organization's data in the app. Therefore, anAn end user must sign in with their work or school account before they can set or reset their Intune app PIN. Microsoft Entra ID handles this authentication through 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.

How does Intune protect the PIN against brute force attacks?

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 is met, the Intune App SDK can wipe the "corporate" data in the app.

Why do I have to set a PIN twice on apps from same publisher?

Note

App versions determine whether a shared PIN is possible. For example, if app A uses an SDK version earlier than 7.1.12 and app B uses version 7.1.12 or later, the user must set up a separate PIN for each app—even if they’they're from the same publisher. However, if apps A and C both use pre-7.1.12 versions, they share a PIN. Likewise, apps B and D share a PIN if both use SDK 7.1.12 or later.

What about encryption?

What gets encrypted?

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 Office apps, Intune treats email (Exchange) and cloud storage (OneDrive) as business locations. For line-of-business apps managed by the Intune App Wrapping Tool, all app data is considered "corporate."

How does Intune remotely wipe data?

Intune can wipe app data in three different ways: full device wipe, wipe, selective wipe for MDM,MDM, and MAM selective wipe.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.

What is wipe?

Why is the Company Portal app needed for Intune app protection to work on Android devices?

See Company Portal app and Intune app protection.

How do multiple Intune app protection access settings that are configured to the same set of apps and users work on Android?

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.

Intune App Protection Policies provide the capability for admins to require end user devices to pass Google Play's device integrity check for Android devices. How often is a new Google Play’Play's device integrity check result sent to the service?

The Intune service contacts Google Play at a nonconfigurable interval determined by service load. Any IT admin configured action for Google Play’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 noncompliant, the IT admin configured action is taken immediately. If the request to Google Play’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 block access until a current result can be obtained.

Intune App Protection Policies provide the capability for admins to require end user devices to send signals viaby using Google's Verify Apps API for Android devices. How can an end user turn on the app scan so that they aren't blocked from access due to this?

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.

What does Google's Play Integrity API actually check on Android devices? What is the difference between the configurable values of 'Check basic integrity' and 'Check basic integrity & certified devices'?

There are two similar checks in the Conditional Launch section when creating an Intune App Protection Policy for Android devices. Should I be requiring the 'Play integrity verdict' setting or the 'jailbroken/rooted devices' setting?

Google Play Integrity API checks require the end user being online, atleastat least during 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.

The app protection policy settings that apply Google Play Protect APIs require Google Play Services to function. What if Google Play Services aren't allowed in the location where the end user might be?

I'm able to use the iOS share extension to open work or school data in unmanaged apps, even with the data transfer policy set to "managed apps only" or "no apps." Doesn't this leak data?

Intune app protection policy can't 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.

How do multiple Intune app protection access settings that are configured to the same set of apps and users work on iOS?

Daily Intune.Admin.News

Get daily email updates

Get a concise summary of the latest Microsoft Intune updates delivered straight to your inbox.

Loading the secure signup form…