Last updated May 27, 2020
At the Apple Worldwide Developer Conference (WWDC) this year, Apple announced “User Enrollment”, a new mode of device 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 Apple DEP, User Approved (UAMDM), or Supervised mode. 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. An MDM administrator can wipe, lock, and heavily restrict access on a DEP enrolled and supervised device. 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 MDM controlling the device, the MDM has permission to operate in a confined space on the device. This effectively provides 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.
Compared to previous enrollment modes, User Enrollment greatly restricts the permissions that an MDM has when managing a device. 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 produces. This helps maintain the anonymity of the end-user and their hardware.
As before, the MDM installs and removes apps; however, it only sees 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.
User Enrollment manages an app for it does not. It cannot be both. Some native apps, such as Apple Notes, include User Enrollment-aware functionality. This allows both managed business data and personal user data, separated within the app itself.
Profiles supported include:
Profiles that restrict the user are largely not permitted. 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 administrator’s 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. When an identity exists in Azure, Managed Apple IDs are automatically created within Apple Business Manager. 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 personal Apple ID remains active on a device that also has a Managed Apple ID in use.
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 with its own encryption and lives entirely separately of other volumes that host the OS or personal user data.
This volume stores all User Enrollment-related data, including:
When a device unenrolls from the MDM, this volume deletes, removing all managed apps and managed data with it. The device returns 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.