The first Microsoft Intune feature to be generally available in the new Azure portal is stand-alone mobile application management (MAM). So what is MAM? Intune MAM applies protection at the application level of mobile apps and can be used in conjunction with any mobile device management (MDM) solution like AirWatch or MobileIron, or without any MDM at all. While many companies will want to consider a MDM solution for controlling security on their users’ devices, MAM can add another layer of security at the application level where policy can start to control the data used by the app not just the hardware used to access it. Organizations leveraging a bring your own device (BYOD) model may be hesitant to force users to put MDM software on their personal devices. In this case, MAM can help protect company data with a minimal footprint on the end user’s device.
Intune MAM can effectively create a container, a barrier preventing managed apps from sending data to non-managed apps. This not only applies to saving whole documents to non-managed apps but also copying and pasting from managed to non-managed apps. The managed apps are also smart enough to know that if data (a document, an email, etc.) comes from a managed source then that information cannot be saved to a non-managed location even inside the same app. This becomes even more important when the time comes to wipe the managed app from the device. The wipe of the managed app will only remove managed data, so a user’s personal data in a managed app stays on their device even after management has been removed. The beauty of this MAM container is that the end user doesn’t need to worry about it unless they try to take an action that violates the MAM policy.
Microsoft has good documentation for setting up stand-alone MAM policies in the new Azure portal so I won’t repeat that here, but let’s take a look at the settings that control the container features.
Figure 1 – Container settings in the Intune App Protection Blade of the new Azure portal.
There are four settings that can be changed to restrict data from moving from managed apps to unmanaged apps. The “Allow app to transfer data to other apps” and “Restrict cut, copy and paste with other apps” settings control the flow of data out of the managed apps. So by changing these settings to “Policy managed apps” and “Policy managed apps with paste in” respectively, we prevent managed apps from sending data to non-managed apps but allow them to work freely with the other managed apps. It should also be noted that the “Allow app to receive data from other apps” and “… with paste in” settings allow data to come into the managed apps from non-managed apps.
The final setting to consider configuring for the container is “Restrict web content to display in the Managed Browser.” The Managed Browser is a special web browser app that is published for iOS and Android by Microsoft and can therefore be managed by a MAM policy. If your users are going to be accessing sensitive corporate data via a web app, then forcing users to use the Managed Browser may make sense for you. However, if you don’t have corporate web apps that contain sensitive data, forcing users to download a separate web browser so they can follow links from within a managed app might defeat the idea of having a light touch on the user’s device. Consequently, if you are deploying a MAM-only solution to your users you should think carefully about changing this setting to “Yes.” The decision is easier if you are using MAM policies with an MDM solution since the MDM solution can deploy the Managed Browser to the device automatically.
Specific Details to Note
I also want to point out some of the finer points to be aware of when using Intune MAM.
MAM policies work exactly as you would expect for users who are in Office 365 and use the Microsoft suite of apps for iOS and Android. Unfortunately, there are limitations on the MAM with the Outlook app or native mail clients with on-premises Exchange, which my colleague Sean Nixon outlines in his post, Using Intune with Exchange On-Premises.
Stand-alone MAM is only currently supported for iOS and Android Microsoft apps. Support for line-of-business apps is in preview and third-party app support is said to be coming.
When iOS users log in to a managed app the first time they will be asked to restart the app and will from then on use the app with the MAM policy applied.
Figure 2 – iOS MAM restart message.
For Android users the Company Portal app must be downloaded from the Google Play store before accessing MAM controlled apps (Note: users do not have to sign into the Company Portal app).
Figure 3 – Android MAM requires the Company Portal app.
Figure 4 – Warning message after installing the Company Portal app.
MAM and MDM policies can be applied independently or jointly for different user groups but not for different devices for the same user because the MAM policy is applied to the user not the particular device.
MAM policies don’t support multiple users on the same device. Devices that are used by multiple users should not try to leverage MAM policies associated with those individual user accounts. Instead use a shared or service account as the user on the shared device. Trying to use multiple accounts on a device will result in the error message in figure 5 or 6 depending on your platform.
Figure 5 – iOS multiple accounts error message.
Figure 6 – Android multiple accounts error message.
Need MAM Help?
While MAM will not likely be a comprehensive solution to your mobile security landscape, it can help fill in gaps for BYOD users or add another layer of security to devices already managed by a MDM solution. Is your business dealing with mobile security challenges? Are you already licensed for EMS but don’t know how best to implement it to meet your business needs? Do you just have questions about the options available for mobile security? Credera has helped businesses implement mobile security strategy including the implementation of MAM policies and would be happy to help. Contact us at firstname.lastname@example.org.