The complete guide to mobile application management: Understanding different MAM techniques

MAM features

Due in large part to the multi-tenant nature of modern mobile devices, MAM seeks to apply EMM controls to individual apps or groups of apps, instead of the entire device. (Refer back to part 1 for more context.) These tasks include:

• Encryption of app data.
• Secure network connectivity (per-app or micro VPN, etc.).
• Configure settings within apps (server addresses, usernames, customizable branding, etc.).
• Authentication and SSO for backend resources accessed by the app.
• Enforce a passcode or security challenge to open enterprise apps. (This may be the same as the authentication process, or simply a local passcode.)
• Secure data sharing between enterprise apps, and keep enterprise data out of person apps. (There are all sorts of direct and indirect ways to share data: “open in,” app extensions, intents, and system repositories like photo albums or calendars.)
• Remote data wipe or app disable.

There are other related tasks, like analytics, performance monitoring, and the full lifecycle process of building, signing, distributing, and updating apps. These are also important, but they represent a different set of issues, so I won’t be covering them in this series.

Types of MAM

How do all these management features and tasks get applied to apps? There are two primary ways:

1. Management features can be built directly into app packages themselves. I refer to this as “app-level MAM;” another term that’s becoming common is “standalone MAM.”
2. Many mobile devices have built-in management frameworks that can differentiate between enterprise apps and data and personal apps and data. These frameworks rely on underlying MDM enrollment. I call this the “device-level MAM” approach; it’s also known as the “AppConfig” approach.

App-level MAM

Where does app-level MAM come from?

• Apps that come directly from EMM vendors and have MAM features built in: The earliest examples were email clients such as Good for Enterprise. Today, examples can also include browsers, file sync and share apps, document editors, scanner and camera apps, and instant messaging.
• Software development kits (SDKs) or other libraries with MAM functionality which can be incorporated by developers while they’re building enterprise apps.
• App wrapping or app modification tools: These take existing pre-built app binaries and add a wrapper (sometimes called a shim or a shell) that has MAM functionality, possibly including the ability to intercept and redirect the app’s API calls. After wrapping, the apps are resigned and redistributed. Note that while there were wider uses in the past, today the industry agrees that you cannot wrap apps from public app stores; instead, you need the permission of the original developer or ISV.
• ISV partner ecosystems: Many EMM vendors have programs to encourage ISVs to incorporate their MAM SDKs into their apps.
• Some enterprise-orient apps also have MAM-like features of their own, configured in the apps’ own back-end services, instead of relying on EMM or MAM platforms.

To learn about the features in various app-level MAM products, you’ll have to refer to individual EMM vendors’ documentation.

Advantages of app-level MAM

• You can add any security or management features you want directly into your apps.
• You don’t have to worry about the device: MAM features in apps can compensate for device shortcomings, reduce the effects of Android fragmentation, and even allow apps to run on untrusted or compromised devices.
• No mobile device management is needed, which helps alleviate concerns about user privacy.

Disadvantages of app-level MAM

• App-level MAM is inherently limited to apps created with the above techniques in mind, or where the creator is fine with you modifying their app—as I mentioned before, you can’t just grab any app from an app store and wrap it.
• In the case of email clients, the performance of third-party apps might not be as good as the clients that come bundled with mobile OSes. This was especially an issue before iOS 7, when Apple was more restrictive of background tasks like downloading message content.
• Apps take longer to build and deploy, since you have to incorporate an SDK or wrap them. This can also add extra steps when the app or the MAM platform is updated.
• App-level MAM frameworks are proprietary to different EMM vendors. This can be a problem for customers, because their choice of EMM platform could limit the apps they are able to manage. This can also be a pain for ISVs: if they want their apps to have MAM features that are compatible with a variety of EMM platforms, they have to add in multiple SDKs, create multiple versions of their apps, or turn apps over to customers for wrapping.

Device-level MAM

What devices and operating systems have MAM features built in?

• Samsung Knox 2.0 and higher (on most Galaxy devices).
• iOS 7 and higher
• Android for Work, a framework available in Android 5.0 and higher (on most quality devices)
• Windows 10 with Windows Information Protection

The AppConfig Community, first initiated by AirWatch but now joined by several other major EMM vendors, has detailed information about MAM built into Android for Work and iOS. Other vendor resources can be found here.

Advantages of device-level MAM

• You can apply MAM features to any app—it doesn’t have to be a special app, and you don’t need anybody’s permission to do it.
• Since you’re relying on the device, you have consistent features for all apps.
• Device-level MAM features are enabled by the same organizations (Apple and Google) that are making the OS, so they share the same philosophy and goals., and MAM is baked into these devices.
• It’s simpler for EMM vendors to implement.

Disadvantages of device-level MAM

• Device-based MAM relies on MDM, so you must enroll, manage and trust the device. MDM enrollment is still a debated and sometime controversial practice for personal BYO devices, especially when it comes to user privacy. For some cases, like partners, contractors, and part-time workers, you might not want to or even be able to enroll users’ devices in MDM.
• The Android device landscape is still fragmented: Many devices don’t support Android for Work, or may not support more recent features.
• You’re limited to whatever management features the OS exposes. For example, iOS allows you to control the movements of enterprise documents and email messages, but it cannot disable the clipboard.

Alternative MAM techniques

Looking at the attributes of app-level and device-level MAM, you can see that there’s a gap: If you can’t get an app with MAM features built in, and you can’t manage the device, it may be impossible to apply MAM controls. However, there are a few alternative techniques that can address this scenario.

Virtual mobile infrastructure (VMI)

VMI is just like VDI, except with a hosted mobile OS instead of a desktop OS. Normal mobile apps run in a datacenter on a virtualized instance of Android (because Apple isn’t going to let anybody virtualize iOS); users connect using a specialized remote display protocol, and no data resides on the device. VMI hasn’t gained much adoption yet, and it comes with its own set of challenges, but conceptually we think it has a lot of potential for certain use cases.

Cloud access security broker (CASB)

CASBs can apply a variety of policies at the network level; and can be used with unaltered apps on unmanaged devices. So far the main vendor that’s promoting this as an alternative to MAM is Bitglass.

Just have two phones

It’s low-tech, but it works and is pretty common. This is also a simple way to keep enterprise calling and texting separate from personal calling and texting.

Wrap or modify publicly-distributed apps without the permission of the ISV

This would be convenient, and it’s attracted a few vendors over the years, but just to make the point again, the consensus is that the door on this is closed and we can’t do it.

Conclusion

Where do these differences actually matter? Is that gap that I talked about actually a problem? Can we declare one technique a winner? Stay tuned for part 3!