Android Enterprise vs device administrator (legacy) enrolment 

Under review

This document is currently under review in order to improve it. If you have questions you’d like to be addressed here, please let me know.

If you’ve read What is Android Enterprise and why is it used?, you’ll know Android Enterprise (AE) offers several rather useful features and deployment scenarios to suit many business requirements.

A recurring query when discussing Android Enterprise is, as you might expect:

How is it different from legacy (device administrator) enrolment?

The answer depends on whether we’re talking about standard, vanilla Android or Samsung. I’ll explain why:

Vanilla Android

What’s vanilla Android in this context? Basically any device not running Samsung’s Knox APIs – devices may be heavily skinned, have additional features over and above AOSP but as far as management goes, they’re essentially pretty much what you get when building from source.

Out of the box, Android as provided by many OEMs offers almost (or) no management APIs for EMMs to leverage, simply because they’ve never – before Android Enterprise – been included as standard in the Android source code OEMs use to build their device images.

Some OEMs have over the years implemented their own APIs here and there for different capabilities that make for a partially manageable device, however this equally requires that EMMs choose to leverage these bespoke APIs for the functionality offered, which hasn’t always been the case. When they do, in addition to having to request device administrator permissions for the EMM agent, it’s not unlikely the EMM would require an additional in-house application is installed on the device to better leverage these APIs – that normally involves enabling unknown sources (via a user prompt) and sideloading APKs. Not very secure.

AirWatch restriction support by different OEMs

Beyond basic security policies and perhaps a simple email/WiFi/etc configuration then, there’s not a lot administrators can manipulate and control with a vanilla Android device, which already makes them rather unappealing for use in an enterprise setting.

When you then consider application management relies on the use of a Google account and requires users manually download applications from Google Play distributed to them via the EMM platform, it becomes even clearer to see the overhead for supporting these devices is rather high. Further complicating things, the introduction of Factory Reset Protection (FRP) means wiping a device without first removing the users’ Google account may render the device unusable. Really not an ideal situation to end up in.

This is not to say these devices have no place in an enterprise setting. Organisations that support a Bring Your Own Device (BYOD) initiative will find most EMMs have containerisation solutions permitting the use of corporate applications within an encrypted, sandboxed environment. Assuming the organisation doesn’t want to control the devices, rather only the corporate data on those devices, it’s possible to support vanilla Android.

Samsung and Knox (<2.8)

Knox 3.0 unifies with Android Enterprise

In January 2018, Samsung announced the unification of their Knox APIs with the Android Enterprise solution set. From Knox 3.0, Samsung devices will utilise and build upon the base Android Enterprise APIs. This coincides with the deprecation of Device Administrator APIs in 2019. The below information therefore references Knox version 2.8 and lower.

Samsung devices on the other hand have had deep EMM integration via their Knox and Knox Premium solutions for many years both on the software and hardware level as I’ve spoken about previously.

When a Samsung device is enrolled normally (as in, not via Knox Premium), EMM administrators have management over the device to a degree similar to that of an Android Enterprise work-managed device; there are an abundance of restrictions available, excellent visibility of device posture, integration with back-end corporate solutions and more flexibility in how a device is deployed. In fact, there are currently more restrictions available on a Samsung device than an equivalent work-managed device while Google continues to work towards feature parity.

If organisations then also choose to combine this with an EMM container in order to partition off critical corporate applications behind an additional passcode-enabled and encrypted sandbox, it potentially offers far more protection than doing so on a vanilla Android device.

Like vanilla Android however, Samsung (Knox basic) enrolment still succumbs to some less than ideal requirements, namely unknown sourcesdevice administrator permissions, and the need for a Google account for application management (there are some APIs for silent application installation, however these are based around in-house applications, not public Play Store apps). There’s also no quick way of getting the device enrolled equivalent to Android Enterprise, requiring the end-user goes through the device setup wizard before being able to obtain the EMM agent to begin enrolment unless leveraging Knox Mobile Enrolment.

For organisations with a budget, Samsung offers a number of paid solutions that benefit from tight hardware/software integration and enhanced security. It does make the experience much closer to that of Android Enterprise work-managed provisioning (and improves upon it in some cases currently), however as these tools are not free, and where an organisation is already paying for an EMM solution, buying licenses for something else may not be particularly appealing. More information about KNOX solutions can be found here.


Android Enterprise isn’t 100% guaranteed to improve on Android management, particularly if the KNOX solutions are already in place, however most organisations and particularly those who want to more easily support a diverse range of devices will benefit massively from the consistent experience, the automated management of Google accounts and the remote application configuration.


There are no comments on Discuss yet, click below to leave one: