Account-driven enrolment methods with Apple devices
Account-driven User Enrolment and account-driven Device Enrolment provide a seamless, secure way for users and organisations 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 enrolment profile is removed.
Managed Apps are always removed during unenrolment.
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 enrolment.
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, organisations 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 enrolment process
To enrol a device using account-driven User Enrolment or account-driven Device Enrolment, the user navigates to Settings > General > VPN & Device Management, or System Settings > General > Device Management, and selects the Sign In to Work or School Account button.
This initiates a four-stage process to enrol into MDM:
Service discovery: The device determines the enrolment URL of the MDM solution.
Authentication and access token: The user provides credentials to authorise the enrolment and get an access token issued for ongoing authentication.
MDM enrolment: The enrolment profile is sent to the device and the user is required to sign in with their Managed Apple Account to complete the enrolment.
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 enrolment 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 organisation.
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 organisation’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 or 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 organisation’s domain. In the event that the request fails, the device proceeds to check with Apple School Manager or Apple Business Manager for an alternative 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 Enrolment. 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 enrolment 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 enrolment method to use and must be either |
BaseURL | String | The enrolment 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 enrolment URL specified by the BaseURL.
Stage 2: Authentication and access token
To authorise the enrolment, 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 authorising 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 enrolments
On iPhone, iPad and Apple Vision Pro, the initial and ongoing authentication process can be streamlined by using Enrolment SSO (Enrolment Single Sign-on) to reduce repeated authentication prompts. For more information, see Enrolment Single Sign-on for iPhone, iPad and Apple Vision Pro.
Stage 3: MDM enrolment
Using the access token, the device can authenticate with the MDM solution and access the MDM enrolment profile. This profile contains all information needed by the device to perform the enrolment. To complete the enrolment, the user must successfully sign in with their Managed Apple Account. After the enrolment is complete, the Managed Apple Account is displayed prominently within Settings and System Settings.
For more information on what iCloud services are available to users, see Access iCloud services.
Stage 4: Ongoing authentication
After the enrolment, the access token remains active and is included in all request to the MDM solution using the Authorisation HTTP header. This allows the MDM solution to continuously verify the user and helps ensure that only authorised users retain access to organisational 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 organisation-owned devices. With Enrolment SSO, token renewal happens automatically through the organisation’s identity provider, ensuring uninterrupted access without authenticating again.
How user data is separated from organisation data with account-driven enrolment methods
When account-driven User Enrolment or account-driven Device Enrolment 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 enrolment for iCloud data synchronisation. 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 organisation’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 organisational 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.
