As we approach 2017, I’m consolidating all of our writing about mobile application management into a three-part guide.
- The first part covers MAM concepts: Why we need it, why it’s challenging, and why the marketplace can be confusing.
- The second part digs into different MAM techniques.
- This final part will put these techniques in the context of various use cases and stakeholders. This is a longer article; think of it more as a reference than a narrative piece.
Most devices could benefit from some type of MAM
Most devices that are used to access corporate apps and data will also have some degree of personal apps and data on them. This is true for both BYOD (which happens in some way or another at every organization, whether formally controlled or not) and for COPE. (COPE stands for corporate-owned, personally-enabled. There are a lot of different models and degrees of control, but the point is there will be personal apps and data on most devices.)
Unless you can issue locked-down corporate devices to all your users, and correspondingly lock down all your applications so users can’t access them on their personal devices, you need to be thinking about MAM for the reasons outlined back in the first part of this series.
Now you may look at the situation and decide that you don’t need controls that are too extreme, or that maybe figuring out SSO and federation for cloud apps is a higher priority, but no matter what, multi-tenant mobile devices are a part of end user computing now.
BYOD and COPE
Enrolling personally-owned mobile devices in MDM—which is needed for device-level MAM—can still be challenging. Users are worried about privacy and control. They’re thinking: Don’t look at what apps I have installed; don’t wipe my phone and erase my photos; don’t track my location; don’t make me use a long complex passcode.
Some EMM vendors are working on privacy education initiatives; adding more layers to protect privacy in admin consoles; or “adaptive enrollment,” where MDM is applied only at certain times. Many users won’t mind enrollment or even give it a second thought, especially if it gives them the convenience of easier access to work apps. And for COPE, there’s a clearer case for enrolling devices (though MAM-only on COPE is valid, too, and many COPE devices are de facto unmanaged today.) The caveat is that even if the users are willing, BYOD devices may not support the MDM or app-level management features that IT wants.
So for all these reasons, it’s likely that you’ll have to provide app-level MAM for some users and and device-level MAM for others. In fact, I’ve always been a proponent of letting users choose which option they want.
Email and Browsing
Besides privacy, another area where the choice of MAM technique will have a significant effect is email clients and browsers. Device-level MAM means using the client and browser that comes bundled with the OS, while app-level MAM means using a third-party browser.
As I mentioned in the previous installment of this series, on older versions of iOS, third-party email clients were at a distinct disadvantage, since there were limits on background activity like downloading message content. Today, though, not only are these limitations gone, but EMM vendors also add other useful features into their third-party clients. Third-party browsers aren’t as big of an issue, since they use the same rendering engine as the built-in browser.
But either way, this brings up a key issue: ever since the days of BYOD, consumerization, and shadow IT, it’s important that enterprise apps have a user experience and feature set that can compete with consumer alternatives.
Publicly-available apps, from the enterprise point of view
If you want to apply MAM features to an app that comes from Google Play or the Apple App Store, you have a few options, but there are also some key sticking points.
Perhaps the ISV offering the app has already collaborated with your EMM vendor, and has implemented the corresponding MAM frameworks in the app. In this case, you can just download the app and start managing it.
If that’s not the case, maybe you (possibly with the help of your EMM vendor) can approach the ISV and convince them to make a MAM-enabled version of their app, or to let you or your EMM vendor modify and redistribute it.
Or, you can just rely on MAM features built into iOS, Android for Work, or Samsung Knox.
Another option is that the app might already have some security and management features built in, without the need for a separate EMM or MAM platform to use them.
But what if none of the above options works out?
If the app supports single sign on and federation, then using an identity management platform is another way to get control over when and how apps are accessed. And if you’re adopting cloud and SaaS apps, you should probably already be doing modern identity and access management, anyway.
When it comes to adding more MAM features, the industry has already established that we can’t wrap and re-distribute apps without permission. In this case, you could look at alternative technologies, like cloud access security brokers (implemented in the manner advocated by Bitglass) or virtual mobile infrastructure. However, neither Bitglass’s approach nor VMI are widespread yet.
Publicly-available apps, from the ISV point of view
ISVs can work with an EMM vendor to bake security and management capabilities into their apps, and enable their apps to securely share data with other apps in the ecosystem. This could give them a leg up among EMM customers, but it also makes their development and deployment process more complicated: To work with multiple EMM vendors, they either have to build multiple versions of their app (listed in the app stores as ExampleApp for AirWatch, ExampleApp for MobileIron, ExampleApp for Intune, etc.) or incorporate multiple SDKs. Even handing apps directly to customers so wrap can result in support issues. (To help solve these problems, I’ve long believed that some sort of standard API interface could be introduced for app-level MAM, but so unfortunately that’s proven to be a pipe-dream so far.)
In addition, some ISVs may have incentives to work with some EMM vendors and not others. For example, the app-level MAM functionality in Microsoft Office for iOS and Android works with Intune, but Microsoft will not incorporate the MAM SDKs of other vendors, or let customers wrap their apps.
Device-level MAM can alleviate some of these issues, but as we’ve discussed, is not usable in all circumstances. In addition, certain device-level MAM features (like support for managed configurations) still require the developer to be aware of and use certain APIs in the OS.
Some ISVs are holding off on using MAM SDKs or allowing customers to wrap and distribute their apps for now. Of course plenty of them still want to provide security and management features in their apps—they just do it on their own as they see fit. This could result in individual apps being in their own silos of MAM functionality, but it’s still good to have. And as I mentioned above, many enterprise-oriented ISVs are embracing standards for identity federation and single sign-on, which gives IT the opportunity to control app access, even without other MAM in place.
This is simple: Since it’s your app, you can incorporate the MAM SDK of your choice during the development process, or use an app wrapping tool later on, and be sure that you’ll always have MAM built into the app no matter what.
Extended enterprise: Non-employees
Many companies are providing apps for the so-called extended enterprise—i.e. contractors, part-time employees, partners, and seasonal workers that provide their own mobile devices. There’s very little chance you’ll want to bother enrolling these devices in MDM, for liability reasons, because of the additional overhead, and the because you might not be able manage these devices at all. (If a contractor already has their device enrolled in MDM at their own company, the device cannot be enrolled into a second MDM server at the same time, for example. This is another take on the multi-tenancy concept I talked about in part one of this series, only this time there are even more stakeholders: the user, their other employer, and your organization.) For these situations, you’ll have to provide apps with built-in MAM.
Extended enterprise: Embedded devices
In the case of mobile devices that are used as kiosks, point of sale terminals, digital signage, or with specialized accessories like a barcode scanner, personalization is likely not needed, so MAM isn’t a big problem. In fact, there have been a lot of advancements such as Apple Supervised Mode, the Device Enrollment Program, Android for Work corporate-owned business-only mode, Android for Work device-owner mode, and Samsung Knox Customization and Knox Enrollment. These have all the controls you need to configure a device, push apps, and generally lock down the experience into whatever you need it to be.
In some situations, you might consider app-level MAM features on top of device-level security controls. This could be to compensate for devices with inadequate built-in security and MAM features, or to simply have multiple layers of protection.
Android for Work (or just any newer Android devices, since Google very recently dropped the “for Work” part of the name) has a stronger work and personal separation concept than iOS. For example, work profiles (the conceptual container that holds enterprise apps and data) are required to be implemented in a way that keeps them from accessing any personal apps and data at all; Android 7.0 can have a password that applies to the work profile but not the device; and users can temporarily deactivate the work profile (great for getting away from “work” for the weekend).
All of these features have the potential to change the conversation around privacy issues, and therefore affect decisions about MAM. However, so far they’re not in widespread use enough to know for sure. Also, remember that Android is still a diverse set of devices, so you can’t always rely on BYOD Android supporting these features or other device-level frameworks like Samsung Knox.
On the iOS side, Apple has made a lot of progress with the built-in MAM features over the years, and many aspects of iOS (like personal photos and iMessage) are completely off-limits to MDM servers.
However, Apple could still go farther. Many MDM servers still reserve the right to view personally-installed apps, for example, and as mentioned before, iOS devices can only be associated with one MDM server at a time. I think another major evolution is due for iOS MDM; I’ll discuss this in another article in early January.
App Config Community and standalone MAM
The AppConfig Community emerged as a multi-vendor industry effort to promote device-level MAM features, establish a standard schema for app configuration, and provide best practices.
I applaud the cooperation and education efforts, but as we’ve seen throughout this series, other types of MAM are important, too. I think the AppConfig Community should take up these causes as well.
At the same time, there has been increasing awareness of app-level MAM, and the industry has gotten better at differentiating between techniques, introducing terms like “standalone MAM” and “MAM without device enrollment.”
From this whole series, we can see that multiple approaches to mobile app management are necessary in different situations—and also that some situations are still difficult for today’s MAM to handle. This is why it’s important to understand MAM.
MAM can be part of many enterprise mobility scenarios and decisions, but it’s difficult to give widespread blanket guidance. Instead, you must carefully consider the app, the ISV, the device, the ownership model, and the use case every single MAM decision.