When IT security teams are evaluating how to secure their company data on mobile devices, they typically have two options. They can either secure the whole device, which is often referred to as Mobile Device Management (MDM) or they can secure just the enterprise apps, which is usually called Mobile Application Management (MAM). MAM solutions have long been regarded as a less invasive security solution that is best suited for Bring Your Own Device (BYOD) enterprise mobile policies. Because MAM allows for an IT administers to only control a container within a device, both administrators and employees can feel at ease knowing that personal data will not be accessible to the IT department.
With that in mind, here are five things you should consider when selecting a MAM product to secure your mobile apps.
1. Check that your MAM solution is compatible with apps employees use.
In order for an app to live within the MAM container, it requires the app developer to integrate their app with the MAM provider's proprietary libraries. This integration can be done via a process called "app wrapping" where the developer must send their app directly to the customer for them to wrap or via an SDK integration. That said, the "app wrapping" solution open questions regarding compliance with Apple terms for the app vendor and the customer. The SDK integration for MAM products tends to be very expensive for the app developers to support. For these reasons, many business apps in the app store will not support your MAM solution, so be sure to check whether your most commonly used apps are supported before investing.
2. Demo the MAM-specific versions of your business apps in advance.
It is common to see MAM-specific versions of an app side-by-side with the original version of the app in the app stores, but it's important to note that it doesn't necessarily mean they provide the same experience. Because it's expensive to integrate with MAMs, many app developers may decide to outsource the integrations. On some occasions, the MAM providers volunteer to do the integration themselves. While this is an ideal solution for the developer, it means that the MAM version of the app is maintained by a different developer which may not have all the most up-to-date features at any given time. A quick demo can help avoid any surprises.
3. Plan for MAM-integrated apps plan to respond more slowly to iOS updates.
It is common for MAM-integrated apps to experience unexpected behaviors after a new OS release. Typically, the MAM providers update their SDKs right in time for the new OS release and then send it out to the developers in the hopes of getting them to update the SDK within their apps. The issue arises when the app developers are primarily focused on getting their original app up to speed for the new OS release and updating the SDK becomes a second or third priority. Make sure your plans account for the likely delay in updates!
4. Develop a strategy to to ensure users download the MAM app, not the original app.
In many cases, there is no guarantee the user will install the protected MAM version of the app. For instance, if the user already had an app installed for personal use before they enrolled with the MAM solution, they will often continue to use it, which defeats the MAM protections. Methods to actually prevent users from installing the original version of the app varies for each app and are often not practical, so prepare to address this issue in your training and ongoing communications.
5. Remember: Once you pick a MAM provider, it can be challenging to switch.
Each MAM has their own way of implementing their app containers which also means that apps within one container may not be supported in other MAM containers. The nature of these proprietary solutions make it difficult to transition from one MAM provider to another. Typically, a transition requires that an admin uninstall a container from users' devices and ask the users to re-download the new container and all the new apps for that container which is a cumbersome process for most.