Apple should let iOS devices connect to multiple MDM servers in a “Limited MDM” mode

For years Apple has been steadily advancing the enterprise mobility management features in iOS. The next steps should be to let devices connect to multiple MDM servers, and to do so in a way that emphasizes app management, not device-wipe policies.

For years Apple has been steadily advancing the enterprise mobility management features in iOS. The next steps should be to let devices connect to multiple MDM servers, and to do so in a way that emphasizes app management, not device-wipe policies.

Why we need another way to do MDM

Everybody was really excited about the mobile app management features that came out with iOS 7, and rightly so: they let IT use MDM to apply granular policies to specific apps. This meant that instead of using just special enterprise versions of apps to do MAM, any app from the app store—including popular, best-of-breed apps—could have MAM policies applied to them.

However, there are some limitations with this approach. First, iOS devices can only be connected to one remote MDM server at a time. This means that people that work multiple companies can’t take full advantage of MDM. For an example, think of doctors that work in multiple hospitals. There are also many companies have multiple MDM products from different vendors. Another problem with using the built-in iOS MAM features is that they do rely on an MDM connection after all, which is generally associated with taking control of the entire device. This means you still have to deal with all the same privacy and liability concerns as with MDM.

But what if this wasn’t the case? What if you could connect iOS devices to multiple MDM servers, and have them interact with the device in a way that emphasizes app-level control, not device-level control? For now I’ll call this concept “Limited MDM.”

How “Limited MDM” could work

Thanks to all the effort Apple has put into iOS management, most of the frameworks and concepts for Limited MDM are already in place. In fact, there’s even a precedent for having different types of MDM. (We already have Supervised Mode in addition to regular MDM, so Limited mode would fit right in.)

iOS MDM can already manage several different types of entities that aren’t the whole device, including individual email accounts, apps, Safari domains, and even content (in the form of books and PDFs in the iBooks app). Limited MDM mode would simply focus on these entities and not device-wide configurations.

Going farther, MDM can also keep the content in these managed entities separate from personal apps. There’s the “managed open in” restriction, which prevents documents from managed apps, Safari Domains, and email accounts from being opened in unmanaged entities; VPNs can be configured just for managed apps and domains; emails from managed accounts can be blocked from being moved into other accounts; and managed apps can be blocked from backing up data to iTunes or iCloud. If MDM can keep all this content away from personal apps, then it should be just as easy to separate content in entities managed by different MDM servers.

Finally, iOS can already work with multiple Exchange accounts and accept configuration profiles from multiple sources. (Profiles from secondary sources, i.e. not the remote MDM server, must be installed manually.)

The main difference for Limited MDM mode would simply be to allow connections to multiple MDM servers.

With multiple MDM servers, the key would be to limit their rights so they don’t conflict with each other or take over the whole device. Instead, their visibility and control would need to be limited to just the managed entities they’re responsible for.

This shouldn’t be too hard, though. Indeed the iOS MDM protocol already has provisions to limit the rights of the remote server, it’s just that in practice most MDM products are set up to take all the rights by default. To make Limited MDM mode work, certain device-wide rights would just not be available at all.

For example, you probably wouldn’t want a Limited MDM server to be allowed to wipe the whole device or poll it for what other apps or configuration profiles are installed. These functions are the very liabilities that make MDM inappropriate for certain use cases in the first place.

Other device-wide policies, like encryption and passwords, might still have to apply, though. Here the device could default to whichever MDM server has the strictest policy. (This is how iOS handles multiple Exchange accounts.) The only way around this that I could think of is if Apple came up with some way of selectively partitioning devices, so that passwords and encryption could only be applied to entities managed by MDM. This seems like a pretty big leap, though.

One thing that might have to change for Limited MDM mode is how tightly MDM can control data sharing between managed entities. Since a Limited MDM server doesn’t have as much visibility or control over the rest of the device as regular MDM, it would need to have tighter control over what it does manage. For example, take screen captures and lockscreen notifications, which can be restricted for the entire device using regular MDM. For Limited MDM, they would have to be modified so that restrictions would only apply to managed entities. Apple might also have to consider restricting other features like cut and paste.

Will it happen?

We can only guess what Apple’s plans are for MDM and MAM in iOS. And as I’ve written many times before, using built-in OS features is just one way to do MAM. Apps with built-in management that doesn’t depend on the device will continue to be important, if not grow in importance as more enterprise-specific apps get built.

But looking at the limitations of the built-in iOS MAM features today, along with the use cases and scenarios people talk about, I think the concept Limited MDM mode that I outlined could be an important tool for enterprise mobility management.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

