Account-driven enrollment methods with Apple devices
Account-driven User Enrollment and account-driven Device Enrollment provide a seamless, secure way for users and organizations to set up Apple devices for work by signing in with a Managed Apple Account.
This approach allows both a Managed Apple Account and a personal Apple Account to be signed in on the same device, with complete separation of work and personal data. Users maintain privacy over their personal information, and IT supports work-related apps, settings, and accounts.
To support this separation, the following changes have been made to the way apps and backups are handled:
All configurations and settings are removed when the enrollment profile is removed.
Managed Apps are always removed during unenrollment.
Apps installed before enrolling in a mobile device management (MDM) solution can’t be converted to become Managed Apps.
Restoring from a backup doesn’t restore MDM enrollment.
Users who sign in with their personal Apple Account can’t accept an invitation for Managed App distribution.
Although Managed Apple Accounts can be created manually, organizations can take advantage of integrating with an IdP, Google Workspace, or Microsoft Entra ID.
For more information on federated authentication, see Intro to federated authentication with Apple School Manager or Intro to federated authentication with Apple Business Manager.
Account-driven enrollment process
To enroll a device using account-driven User Enrollment or account-driven Device Enrollment, the user navigates to Settings > General > VPN & Device Management or to System Settings > General > Device Management and selects the Sign In to Work or School Account button.
This initiates a four-stage process to enroll into MDM:
Service discovery: The device determines the enrollment URL of the MDM solution.
Authentication and access token: The user provides credentials to authorize the enrollment and get an access token issued for ongoing authentication.
MDM enrollment: The enrollment profile is sent to the device and the user is required to sign in with their Managed Apple Account to complete the enrollment.
Ongoing authentication: The MDM solution verifies the signed-in user on an ongoing basis using the access token.
Stage 1: Service discovery
In the first step, service discovery tries to identify the MDM solution’s enrollment URL. To do so, it uses the identifier entered by the user, for example eliza@betterbag.com. The domain must be a fully qualified domain name (FQDN) that advertises the MDM service for the user’s organization.
The following then takes place:
Step 1
The device identifies the domain in the supplied identifier (in the above example, betterbag.com).
Step 2
The device requests the well-known resource from the organization’s domain—for example, https://<domain>/.well-known/com.apple.remotemanagement.
The client includes two query parameters in the URL path of the HTTP GET request:
user-identifier: The value of the entered account identifier (in the above example, eliza@betterbag.com).
model-family: The device’s model family (for example, iPhone, iPad, Mac).
Note: The device follows HTTP 3xx redirect requests, which allows the actual com.apple.remotemanagement file to be hosted on another server reachable by the device.
For devices with iOS 18.2, iPadOS 18.2, macOS 15.2, visionOS 2.2, or later, the service discovery process allows a device to fetch the well-known resource from an alternative location specified by the MDM solution linked to Apple School Manager or Apple Business Manager. The first preference for service discovery is still the well-known resource at the organization’s domain. In the event that the request fails, the device proceeds to check with Apple School Manager or Apple Business Manager for an alternate location of the well-known resource. This process requires the domain used in the identifier to be verified in Apple School Manager or Apple Business Manager. For more information, see Add and verify a domain in Apple School Manager or Add and verify a domain in Apple Business Manager.
To use this capability, the alternative service discovery URL must be configured by the MDM solution linked to Apple Business Manager and Apple School Manager. When the device reaches out to Apple School Manager or Apple Business Manager, the device type is used to determine the assigned MDM solution for that type—the same process to determine the default MDM solution for Automated Device Enrollment. If the assigned MDM solution has configured a service discovery URL, the device proceeds to request the well-known resource from that location. To set the default device assignment, see Set the default device assignment in Apple School Manager or Set the default device assignment in Apple Business Manager.
The MDM solution can also host the well-known resource.
Step 3
The server hosting the well-known resource, responds with a service discovery JSON document that conforms to the following schema:
{ "Servers": [ { "Version": "<Version>", "BaseURL": "<BaseURL>" } ]}The MDM enrollment keys, types, and descriptions are in the following table. All keys are required.
Key | Type | Description |
|---|---|---|
Servers | Array | A list with a single entry. |
Version | String | This key determines the enrollment method to use and must be either |
BaseURL | String | The enrollment URL of the MDM solution. |
Important: The server must ensure that the Content-Type header field in the HTTP response is set to application/json.
Step 4
The device sends an HTTP POST request to the enrollment URL specified by the BaseURL.
Stage 2: Authentication and access token
To authorize the enrollment, the user needs to authenticate with the MDM solution. After successful authentication, the MDM solution issues an access token to the device. The device securely stores the token for use when authorizing subsequent requests.
The access token:
Is central to both the initial authentication process and ongoing access to MDM resources
Serves as a secure bridge between the user’s Managed Apple Account and the MDM solution
Is used to allow continuous access to work resources for all account-driven enrollments
On iPhone, iPad, and Apple Vision Pro, the initial and ongoing authentication process can be streamlined by using Enrollment SSO (Enrollment Single Sign-on) to reduce repeated authentication prompts. For more information, see Enrollment Single Sign-on for iPhone, iPad, and Apple Vision Pro.
Stage 3: MDM enrollment
Using the access token, the device can authenticate with the MDM solution and access the MDM enrollment profile. This profile contains all information needed by the device to perform the enrollment. To complete the enrollment, the user must successfully sign in with their Managed Apple Account. After the enrollment is complete, the Managed Apple Account is displayed prominently within Settings and System Settings.
For more information what iCloud services are available to users, see Access iCloud services.
Stage 4: Ongoing authentication
After the enrollment, the access token remains active and is included in all request to the MDM solution using the Authorization HTTP header. This allows the MDM solution to continuously verify the user and helps to ensure that only authorized users retain access to organizational resources.
Access tokens typically expire after a set period. When this happens, the device may prompt the user to reauthenticate to renew the access token. Periodic revalidation helps to upload security, which is important for both personal and organization-owned devices. With Enrollment SSO, token renewal happens automatically through the organization’s identity provider, ensuring uninterrupted access without authenticating again.
How user data is separated from organization data with account-driven enrollment methods
When account-driven User Enrollment or account-driven Device Enrollment is complete, separate encryption keys are automatically created on the device. If the device gets unenrolled by the user or remotely using MDM, those encryption keys are securely destroyed. The keys are being used to cryptographically separate the managed data listed in this table.
Content | Minimum supported operating system versions | Description | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Managed app data containers | iOS 15 iPadOS 15 macOS 14 visionOS 1.1 | Managed Apps use the Managed Apple Account associated with the MDM enrollment for iCloud data synchronization. This includes Managed Apps (installed with the | |||||||||
Calendar app | iOS 16 iPadOS 16.1 macOS 13 visionOS 1.1 | Events are separate. | |||||||||
Keychain items | iOS 15 iPadOS 15 macOS 14 visionOS 1.1 | The third-party Mac app must use the Data Protection Keychain API. For more information, see the Global Variable kSecUseDataProtectionKeychain on the Apple Developer website. | |||||||||
Mail app | iOS 15 iPadOS 15 macOS 14 visionOS 1.1 | Mail attachments and body of the mail message are separate. | |||||||||
Notes app | iOS 15 iPadOS 15 macOS 14 visionOS 1.1 | Notes are separate. | |||||||||
Reminders app | iOS 17 iPadOS 17 macOS 14 visionOS 1.1 | Reminders are separate. | |||||||||
On iPhone, iPad, and Apple Vision Pro, Managed Apps and managed web-based documents all have access to the organization’s iCloud Drive (which appears separately in the Files app after a user signs in with their Managed Apple Account). The MDM administrator can help keep specific personal and organizational documents separate by using specific restrictions. For more information, see Managed App restrictions and capabilities.
If a user is signed in with a personal Apple Account and Managed Apple Account, Sign in with Apple automatically uses the Managed Apple Account for Managed Apps and the personal Apple Account for unmanaged apps. When using a sign-in flow in Safari or SafariWebView within a Managed App, the user can select and enter their Managed Apple Account to associate the sign-in with their work or school account.
