Apple Business Manager decides which device management service every company-owned Apple device trusts, who your Managed Apple Accounts are, and who can release a device from your organisation for good, yet it is often run by one person with a shared login. Apple has renamed the service: its user guide now states that Apple Business Manager is now Apple Business, combining the capabilities previously found in Apple Business Manager, Apple Business Essentials and Apple Business Connect. Most administrators and search results still use the old name, so this guide uses both; settings and limits below come from the current Apple Business user guide, checked on 8 November 2026. It covers roles and organisational units, federation and Managed Apple Accounts, device management service tokens, the API, activity logging and a hardening baseline. It is for Apple endpoint administrators, identity engineers and security teams. The general case for treating device management as tier zero is in the Mobile Device Management Security Guide; this page is the Apple Business layer that sits above your device management service.
This is an independent guide from NHI Mgmt Group, based on Apple's public documentation as of November 2026. It is not sponsored or reviewed by Apple. Product features change, so confirm settings against Apple's current documentation.
Key takeaways
- Apple Business is the root of device trust. It assigns serial numbers to a device management service, and Automated Device Enrollment then supervises the device and can make enrolment non-removable.
- Federation does not cover your most powerful users. Organization Administrators, and any role that can set up federation, cannot sign in with federated authentication, so their Managed Apple Account passwords and recovery need their own care.
- Use custom roles. Up to 10 people can hold Organization Administrator; most work fits IT Administrator, Device Enrollment Manager or one of up to 15 custom roles scoped to organisational units.
- Service tokens and API keys are long-lived secrets. Device management service tokens expire after one year and must be replaced when the downloading user leaves or changes password; API private keys are generated once and must be vaulted.
- Release is near permanent. Releasing a device ends your ability to manage it or its Activation Lock through Apple Business, so restrict who and what can do it, including linked management services.
How identity and access work in Apple Business Manager
Every person who signs in to Apple Business uses a Managed Apple Account: an account the organisation creates, owns and manages, separate from personal Apple Accounts. Accounts can be created manually, through federated authentication, or by directory sync from Google Workspace, Microsoft Entra ID or another identity provider. Each Managed Apple Account must be unique and cannot match an Apple Account another person already holds. Managed Apple Accounts give access to iCloud, device continuity, business services, Apple Developer programmes and collaboration services, so they are both an admin identity and a user identity.
Federation and directory sync
- Supported providers: Google Workspace; Microsoft Entra ID global service (login.microsoftonline.com) over OpenID Connect, with national clouds not supported; or any other identity provider that supports OIDC or SCIM. Only one provider can be linked at a time.
- Domain prerequisites: the domain must be verified, locked, and have domain capture turned on before an identity provider is linked, with no Managed Apple Account conflicts.
- Signals: connecting an identity provider uses an OIDC sign-in method with the ssf.manage and ssf.read scopes and the identity provider's Shared Signals Framework and OpenID configuration URLs.
- Account creation: once federated, Managed Apple Accounts are created on sign-in with the user's existing username and password; existing users in the federated domain have their account changed to match.
- Directory sync: synced accounts are read-only until sync is turned off, when they become editable manual accounts. Accounts removed at the source can be removed from Apple Business, which is what makes offboarding work.
- Naming rules: Google Workspace requires the email address as username with no aliases; Entra ID requires the userPrincipalName to match the email address, without UPN aliases or Alternate IDs.
- Approval: approving federation in Entra ID needs a Global Administrator account; Apple notes the role can be changed afterwards, so do so.
- Expiry: if the identity provider connection expires, federation and account sync stop until reconnected. Monitor it.
Federation brings your identity provider's MFA, Conditional Access and joiner, mover and leaver process to most Apple Business users. It is the single biggest improvement for most tenants. The SCIM Provisioning Guide covers the sync mechanics and the Federation and Trust Relationships Guide the trust you create.
Passwords and lockout for non-federated accounts
Accounts that cannot federate, including every Organization Administrator, rely on Apple Business passwords and verification phone numbers. Apple documents that a user is locked out after more than 10 incorrect password attempts or when Apple suspects fraud; a user with the right role can reset a password, but an account locked for suspected fraud must be unlocked by an Organization Administrator working with Apple. Two practical consequences: you need more than one Organization Administrator so a lockout does not strand the tenant, and verification phone numbers on admin accounts must be organisation-controlled, not a departed employee's mobile.
Admin roles and privileged access
Apple Business has predefined roles and custom roles, and every user must have at least one role. Organisational units (OUs) set scope: a role assigned in the initial organisation applies to all OUs, while a role assigned in an additional OU applies only there and cannot change the initial organisation.
| Role | Type | What it controls | Security note |
|---|---|---|---|
| Organization Administrator | Predefined | Any feature in any OU; manages all other roles | Maximum 10 holders; cannot sign in with federation |
| IT Administrator | Predefined | IT functions; manages other IT Administrators, Staff and custom roles | Day-to-day admin role for most IT staff |
| Marketing Administrator, Ads Administrator | Predefined | Marketing and advertising features | Cannot manage other roles; keep separate from device administration |
| Staff | Predefined | Beta software, programme resources, feedback, FaceTime and iMessage | Default for ordinary users |
| Device Enrollment Manager | Custom (provided) | Devices and device management services | Can reassign devices between services; treat as privileged |
| People Manager, Content Manager | Custom (provided) | Users and content in specific OUs; app and book licences | Scope to the OU that needs it |
| Device API Manager | Custom (migration only) | Appears when an organisation with existing API accounts moves to Apple Business | Review its holders after migration |
| Your own roles | Custom | Up to 15, built from Organization, People, Devices, Apps & Services and Brands permissions | Build narrow roles such as a device configuration role |
Users who can view, edit and delete roles can change the permissions of default roles after verification, and the change applies to every holder, so restrict that permission to Organization Administrators. Aim for two or three Organization Administrators (enough to survive a lockout, well under the limit of 10), put device staff in IT Administrator or Device Enrollment Manager, and use OU-scoped custom roles for regional teams. Because Organization Administrators sign in with Apple Business credentials rather than your identity provider, give them dedicated admin Managed Apple Accounts that are not used for iCloud or daily work. See the Break-Glass Account Guide for how to hold and test them.
Integrations, API tokens and service accounts
Device management services and enrolment
Linking an external device management service is done at Devices > Management Services by a user whose role can view, add and delete services. You upload the service's public key certificate, download a service token and upload it to the service. Apple documents that service tokens expire after one year, and that a token should be replaced when a new public key or token is generated, when the user who downloaded it changes their Managed Apple Account password, or, as a security measure, when that user leaves the organisation. Each service also has a Release Devices option: leave it cleared unless the service genuinely needs it, because a compromised management service could otherwise release your devices.
| Enrolment method | Ownership | Supervision | Security implication |
|---|---|---|---|
| Automated Device Enrollment | Organisation-owned, new or erased | Supervised | Strongest control; enrolment can be made non-removable and devices held in Setup Assistant until critical configuration is applied |
| Account-driven Device Enrollment | Organisation-owned, already in use | Mac supervised; iPhone, iPad and Apple Vision Pro not | Removing the profile removes organisational data |
| Account-driven User Enrollment | Personally owned (BYOD) | Unsupervised | Limited to Managed Apple Account and managed apps; data separation for privacy |
Devices enter Apple Business when you link your Apple Customer Number or reseller number, or are added with Apple Configurator. Apple's deployment guide states that with Automated Device Enrollment you can prevent users removing the enrolment profile, and on Mac this also blocks removal through System Settings and the profiles command. Where device subscriptions need approval, Apple advises checking enrolment details including the SHA-256 certificate fingerprint before approving. See the Apple Declarative Device Management and Managed Device Attestation Guide for the configuration layer that follows enrolment.
Apple Business API accounts
Only an Organization Administrator can create an API account, and an organisation can have up to 50. Authentication uses OAuth 2: the client presents its credentials and receives an access token. The private key is a .pem file generated once. Permissions are chosen per area: devices and device management services (including assign, unassign and release, migrations and Activation Lock status), users and groups, Blueprints and configurations, packages and apps, and audit events. Apple's page does not document key expiry or rotation, so set your own rotation schedule and revoke accounts you no longer use.
| Credential | Lifetime | Blast radius if stolen | Control |
|---|---|---|---|
| Device management service token | One year | Lets an attacker's server impersonate your service for assigned devices | Store in vault, replace on staff change, calendar the renewal |
| API account private key (.pem) | Not documented by Apple | Whatever permissions the API account holds, possibly release | Least permissions, vault, rotate, owner per account |
| Organization Administrator password | Until changed | Full tenant, including new API accounts | Dedicated accounts, organisation-controlled verification numbers |
| Identity provider federation connection | Until expiry | Account creation and sign-in for the domain | Monitor expiry, restrict who can change federation |
Grant API accounts read-only permissions unless a workflow needs to assign devices, and avoid the release permission entirely for automation. The API Key Management Guide covers storage and rotation patterns.
Logging and detection
The Activity Center (Settings > Activity Center) lists sign-in creation, account updates, deletion, deactivation and federation, federation disabled, role assignment, verification code creation, device assign, unassign and release, server deletion and reassignment, domain collision scans, SCIM provisioning and deprovisioning, and Shared iPad passcodes. You can filter by activity, status and time window (last hour, 24 hours, 7 days or 30 days) and download a log file for each activity. Apple does not state a retention period, so export what you need. API accounts can be given permission to access audit events, which is the route to automated collection.
| Detection | Signal | Why it matters |
|---|---|---|
| Role assignment to Organization Administrator or a device role | Activity: assign roles | Persistence and escalation (ATT&CK T1098) |
| Device released or bulk unassigned | Activity: release devices, unassign devices | Loss of control over hardware |
| Management service deleted or devices reassigned | Activity: delete server, reassign | Devices pointed at a different service |
| Federation disabled or account disconnected from source | Activity: federation disabled, disconnect from source | Removes identity provider controls |
| New verification codes created for admins | Activity: create new verification codes | Possible account takeover step |
| New API account | Organization Administrator activity and API audit events | New machine path into the tenant (T1528) |
Measures: number of Organization Administrators (target two or three), percentage of users federated, days until each service token expires, API accounts with a named owner and last review date, and released devices that match a disposal record.
Hardening baseline
- Inventory: list every user with a role, every API account, every device management service and its token expiry, and the current verified domains.
- Verify and lock domains: verify, lock and turn on domain capture so personal accounts cannot sit on your domain.
- Federate: connect your identity provider in a pilot OU first, confirm sign-in and MFA, then extend. Keep Organization Administrators on dedicated non-federated accounts.
- Cut privilege: reduce Organization Administrators to two or three; move others to IT Administrator, Device Enrollment Manager or custom roles scoped to OUs.
- Protect release: clear Release Devices on every linked management service that does not need it and remove release from API accounts.
- Tokens and keys: move service tokens and .pem files into a vault, set renewal reminders well before the one-year expiry, and replace tokens downloaded by people who have left.
- Enrolment: use Automated Device Enrollment for organisation-owned devices, make enrolment non-removable and hold devices in Setup Assistant until critical configuration lands.
- Logging: export Activity Center logs on a schedule or collect audit events by API into the SIEM.
Rollback: federation can be disconnected from a domain, and synced accounts become editable when sync is turned off. Test both in a pilot before production, and make sure at least two Organization Administrators can sign in before changing anything about federation.
Common misconfigurations
- One shared administrator login: no accountability and, after a fraud lockout, no second Organization Administrator to work with Apple.
- Service token downloaded by a leaver: the token keeps working until expiry unless replaced, contrary to Apple's advice.
- Release Devices left on for every service: a compromised management service can push devices out of the organisation.
- Organization Administrator used for daily work: the most powerful accounts are the ones that bypass your identity provider.
- Federation left on a stale connection: account sync stops when the connection expires, so leavers keep access.
- Devices released before repair: Apple warns not to release devices sent to Apple for repair, because a replacement will not appear in Apple Business.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Federation and account lifecycle | AC-2, IA-2(1) | PR.AA-05 |
| Roles and OU scoping | AC-6, AC-6(5) | PR.AA-05 |
| Service tokens and API keys | IA-5 | PR.AA-05 |
| Enrolment and device inventory | CM-8, CM-6 | ID.AM-02, PR.PS-01 |
| Activity logging and review | AU-6 | DE.CM-03 |
| Dependence on the Apple service | SA-9 | GV.SC-07 |
Practitioner checklist
- Verify and lock every company domain and turn on domain capture.
- Federate with your identity provider and monitor the connection for expiry.
- Keep two or three Organization Administrators on dedicated accounts with organisation-controlled verification numbers.
- Scope everyone else with IT Administrator, Device Enrollment Manager or OU-scoped custom roles.
- Clear Release Devices on linked management services and in API account permissions unless required.
- Vault service tokens and API keys, renew before the one-year expiry and replace on staff change.
- Use Automated Device Enrollment with non-removable enrolment for organisation-owned devices.
- Export Activity Center logs or collect audit events into the SIEM and alert on role, release and federation changes.
Standards and references
- Apple: Apple Business User Guide, Intro to roles and permissions
- Apple: Apple Business User Guide, Intro to federated authentication
- Apple: Apple Business User Guide, Intro to Managed Apple Accounts
- Apple: Link to an external device management service
- Apple: Create an Apple Business API account
- Apple: View activity
- Apple: Release devices
- Apple: Platform Deployment, Automated Device Enrollment and device management
Related NHI Mgmt Group resources: Mobile Device Management Security Guide · Apple Declarative Device Management and Managed Device Attestation Guide · Apple Platform Security Explained · SCIM Provisioning Guide