There is a button in Apple Business that emails several hundred of your employees, gives them thirty days to do something about their personal Apple account, and cannot be un-pressed. Apple will not tell you which employees. This article is about deciding whether to press it, and the next one is about finding the people first.
Identity is where Apple Business stops being an inventory system and starts being an authority. The device half of the product is mostly bookkeeping: serial numbers arrive, you assign them somewhere, they enrol. The identity half asks a harder question, which is whether the accounts your people use on Apple hardware belong to them or to you, and the mechanism Apple provides for changing that answer is blunt, public and one way.
I have watched this go badly more than once, and the pattern is always the same. An organisation verifies its domain because verification is a prerequisite for something else it wants, notices a control that appears to tidy up all those personal Apple accounts on company addresses, and uses it on a Tuesday afternoon. On Wednesday the service desk takes ninety calls from people who received an email from Apple that reads like a phishing attempt and tells them their account is being taken over.
What a Managed Apple Account is, and what it costs the user
A Managed Apple Account is an Apple account your organisation owns, creates and can delete, as against a personal Apple Account which belongs to the human using it. Apple’s framing is that they exist to keep organisational data separate from the personal data users create with their own accounts, and that separation is the entire point. It is also what makes them worth having: a managed account can be provisioned from your directory, its session can be killed when you kill the user’s password, and it goes away when the person leaves.
The costs are real and worth stating plainly rather than discovering. Apple does enumerate them, on its service access page, under a heading asking what Managed Apple Accounts cannot access. The list is worth reading before you promise anybody anything: the iCloud+ services including Private Relay, Hide My Email and Custom Email Domain, iCloud Family Sharing, iCloud Mail, iCloud for Windows, and media services and store content. The services Apple names as working are the ones an organisation actually cares about: iCloud Drive, iCloud Keychain, contacts, calendars, reminders, notes and iCloud Backup. Access to some services is capped at ten devices on the same account. And every managed account must be unique, cannot duplicate an existing Apple Account, and an address that belonged to a personal account deleted through Apple’s formal deletion request process cannot be reused as a managed one for six years.
That six year rule is the sort of constraint that looks like trivia until it is load bearing. It means an address you free up today is not necessarily an address you can use tomorrow, and it means the tidy mental model of deleting an account and recreating it does not survive contact with the product.
Three stages of authority over a domain
Apple gives you a domain in three escalating stages and the escalation matters, because each one is quieter or louder than administrators expect.
Verifying proves you control the domain. It is silent as far as your users are concerned. The only email is to you, confirming the domain is being verified. After it succeeds Apple begins scanning daily for personal Apple accounts using your domain and shows you a count of them in the domain details.
Locking stops the bleeding. Once a domain is locked, only Managed Apple Accounts can be created on it, and existing personal accounts created before the lock remain untouched. This is also silent. It is the single most under-used control in Apple Business, and it is the one I recommend organisations turn on early and think about later, because it costs nothing, notifies nobody, and stops the problem growing while you decide what to do about the accounts that already exist.
Capturing is the loud one. It notifies every person holding a personal Apple account on your domain and gives them thirty days to act. Apple’s own warning appears twice on one page and says that turning on Domain Capture cannot be undone, and that sending notifications impacts all users with unmanaged Apple accounts across the domain you capture.
Lock early. It is silent, it is free, and it stops the problem growing while you decide what to do about it.
The thing to understand about the third stage is that it is no longer optional if you want single sign-on. Apple states that if your goal is federated authentication, and optionally directory syncing, you need to first lock the domain and then begin the domain capture process. The federation requirements page repeats it as a prerequisite. So an organisation that set out to give its people one credential for Apple devices discovers that the road there runs through a mass notification to its entire staff. That is a communications project wearing an identity project’s clothes, and it should be resourced accordingly.
What actually happens to the user
The person on the other end of this is not an administrator and did nothing wrong. They created an Apple account with their work email address, probably years ago, probably to download something, and it has since accumulated purchases, photos, a phone and a watch. What arrives is an email, plus an on-device notification if they are on iOS 18, iPadOS 18, macOS 15.1, visionOS 2 or later, telling them their account is affected and offering two choices.
They can choose a new primary email address and keep the account as their own. Or they can transfer the account and its data to your organisation, which converts it into a Managed Apple Account. For most people in most organisations the first is the right answer and the second is a trap, because transferring hands you their personal purchase history and photo library along with everything else, and hands them a permanent dependency on an employer they will one day leave.
For a large minority the choice is not offered at all, and your service desk should know that before the calls start. Apple documents a substantial class of accounts that cannot be transferred and are shown only the rename: anything using iCloud Mail, iCloud+, Family Sharing, Sign in with Apple, a Recovery Key, a Security Key, Advanced Data Protection, Apple Card or Apple Savings, plus accounts with a Legacy Contact, child accounts, and accounts with outstanding pre-orders. Apple separately notes that Find My is unavailable to Managed Accounts and that AirTags and AirPods should be removed before a transfer. Since the rename is the right answer for most people anyway, the useful framing is that transfer is the exception rather than the default, and its absence is normal rather than a fault.
Apple notifies four times: day one, day twenty-one, day twenty-seven, and once more after the primary address actually changes. Read that carefully, because it is three pushes inside the window and one confirmation afterwards, not four reminders. The gap between day one and day twenty-one is where your service desk load lives, and it is also where almost nothing happens, because people who ignore an email on day one ignore it for three weeks.
If they do nothing, once the thirty days elapse the account does not become yours. It remains a personal Apple Account and is renamed to a temporary address in the form of the local part, a hyphen, the domain, and then @temporary.appleaccount.com. Their address is released for you to use. This is the outcome people misunderstand most often, and it cuts both ways: the user has not lost their account, their photos or their purchases, and you have not gained an account, only an address.
There is also a population who get an email and need do nothing at all. Apple notifies anyone holding your domain as a verified secondary address on some other personal account, and those addresses are simply removed after the transfer period. They will still call your service desk, and from a mail log you cannot tell them apart from the people who genuinely need to act.
The part Apple does not help with
Here is the sentence that defines this whole exercise, verbatim from Apple’s own guidance on reviewing your domain before capture: “Apple doesn’t provide any details about these accounts.”
You get a number. An organisation that has let people create personal Apple accounts on its domain for ten years gets a number in the hundreds and no names. Apple’s position is defensible, because these are personal accounts belonging to individuals and Apple is not in the business of handing an employer a list of its employees’ private account holdings. It is also, operationally, an instruction to notify several hundred people about something without being told who they are.
Since July 2025 there has been a partial answer. Apple will generate a downloadable list of account names on your verified domain. It is genuinely useful and it is not the list you want, because Apple states it only includes users who have recently signed in to Apple web services such as the Apple Developer Program, the AppleCare Enterprise Portal or the Apple Push Notification Certificate portal. In other words it enumerates the people who touched Apple’s business-facing web properties, not the people who own an Apple account. One practitioner who ran a capture in early 2026 reported a list of eighty-nine accounts against more than four hundred actual migrations. Treat the list as a floor, never as a roster.
Which leaves you doing what competent administrators have always done here, which is to find the population from your own systems rather than Apple’s. Apple has been emailing these people for years about password resets, receipts and sign-in codes, and all of that mail landed in mailboxes you control. Your mail platform knows who has an Apple account on your domain even though Apple will not say. Turning that observation into a defensible pre-flight list is the substance of [AB 4.1], and it is the reason that build sheet is longer than the one that creates the organisation.
It will not find everyone, and the article says so rather than pretending. A former employee whose mailbox was deleted, who never added a secondary address to their Apple account and whose devices are too old for the on-device notification, receives nothing, learns nothing, and discovers on day thirty-one that their account has a new name. That person exists in most estates of any age. The honest control is to size that gap rather than to claim it away.
If you did this before, some of what you know has changed
Anyone who ran this in the older Apple Business Manager remembers it differently, and their memory is not faulty. In the pre-2024 product the notification was not a separate step at all. It fired off the federation path: you verified and federated a domain, Apple found the conflicting accounts, and an administrator pressed a control to send notifications from an activity view. The window was sixty days rather than thirty, the user’s only option was to rename, and the article of the day said in as many words that you could watch the messages being sent but could not see the actual personal Apple IDs.
Domain lock and Domain Capture arrived as distinct steps in October 2024. So three things in the received wisdom are now wrong. The window is thirty days, not sixty, and the sixty day figure still circulates in community writing. Capture is now its own deliberate, labelled, irreversible action rather than a consequence of federating. And users now have the transfer option as well as the rename.
One thing did not change, which is the part that mattered most. Apple still will not tell you who these people are.
The decision
Verify the domain, because everything needs it. Lock the domain early, because it is silent and it stops the problem growing. Then treat capture as a project with a communications plan, a service desk brief and a start date chosen deliberately, rather than as a checkbox on the way to single sign-on.
If you do not need federation, you may not need capture at all. A locked domain with a population of legacy personal accounts is an untidy but stable state, and untidy and stable beats tidy and on fire. If you do need federation, capture is on the path and the only question is when, which means the only real decision left is how much work you do before you press it.
My answer is: more than feels proportionate. The thirty days are fixed, the step is irreversible, and the difference between a capture that generates ninety support calls and one that generates nine is entirely front-loaded. The next article is that front-loading, in order.
Apple Business
‹ Previous: [AB 3] Roles, Organizational Units, and Who Can Break What
Next: [AB 4.1] Build Sheet: Locking and Capturing a Domain ›
