Federation is the point where your people stop having an Apple credential. They sign in to an iPhone with the password they already use for everything else, and when you disable that account in Entra ID their Apple session dies with it. That is a genuine improvement in control, and getting there costs you three things nobody mentions until you hit them.
The relationship is worth stating precisely because it is routinely described backwards, including in at least one answer on Microsoft’s own community forum. Entra ID is the identity provider. Apple Business is the relying party. Apple’s own wording is that Microsoft Entra ID is the identity provider that authenticates the user for Apple Business and issues authentication tokens. You are not federating your domain in Entra ID and you are not making Apple an identity provider for anything. You are handing Apple a read-only window onto your directory and letting it defer authentication to you.
What you are actually consenting to
The consent prompt is the most important screen in this whole process and most administrators click through it. Apple asks for five things, and each one is worth understanding because together they define exactly how much of your directory Apple can see.
It asks to view basic profile, which carries the openid, profile and email scopes and gets Apple the identity claims in the token: issuer, audience, subject, tenant, object ID and user principal name. It asks to read domains, which is Domain.Read.All, so Apple can see which of your domains are verified. It asks to read directory data, Directory.Read.All, which is the one that carries the user objects and which Apple also reuses for directory sync rather than requesting a second grant. It asks to maintain access to data, offline_access, so it can refresh its token.
And it asks to read audit log data, AuditLog.Read.All, which is the interesting one because it is not obvious why an account service would need your audit log. Apple explains it, and the explanation is the security argument for federation in a single sentence. Apple retrieves security events that happened to user accounts in Entra ID so it can take appropriate measures for accounts signed in on Apple devices, and specifically: when a password is changed or invalidated by Entra ID, the Managed Apple Account session is terminated and challenged to reauthenticate. The filter Apple runs is on activity display names of ChangePassword or ResetPassword.
So Apple polls your audit log looking for password events and uses them as a kill signal. That is why a federated Apple estate reacts to a compromised credential, and an unfederated one does not.
At no time is any data written back to Microsoft Entra ID. Apple reads. It never writes.
That last sentence is Apple’s, verbatim, and it is the one to quote at whoever has to approve this. The integration is a read-only pull. Nothing Apple does can modify a user, a group or a setting in your tenant.
One practical consequence that gets missed: Global Administrator is required to establish the trust and is not required to keep it. Apple documents two supported downgrades afterwards, either to Global Reader, Application Administrator or Cloud Application Administrator, or to an account holding both Directory Reader and Reports Reader. The underlying permissions are narrow, being read on domains, read on users and read on audit logs. An organisation that leaves a standing Global Administrator attached to this integration has done so by omission rather than by requirement, and that is worth catching in a privileged access review.
Directory sync, and a widespread belief that is now wrong
Almost everything written about syncing users into Apple Business describes SCIM. You enable a sync in Apple, Apple hands you a tenant URL and a bearer token with a short expiry, you take those into the provisioning blade of an enterprise application in Entra ID, you map attributes, and you start provisioning. That is a real mechanism, it worked, and it is what the community has documented for years.
It is not what Apple documents for Entra ID today. The current path is OIDC, configured entirely on the Apple side, and the whole published procedure is two lines: go to Settings, then Domains, and under Directory Sync select Set up next to the Entra ID domain you want to sync. There is no token, no Entra-side configuration and no second credential, because the consent you granted during federation already carried Directory.Read.All and Apple reuses it. Apple says so in a note on the consent table.
I am going to be honest about the limits of my confidence here, because this is the one place in the identity story where I cannot tell you the whole answer. Apple still documents a token-based SCIM path for the generic identity provider option, complete with a four calendar day window to complete the token transfer. And a support thread from February 2026 shows an administrator using Entra-side provisioning vocabulary, with target IDs and skipped users, while the Apple side of the same tenant displayed Entra ID connected with Directory Sync. Whether both mechanisms are live in parallel, and what a tenant already running the SCIM path should do about it, is not documented anywhere I can find. If your tenant already provisions to Apple through the Entra provisioning blade, do not assume this article describes what you have.
What sync does is narrow and worth knowing before you plan around it. Accounts arrive with the role of Staff and their information is read-only in Apple Business, though you can still edit the role. Apple generates a Person ID on first sync to identify conflicting accounts, and editing that Person ID unpairs the account from your directory until somebody resolves the resulting Person ID conflict, which is a documented recovery rather than a dead end. When a user is removed in Entra ID the Apple account is deactivated and flagged for deletion, signed out of devices and unable to sign back in, and unless it syncs again within thirty days it is removed outright.
And the limitation that reshapes deployment plans: syncing user groups is not supported. Anyone intending to drive Apple Business roles or device assignment from Entra security groups needs a different plan, because the groups do not arrive.
The user principal name is the identity, and that is a trap
Apple maps userPrincipalName to both the Managed Apple Account and the email address. Not mail. Not the primary SMTP address. The UPN.
In a tenant where those agree, which is most greenfield tenants, nothing happens and you never think about it. In a tenant that grew out of an on-premises directory, where somebody’s UPN is still [email protected] or [email protected] while their mail is [email protected], the Managed Apple Account follows the UPN and the user gets an identity they do not recognise, on a domain that may not even be federated. This is the single most common preventable failure in an Apple federation, and it is preventable by reading two columns in your user list before you start.
Apple publishes three different attribute tables across its own federation and sync pages and they do not agree with each other, differing on whether display name is carried, whether object ID is required, and on the casing of half the field names. The three agree on the parts that matter, which are the two name fields and the UPN. I would not build anything on the optional rows until Apple reconciles them, and I would take seriously Apple’s warning that adding attributes outside its mapping can break the connection through token validation failures.
Three things that will stop you
Conflicts block everything, and they block it silently. Apple lists having no Managed Apple Account conflicts as a federation prerequisite. What is not documented, but is stated by a Microsoft moderator answering a case in February 2026, is the failure shape: with unresolved conflicts on the federated domain, no new Managed Apple Accounts are created at all, including for users who are not themselves conflicted, while provisioning cheerfully reports success. If you are looking at a green sync and an empty Apple Business, this is where to look first.
One identity provider, tenant-wide. Apple’s rule is that you can link to Google Workspace, Microsoft Entra ID, or your own provider, but only one at a time. Migrating between them is a disconnect and reconnect, which is precisely the operation Apple’s sync conflict article exists to clean up after.
And your Entra tenant cannot be shared with another Apple Business organisation. Apple states that to use OIDC your organisation cannot have the same Entra ID tenant as any other Apple Business organisation, and tells you to check with your Global Administrator that nobody else is using it. In a group of companies sharing one tenant across several legal entities, each with its own Apple Business organisation, this is a hard architectural constraint and it is better discovered now than in the middle of a rollout.
National clouds are out entirely. Apple supports the global service at login.microsoftonline.com and states that integration with national clouds is not currently supported, which removes GCC High, DoD and 21Vianet from this conversation altogether.
The administrators who cannot use what they built
I covered this in [AB 3] and it belongs here too, because this is where people meet it. Apple’s rule is that users with the role of Organization Administrator, or any custom role holding the permissions to configure federation and connect to an identity provider, cannot sign in using federated authentication and can only manage the federation process.
The practical effect is that you cannot test federation with your own account, and the single-user test step requires a real user who is not you. The strategic effect is better: your top ten accounts authenticate against Apple rather than against your tenant, so a broken Entra ID cannot lock you out of Apple Business. Treat them as break-glass accounts, because that is what Apple has made them.
There is a related failure with no error message at all, and it is worth carrying. If a synced user has a user principal name exactly matching an existing user who holds federation permissions, Apple performs no sync for that account and leaves the source field unchanged. Nothing fails. Nothing is logged for you. The account simply never arrives.
What turning it on does the moment you do it
One effect lands immediately and it is not announced on the screen where you flip the switch. Be careful about the other one people expect here: blocking the creation of new personal Apple accounts on the domain happens at the earlier approval step, not at turn-on. Apple places that note under approving federated authentication, which means the door closes when you first connect Entra ID rather than when you enable sign-in. It is also an effect the domain lock already gave you, which is one more reason locking early costs nothing.
What does land at turn-on is the rename. Existing Apple Business users whose email address sits in the federated domain have their Managed Apple Account automatically changed to match that address. Silently. Apple’s guidance elsewhere is explicit that users are not notified when their Managed Apple Account changes and that you need to notify them yourself. So the population to warn is not only the personal-account holders from the capture in the previous article, it is also your existing managed users, and nobody tells you which ones they are except your own user list.
One more thing Apple documents without giving you a number: the federation connection expires, and when it does, federation and user syncing stop until you reconnect. Apple does not publish the period. That is an operational dependency with no stated lifetime, which means the only sane response is to check it on a schedule rather than to wait for the day everybody’s iPhone stops signing in.
The build sheet takes this in Apple’s order, with a gate in front of each step that cannot be walked back.
Apple Business
‹ Previous: [AB 4.1] Build Sheet: Locking and Capturing a Domain
Next: [AB 5.1] Build Sheet: Federation and Directory Sync, End to End ›
