Mobile Application Management (MAM) for Android and iOS has been part of Microsoft Intune for many years now. MAM allows us to manage and protect corporate data on an application level. Besides protecting data, we can also set access requirements and perform a remote selective wipe of corporate data while leaving personal data untouched.

What makes this such a popular solution is that you can implement it even without enrolling and managing the device itself. As you can imagine, this makes it very applicable for those personal devices we don’t want to manage corporately.

In this blog post, I will guide you through the configuration of Mobile Application Management (MAM) for personal Android & iOS devices. The post will include the following sections;

• Preparation
• App protection policies
  • Data protection
  • Access requirements
  • Conditional launch
• Conditional access policy
• Onboarding experience
• Remote selective wipe
• Enrollment restrictions
• Wrap up

Preparation

Let’s get the licensing requirements out of the way first. Microsoft Entra ID P1 (for Conditional Access) and Microsoft Intune (for app protection policies) licenses are required, so assigning a Business Premium or M365 E3 subscription will be sufficient.

Next, please prepare your users for the upcoming changes, as you’ll need their help here. Communicate properly with your users or even offer them a step-by-step manual on how to register their devices with MAM. Users will have to install a broker app on their personal devices to retain access to corporate applications, which some users might even dislike. For iOS, this app is the Microsoft Authenticator app, and for Android, it’s the Company Portal app.

App protection policies

Mobile Application Management (MAM) for Android and iOS uses app protection policies to define how we want to protect our corporate data on the application level. These policies can apply to both corporately managed (MDM) and unmanaged personal devices.

App protection policies have many different settings to enable, disable, or configure. If you want to deploy a quick and solid baseline, Microsoft has documented three different configurations with three different protection levels for us to use.

• Level 1: Basic Security
• Level 2: Enhanced Security
• Level 3: High Security

I’ll be using my own set of recommended configuration settings, but feel free to use the Microsoft baselines; I promise you, I won’t feel offended.

To create your first app protection policy navigate to the Microsoft Intune admin center, and go to Apps > App protection policies > and click the +Create policy button. Note that you must create separate policies for Android and iOS devices.

Firstly, on the apps page of the configuration, you can specify the apps to which the policy should be applied to. I recommend selecting the “Core Microsoft apps” at least, as this will protect your most important apps, but protecting more apps is possible. See a list of supported apps here.

Next, let me share my baseline configuration with you, which will work for most (but not all) organizations.

Data protection

Here are my proposed data protection settings. It includes preventing actions such as copying/pasting, printing, screenshotting, downloading, or making backups of corporate data.

Restricting the “cut, copy, and paste” action may sound pretty harsh, and from my experience, users do indeed complain about it a lot. For this reason, I like to balance it out by configuring the “cut and copy character limit”. This way, we can prevent users from accidentally leaking large amounts of content (whole documents) while allowing them to cut or copy small bits of text, such as physical or e-mail addresses, to other apps.

Access requirements

Here are my proposed access requirement settings. It includes requiring a PIN or Biometrics to access corporately managed applications.

A couple of things that could be changed are, for example, the PIN length. Some companies prefer a length of 6. Another one is to lower the number of minutes to recheck the access requirements or to enforce PIN resets after a certain number of days. Overall, the above settings are balanced and work for most organizations. 

Conditional launch

Here are my proposed conditional launch settings. It includes configuring an offline grace period, maximum PIN attempts, and blocking access for old OS versions and jailbroken devices.

One more setting worth mentioning, as it is really powerful, is the “Max allowed threat level” device conditions setting. This setting uses the Mobile Threat Defense (MTD) connector and can be used to onboard devices into Microsoft Defender for Endpoint. As I described in this blog post, even unmanaged devices are supported.

Conditional access policy

Next, we need to enforce the app protection policies on our users, or else nothing will happen. We do this by configuring a conditional access policy, targeting the Android and iOS device platforms, and requiring app protection policies for users accessing corporate applications. I suggest targeting the same apps you configured in your app protection policies earlier to avoid conflicts.

To create your conditional access policy navigate to the Microsoft Entra admin center, and go to Protection > Conditional Access > Policies and click the +New policy button.

Alternatively, you can configure device filters to target only unmanaged devices if you want, but know that these app protection policies also work for managed devices, so this is not strictly necessary. 

Another thing to note is that users accessing managed apps with multiple company accounts is currently not supported. As a workaround, you should exclude any secondary accounts from your conditional access policy. This limitation has been around for quite some time, but it looks like support will finally arrive in June 2024. Check the roadmap item here.

Onboarding experience

After configuring the app protection and conditional access policy, we’ll take a look the onboarding experience.

Let’s imagine the user has a personal Android device and tries to access their corporate e-mail. Instead of Microsoft Outlook, they first attempt to sign in to the Gmail app.

As you can see, the Gmail app is not supported by app protection policies, so the sign-in is blocked. 

After we try to sign in to Microsoft Outlook, we are prompted to download and install our broken app, the company portal app. On iOS, the broker app will be the Microsoft Authenticator app.

After installing the broker app, the user is prompted to register their device with MAM. Once registered, they can set up their PIN and biometrics to access company apps.

Afterward, they can sign in to company-managed apps such as Outlook while being protected by the app protection policy.

Remote selective wipe

While you cannot fully manage a MAM-registered device, you can remotely wipe corporate data. To do this, navigate to the Microsoft Intune admin center, go to Apps > App selective wipe, and click the +Create wipe request button.

Then, select the user and its MAM-registered device and create the wipe request.

You’ll see the pending wipe request from the overview page.

The user will be notified that the corporate data has been removed while their personal data is untouched.

From the overview page, you, as an admin, can then check if the remote wipe was successful.

Enrollment restrictions

One small piece of advice before we wrap up this post. I suggest you disable personal device enrollments by setting up enrollment restrictions in Microsoft Intune. I wrote a quick guide on how to do this if you’re interested.

It is optional, but it will considerably help your deployment. Why? Let me ask you a question. What will happen if we require Android users to install the company portal app while allowing them to enroll their devices into Mobile Device Management? The answer is that users make mistakes and accidentally enroll their devices while using the app.

Wrap up

To wrap up, I just want to say that implementing app protection policies should be a must for any organization. It brings very high security value, especially for unmanaged devices but also for corporately managed devices, while the requirements are relatively low.

In this blog post, we’ve discussed MAM for Android and iOS. However, if you are interested in MAM for Windows, I recently wrote a post on it, even though there are not many capabilities yet. 

Mobile Application Management (MAM) for personal Android & iOS devices