"This meant that instead of using just special enterprise versions of apps to do MAM, any app from the app store—including popular, best-of-breed apps—could have MAM policies applied to them." - no, this isn't really the case. iOS managed app configuration (which I think is what you are referring to) allows the app developer to add code to their app which will enable certain config fields (e.g. server name, user name) to be pre-populated by an MDM product. However, for this to work, the app has to be "managed", which means installed by MDM, not from the app store. You therefore still need to jump through the same old hoops of getting the app developer to give you an unsigned copy of the app binary so that you can re-sign it with your enterprise cert, rebuild it it in XCode,upload to your MDM product, and then push it out to devices from there. THEN you have the power to use the configuration fields.


It is true that there doesn't have to be a separate version of the app (the vendor builds these iOS policy hooks into the standard version if they choose to do it at all) but that does not confer any particular advantage on the user. It's good for the developer in theory - they can add policies that should work across all MDM products instead of writing different versions using each MDM vendor's SDK.


I think your Limited MDM idea would have a problem with the Managed Open In function - one organisation may be happy with allowing data to be shared between the apps that it has installed, but once you allow a second organisation to install an app (which is also by definition managed) then it too can share data with the apps installed by the first org. The first org might not be happy wit this app being able to do this. The only way round this would be to have each MDM have a separate pool of managed apps - but if you do this, how do you cope if two MDMs both want to install and manage the same app?


Cancel

Hi TimB,


Good thoughts and ideas here!


One thing, though—Neither using MDM to push an app to a device nor using MDM to configure fields within an app require the app to be resigned and redistributed with an enterprise developer certificate.


All of the features that I wrote about—managed open in, per-app VPN, blocking iCloud/iTunes backup—can be applied to any app. The app must be installed via an MDM command, but it’s still just the regular version of the app that comes from the App Store.


Of course using the MDM protocol to configure settings within an app requires that the app is developed with these capabilities in the first place, but I wasn’t referring to those types of apps in this article. My assumption here is that many best-of-breed apps are not developed with any of these enterprise features in mind (because otherwise we wouldn’t have to worry about all this after-the-fact MAM stuff in the first place!) and as a result, for these apps our only option is to use MAM features that are built into the OS.


But you bring up an interesting point that I wasn’t thinking of at the time I wrote the article. If more ISVs enabled their apps to use MDM to configure settings within the app, then there’d be no need to have all the different EMM-vendor-specific versions.


The problem with this approach is that it also has the contingency of requiring MDM to be in place, and MDM is not suitable for all situations. (I wrote about this a while back in www.brianmadden.com/.../vmware-airwatch-and-box-announced-a-new-standards-based-mam-framework-is-this-the-solution-we-ve-been-waiting-for.aspx )


However, since Limited MDM mode could be acceptable in wider variety of situations, it would increase the utility of this technique.


(Now we can also argue that as enterprise mobile apps mature the need to add in MAM through app wrapping, building special MAM versions, or using OS-based MAM features will diminish. Instead, the apps will have more of the appropriate security and management features built in, and anything that needs to be configured will happen when the user logs in—so it’ll be more of an access and identity management issue. But that’s a subject for another time… www.brianmadden.com/.../if-mobile-apps-come-with-their-own-built-in-management-features-then-do-we-still-need-mdm-and-mam.aspx )


You also mentioned the possibility of “open in” conflicts—my idea is that with multiple MDM servers, turning on open-in permission would only apply to whatever apps or other entities are managed by that particular server; i.e. each server would be creating its own group of managed entities that could associate with each other, but not with personal entities or entities managed by other servers.


You are right that having multiple MDM servers that want to manage the same app would be a problem. I’m not sure what the answer is here. Allow multiple copies? Whichever server pushes the app to the device first wins? I’m not sure. Again this is where apps getting smart about handling multiple accounts and such could lead the way.


Anyway, thanks for the comment!


Cancel

Hey Brian,


I really like the idea, but there is a key issue:


Apple will need to make "Limited Management" not look like "management" at all or users will not want to use it.


Since employees often consider their devices to be "personal" (regardless of who actually bought the device), they resist anything that looks like "management" (we often saw a drop-out rate -- users that refuse email, VPN, or other services when management is required -- around 30-50% when companies implement MDM).


Extending your thoughts:


- Limited MDM should not require enrollment -- Apple should give companies the ability to add just a managed app (no "management" enrollment required) and only the app would be protected. Enrollment (even simplified) for MDM is just to scary and cumbersome for most employees who have a "personal" device.


- Limited MDM should allow separate password to access the app -- Your encryption is only as strong as your password, but this leads to the significant problem of: too long (8 chars) and the users will hate it; too short (4 digit PIN) and it won't be secure. There should be a device-supported long-password required to access the Limited MDM apps.


There is a long list of other features I think they would need to make Limited MDM useful for both the employee and IT, but without these two features, it won't address the key issue that users just don't trust their company with anything that remotely looks like management of their precious personal device.


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close