In What’s new in Apple device management and identity WWDC 25 session video, Apple has announced several improvements to Apple Business Manager and Apple School Manager. This article ignores ASM and focuses only on ABM, although most of the features are common for both.

ABM Customer API

The automation problem

It has been quite difficult to do any sort of granular automation with ABM.

For device assignments to MDM servers, admins have had the ability to automatically assign devices based on model family (Mac, iPhone, etc.). This works well in simple setups where all your Macs go to one MDM server. However, if you need to assign your iPhones to two different MDM servers, it would have to be done manually at least for some of them.

If all your purchased Apple devices are added to ABM, it becomes a very good source of inventory information since it has all the identifiers such as serial number, IMEI, MEID, and EID. MAC addresses for iPhone + iPad Wi-Fi and Bluetooth interfaces have just been announced 🥳. To import all of this to an inventory system, a CSV can be manually created. If you are lucky, your MDM vendor exposes ABM information through its API. If you are not lucky or some of your devices have to be in the “unassigned” state, you are back to manual CSV export.

The API solution

ABM is finally getting customer facing API. This has been a highly requested feature for a longtime in Apple admin community.

ABM user with Admin role will be able to issue API token which can then be used to interact with following endpoints:

List All Devices	GET /v1/orgDevices
Get Device Information	GET /v1/orgDevices/{id}
Get Device Management Service Information for a Device	GET /v1/orgDevices/{id}/relationships/assignedServer
List of Device Management Services	GET /v1/mdmServers
Get All Devices Assigned to Device Management Service	GET /v1/mdmServers/{id}/relationships/devices
Assign or Unassign Devices from Device Management Service	POST /v1/orgDeviceActivities
Get Batch Action Activity Status	GET /v1/orgDeviceActivities/{id}

Public API is now live! API token can be generated at https://business.apple.com/#/main/preferences/apiaccounts.

Update: Documentation can be found at https://developer.apple.com/documentation/applebusinessmanagerapi

Device management migration

Before device management migration

Imagine this situation: You have a couple of thousand Apple devices which are all enrolled to HappyOrg MDM solution via Automated Device Enrollment. Unfortunately, over the years, HappyOrg MDM turns into SadOrg MDM, and you finally decide to replace it with another solution, SuperOrg MDM. You integrate SuperOrg MDM with ABM, re-assign all the devices to it, and do the final step – unenroll all devices from SadOrg MDM. The question is what comes next.

On macOS 13 or earlier, “Device Enrollment” notification would appear from time to time.

Users can happily ignore this notification as long as they wish. To solve this problem admins would deploy some sort of persistent service with custom UI (LaunchAgent) which would nag the user more aggressively and run profiles renew -type enrollment behind the scenes with root privileges (LaunchDaemon) to force the notification to appear at the right time while hoping Do Not Disturb is not enabled . Plus these two components would need to talk to each other somehow possibly via XPC.

Of course I had to create such tool because we needed to switch enrollments just a few months before macOS 14 release 🙃.

On macOS 14 and 15, the notification is replaced by a full-screen Setup Assistant experience. Users can click on “Not now,” which defers the process by 8 hours. Then it becomes unskippable.

No need to create a custom UI, just call profiles renew -type enrollment. On macOS 15, root privileges are not even required for that.

On iOS, nothing would happen. Well.. unless you wipe the device instead of unenrollment to force regular ADE 🤡. Since you don’t want to be overly mean, it is probably better to ask your users to do the classic Device Enrollment, which is very obnoxious nowadays, and then keep track of who enrolled and who hasn’t to nudge the right people to do it.

After device management migration

This will only apply to macOS 26 and iOS 26 of course. Admins will set an enrollment deadline during MDM server re-assignment in ABM. It looks like no unenrollment from MDM server itself will be needed.

User will receive a notification letting them know they need to migrate and when the deadline is.

Migration happens in fullscreen Setup Assistant experience.

Managed apps installed by the previous MDM and their data can be preserved if the new MDM server utilizes await device configured feature and initiates app installation before release the device from the await state by sending DeviceConfigured MDM command.

It’s not clear yet whether iOS devices remain in supervised mode after re-enrollment. One would assume so but let’s wait until we can test it the process for real.

Grab bag

Enforce Managed Apple Account sign-in

ABM is getting an ability to limit sign-in to Apple Accounts on company-owned devices only to Managed Apple Accounts. This feature currently works as a single global switch with no dependency on MDM. If you need this to be more granular, make sure to submit feedback to Apple.

Learn which Personal Apple Accounts use the company domain

When initiating the capture process on a company domain in ABM in order to use it only for Managed Apple Accounts, you can see how many Personal Apple Accounts use the domain in their account username. Apple will finally provide an ability to download a list of all these usernames. This will help tremendously with user comms since organizations will be able to target it only on users who actually use the company domain for their PAA.

Update 2025-06-13: Unfortunately there is a fine print. This feature will apply only to a subset of Personal Apple Accounts which has signed into services such as Apple Developer Portal, AppleCare Enterprise Portal and Apple Push Notification services portal. With this limitation the usefulness of this feature is drastically reduced.

Custom URL for account driven enrollment

Account driven enrollments have relied on existence of https://companydomain.tld/.well-known/com.apple.remotemanagement resource. For some reason Apple has not implemented DNS-based verification for this flow. Verification via file served by a web server has proved to be challenge for certain organizations where device management people are just siloed too far way from people running the company main website.

To bypass this problem Account-driven enrollments will be able to use custom service discovery URL provided by MDM server.

Granular privileges for the Device Enrollment Manager role

Follow capabilities can be turned of for Device Enrollment Manager role:

• Add and remove device management services <- This one I like a lot 🥳
• Assign devices
• Remove Activation Lock from organization-owned devices
• Release devices from organization

Warranty information

ABM will now display AppleCare information in device details for applicable devices.

Developer services for Managed Apple Accounts

Managed Apple Accounts work for developer services like notarization, including command-line tools like notarytool and stapler, and app-specific passwords.

Previously admin would have to use App Store Connect API key in order to access notarization services.