Last updated June 11, 2019
At the Apple Worldwide Developer Conference (WWDC) this year, Apple announced a new mode of device enrollment, entitled “User Enrollment”. This enrollment mode is available in iOS 13 and macOS 10.15 Catalina. This is a notably different mode of enrollment than the previously available DEP enrolled, User Approved (UAMDM), or Supervised modes of enrollment. While these modes still exist, User Enrollment (sometimes referred to as “UEMDM”) aims to address Bring Your Own Device (BYOD) deployment scenarios specifically.
The existing modes of Apple MDM enrollment are powerful. A DEP enrolled and supervised device can be wiped, locked, and heavily restricted by an MDM administrator. In macOS, an MDM administrator is able to run powerful root-level commands and whitelist dangerous controls to applications and extensions. Likewise, an administrator can retrieve information about installed applications that were not installed by the MDM.
User Enrollment aims to severely restrict what the MDM can do to the device. Instead of the device being generally controlled by the MDM, the MDM has been given permission to operate in a confined space on the device, effectively providing business services to the end user without requiring the user to sacrifice their own privacy. On the same token, it increases the security around corporate data by cordoning off this data in a separate storage area. This results in a better balance of security and privacy for both the enterprise and the user in a BYOD scenario.
User Enrollment greatly restricts the permissions that an MDM has when managing a device compared to previous enrollment modes. Below is a summary of the changes.
The MDM is no longer able to retrieve device-identifying information, such as a serial number, universal device identifier (UDID), IMEI, or mac addresses. Instead, the device provides an anonymized identifier that lives for the life of the MDM enrollment. If a device unenrolls and then re-enrolls at a later time, a new identifier is produced. This helps maintain the anonymity of the end user and their hardware.
The MDM is able to install and remove apps as it was able to before, however it can only see the apps that it is managing. Apps installed by the user will not be visible to the MDM, nor will the MDM be able to place any of these apps under management.
An app must either be installed and managed by User Enrollment or not. It cannot be both. Some native apps, such as Apple Notes, include User Enrollment-aware functionality, allowing them to include both managed business data and personal user data, separated within the app itself.
A narrow set of profiles will be supported, namely:
Profiles that restrict the user are largely not permitted. For instance, strict passcode requirements, configurations that proxy network traffic, and restrictions that block content are not allowed. Some restrictions, as they relate to enterprise features like Managed Open In are still supported.
User Enrollment removes an administrators ability to set or clear a passcode, wipe a device, and perform other device-level operations that encroach on an end user’s privacy and control of their own device.
User Enrollment relies upon and requires that a Managed Apple ID is associated with each enrolled device. This Managed Apple ID currently provides two functions:
The Managed Apple ID can be created manually by an administrator within Apple Business Manager. Apple also supports federation with Azure Active Directory, allowing Managed Apple IDs to be automatically created within Apple Business Manager when identities exist in Azure. The MDM is responsible for specifying the Managed Apple ID that a device is to use during the time of device enrollment.
Managed Apple IDs do not conflict with regular Apple IDs. A user may continue to use their personal Apple ID on a device even when a Managed Apple ID is also being used by the same device.
As both a security and privacy mechanism, a separate APFS volume is created during User Enrollment. An APFS volume, for the layperson, is essentially a virtual hard drive that has its own encryption and lives entirely separately of other volumes that host the OS or personal user data.
This volume is responsible for storing all User Enrollment-related data, such as:
If the device unenrolls from the MDM, this volume is deleted, removing all managed apps and managed data with it. The device is returned to its original state before enrollment occurred.
If employees are using their personal devices in your deployment, chances are that the answer is “yes”. Convincing employees in a BYOD scenario to grant your organization permission to see what apps they have installed, remove their passcode at any point, or wipe their device is a big ask and is unlikely to receive buy-in.
Outside of a BYOD scenario, User Enrollment doesn’t make a lot of sense. If a business owns the hardware being managed, it will likely want to retain the ability to unlock, track, and recover devices if need be. Enrolling using User Enrollment, if not immediately, will prove to be too restrictive down the road as additional business requirements develop.