Enrolment is not a step in a build. It is the moment you decide, permanently and for that individual device, how much authority your organisation is going to hold over it. Everything you can do afterwards is downstream of a door somebody walked through in the first ninety seconds, and every one of them costs a wipe or a cable to walk back through.
Wave 1 of this series ended with a verified, federated Apple Business organization, devices arriving into it from the channels you actually buy through, and a live connection to Intune. Nothing was enrolled, deliberately, because enrolment is where the design decisions are and they deserve their own article rather than a step in a build sheet. [AB 7.1] built the plumbing. This one is about what you send through it.
Most writing on this subject is a feature matrix. A feature matrix tells you what each method supports and it will not tell you the thing you actually need, which is what each method takes away and whether you can get it back. So this article is organised around cost rather than capability, and the recurring question is not “can I do X” but “what have I just made impossible”.
Apple’s axis, and it is the right one
Apple states the trade in two sentences on its enrollment methods page, and it is a better organising principle than anything Microsoft publishes. Account-driven User Enrollment and account-driven Device Enrollment provide the user with the most privacy and data separation. Profile-based Device Enrollment and Automated Device Enrollment provide IT teams the most control over the device.
Read that as an axis rather than as a menu. Every method sits somewhere on a single line running from the user’s privacy at one end to your control at the other, and the position is set by how much the device is willing to tell you about itself. Apple’s own capability matrix makes the mechanism visible: account-driven User Enrollment cannot query unique device identifiers like the serial number, cannot query the time zone, the phone number, the roaming status or the list of installed apps, and cannot enforce software updates. Every other method can. That is not Microsoft failing to implement something. That is Apple withholding the data at the platform layer because of the door the device came through.
The enrolment method is not a deployment preference. It is a permission boundary Apple enforces in the operating system, and no amount of MDM configuration reaches across it.
That is why the ownership record, the supervision state and the identifier visibility all move together. They are not three separate settings you can mix. They are three views of the same decision.
Door one: Automated Device Enrollment
This is the door the series has been building toward. The device is in Apple Business, Apple Business has told Intune about it, and when somebody takes it out of the box Setup Assistant offers it to your organisation before the user has done anything at all. It is the only iPhone or iPad enrolment path that supervises the device without a cable, and supervision is what everything else in Phase 9 depends on, as [9.4.2] sets out at length.
What it costs is the device’s current state. Microsoft’s guidance is unambiguous and it appears as a Tip immediately under the prerequisites: automated device enrollment applies device configurations that a device user may not be able to remove, so wipe all devices prior to enrolment to return them to an out-of-box state. The prerequisites themselves say new or wiped. The decision table in the enrolment guide is blunter still: against the row “You have existing devices”, the answer is a cross and the instruction is that existing devices should be enrolled using Apple Configurator.
There is a platform asymmetry here that catches people who have done this on Mac first. The macOS decision table answers the same row with a tick and points at a documented path for enrolling existing Macs after Setup Assistant has already run. There is no equivalent for iPhone and iPad. On Apple mobile, an activated device has to be wiped, and Microsoft states the ordering precisely: a device that is already activated needs to be wiped before it can enrol with automated device enrollment, and after you wipe it but before activating it again you can apply the enrolment policy.
The second cost is one almost nobody prices in at design time, and it is the subject of the next article. An ADE enrolment policy is read by the device once, during activation. Change it afterwards and the change is inert on every device that has already activated, with one documented exception: the device name template, which takes effect at the next check-in. That makes the policy shape a decision with the lifetime of the hardware rather than a setting you tune. It is the single strongest argument for spending an afternoon on the policy before you enrol the first device.
The third cost is the one this series will keep returning to. ADE with Setup Assistant with modern authentication gets you an enrolled, supervised, user-affiliated device that Microsoft Entra ID does not know exists. Intune reports it compliant. Entra reports it noncompliant, or has no device object for it at all, depending on which Microsoft page you read. Conditional Access therefore has nothing to evaluate. The window closes when a human opens an app and signs in a second time, and it is bounded by that human action rather than by a timer. That is the whole subject of the next article and it is why this one does not treat ADE as a finished answer.
Door two: Apple Configurator
Configurator is the door for devices you can physically hold. Enrolling into Intune this way requires a USB connection to a Mac for every device you enrol, which is the constraint that decides whether it is viable, and it comes in two modes that produce materially different outcomes.
Setup Assistant enrollment wipes the device and prepares it to enrol during Setup Assistant. Direct enrollment does not wipe, and enrols the device through the iOS settings, and supports devices with no user affinity only. Microsoft is explicit that the Company Portal app is not supported for directly enrolled devices, and that apps requiring user affiliation, including Company Portal itself, cannot be installed. So direct enrollment gives you a corporate ownership record on a device that was never erased, and takes away the user, the Company Portal and every line-of-business app that depends on either.
Two traps worth carrying. The first is a contradiction inside Microsoft’s own page. Its prerequisites list device serial numbers as required for Setup Assistant enrollment only, and its direct enrollment section says you can enrol a device without acquiring the device’s serial number, but its certificates section says that before you export the ACME certificate for Apple Configurator enrollment you must first preload the device serial numbers into Intune and assign them to the enrolment policy, otherwise the direct enrollment policy will fail. The three sentences cannot all be operative. The safe reading is that the preload is a condition of the ACME path specifically, and Microsoft currently tells you not to take the ACME path for userless direct enrolment anyway, because downloading the ACME profile errors and the instruction is to use the SCEP profile until that is fixed. Preload the serials regardless. It costs nothing and it is the only reading that survives whichever certificate profile you end up exporting.
The second is the artefact lifetime. Direct enrollment produces a .mobileconfig file that Microsoft states is only valid for two weeks, at which time you must re-create it. A stack of devices being cabled up over a month is two exports, and the failure at the end of week three looks like a device fault rather than an expired file.
[AB 6.2] covers using Configurator to add a device to the Apple Business register, which is a different operation from using Configurator to enrol it into Intune, and conflating the two is the classic mistake. Adding a device to Apple Business puts it in the ownership register. The thirty day provisional period Apple describes begins after the device is successfully assigned and enrolled in a management service, not when you cabled it up, and during it the user can release the device from Apple Business, from supervision and from the management service. If you stage devices weeks before you hand them out, none of the clock has run. Enrolling with Configurator is an Intune operation that happens over a cable.
Door three: device enrolment, web based or through the app
This is the BYOD-shaped door, and it is the one whose costs are most widely misunderstood. Intune offers two variants of Apple device enrollment: web based device enrollment, which runs entirely in Safari and the Settings app, and device enrollment with the Company Portal app. Microsoft’s own comparison gives them identical answers on almost every row. Neither requires a device reset. Neither supervises. Both support just-in-time registration. Web based needs Microsoft Authenticator only; the app-based variant needs Authenticator and Company Portal. The minimum is iOS 15 for web based and iOS 14 for app based, both now academic against Intune’s own supported floor, which is iOS and iPadOS 17.x for devices with user affinity.
Microsoft’s own ranking is worth quoting because it is stronger language than the company usually uses about a BYOD path: it recommends web enrollment using JIT registration with SSO as the most secure enrolment method for device attestation, and recommends enabling web based enrolment because it does not require employees and students to install the Company Portal app.
The ownership record is recoverable here, and that surprises people
Intune classifies iOS and iPadOS devices as personally owned by default. Where enrolment restrictions are concerned, a device counts as corporate-owned if it is registered with a serial number or IMEI, or enrolled by using Automated Device Enrollment. That two-condition sentence is the rule for evaluating a personal-device block, not the general ownership rule: Intune’s own ownership article adds that Apple Configurator enrolment and device enrollment manager accounts also produce corporate status automatically, which is why the Configurator column in the table below reads corporate without any identifier upload.
The consequence is that you can put a device-enrolled iPhone into the corporate ownership record by uploading its serial number as a corporate identifier before the user enrols. Corporate identifiers are supported for iOS and iPadOS, and Microsoft recommends the serial number over the IMEI where you have it. The ordering is strict: the list must be imported prior to enrolling the devices in Intune. What you get is the ownership record and the fuller inventory that comes with it. What you do not get is supervision. On iPhone and iPad supervision arrives either through Automated Device Enrollment or through an Apple Configurator wipe over USB, and a device-enrolled phone has had neither.
Two 2026 corrections that change the cost model
The first is about apps, and it corrects something this series would have got wrong six months ago. There is a widely repeated claim that an app the user installed before enrolment can never become managed on Apple platforms. Stated that broadly it is false. There is a real restriction underneath it and it is scoped much more narrowly than almost anyone says.
Apple’s sentence lives on the page about account-driven enrollment methods, in a list introduced by an explanation of work and personal data separation, and it therefore scopes to the two account-driven methods. Apple’s current managed apps page, revised in June 2026 and the most recent Apple source in this area, states the general rule the other way round: if the user has installed an app already, the device management service can take over management of that app, on supervised devices this happens without user interaction, otherwise the user needs to formally accept management, and app conversion is not available for account-driven User Enrollments. Apple’s capability matrix carries the same fact as a row, and it is the wider of the two statements: take over management of a personal app is allowed for profile-based Device Enrollment and for Automated Device Enrollment, and not allowed for both account-driven methods. The prose sentence names only account-driven User Enrollment; the matrix rules out account-driven Device Enrollment as well.
Microsoft documents the same capability from its own side, listing managed app conversion as supported on iOS and iPadOS and nowhere else, with a footnote describing it as a native iOS feature that allows Intune to take over the ownership of an application originally deployed outside of Intune during the next check-in. Its troubleshooting guidance describes the user-facing half in passing, inside an article about removing App Store apps: after the apps are assigned, you are prompted to allow Intune to take over management of the apps on the device. On a device enrolled through the device enrolment programme in supervised mode, that prompt does not appear.
The pre-installed app problem is a user enrolment cost, not a BYOD cost. Choosing web based device enrolment over account-driven User Enrollment removes it entirely, at the price of a takeover prompt the user has to accept.
The second correction is about patching, and it is the one most likely to be missing from a decision made in 2024. The enrolment guide still carries a sentence saying that users must install updates and that only devices enrolled using Automated Device Enrollment can receive updates using MDM policies or profiles. Microsoft’s declarative device management update page lists the supported enrolment methods as Device Enrollment and Automated Device Enrollment, on iOS and iPadOS 17.0 and later. Both statements are live. They are reconcilable, because the legacy MDM software-update workload was supervised-only while the declarative workload is not, and Microsoft has separately stated that Apple has deprecated MDM-based software update workloads and that Intune will soon end support for them. The newer page describes the mechanism that is going to survive.
So if your argument for insisting on ADE is that it is the only way to force an OS update, that argument is weaker in 2026 than it was, and you should check it against the declarative update documentation rather than against the enrolment guide before you use it to justify a wipe campaign.
Door four: account-driven User Enrollment
This is the door for a device the organisation does not own and does not want to see inside. The user signs in with a Managed Apple Account, which is why [AB 4] and [AB 5] are prerequisites in practice rather than in name. Federation is the escape from hand-issuing those accounts, and Microsoft says so directly: if you enable federated authentication, which consists of linking Apple Business with Microsoft Entra ID, you do not have to create and provide unique Apple IDs to each user.
The mechanism is a separate encrypted volume. Work data lives on a managed APFS volume and in managed apps, away from the user’s personal data and apps, and the volume and cryptographic keys created to manage the work data are erased when the device unenrols from Intune. Microsoft states the authority split more cleanly than Apple does: users cannot factory reset the work partition, administrators can; users can factory reset the personal partition, administrators cannot. Apple’s own framing sits at the cryptographic layer, that the operating system creates separate encryption keys when account-driven enrolment completes.
What it costs is more than most decision tables admit.
The corporate ownership record is structurally impossible, not merely absent. Microsoft’s own wording: Apple user enrollment with Company Portal and account driven user enrollment corporate identifiers are not currently supported because the MDM does not get access to the device serial number, IMEI and UDID. That is a property of Apple’s privacy design rather than an Intune gap, and no future Intune release closes it without Apple changing what the device discloses.
Every Microsoft app the user already had has to be deleted and redeployed. This is the trap from the previous section landing where it actually applies. Microsoft’s worked example is Outlook: the user downloads it from the App Store, configures it for personal email, is later blocked by Conditional Access when they add work mail, enrols, and the user enrollment policy fails because Outlook is installed and configured in the user partition rather than the work partition. Users must manually uninstall the app. On a two-year-old daily driver that is materially worse than the phrase “no wipe required” suggests.
Volume licensing is user-only, and the default works against you. Microsoft’s licensing table gives User Enrollment as not supported under device licensing and supported using Managed Apple Accounts under user licensing, and separately states that when you create a new assignment for a volume purchased app the default licence type is now device. The default therefore produces a failure. The error code is 0x87D13BA9, and its text says exactly this: the app is deployed with the Device licensing type but only the User licensing type is supported for BYOD devices enrolled with account driven Apple User Enrollment. The licensing article for this series will put a gate in front of it.
It is the hardest one-way door in the set. Microsoft: when devices are enrolled using account driven user enrollment, you cannot switch to device enrollment, you cannot move an app from unmanaged to managed, and users must unenrol from user enrollment and then re-enrol to device enrollment. Every other transition in this article is a wipe. This one is a wipe plus a conversation with the user about their personal device.
There is also a cross-surface coupling that catches people who adopt this path and then wonder why a corporate build broke. Intune blocks an ADE enrolment that uses the Company Portal authentication method if the device user is targeted with an account driven Apple user enrollment policy type. The user receives an error saying their account does not support enrolment through the Company Portal app and that they need to enrol through the Company Portal website. A BYOD policy targeting a person therefore invalidates a corporate policy targeting that person’s hardware, and the documented remedy is to use Setup Assistant with modern authentication instead. If your tenant has adopted account-driven user enrolment at all, the Company Portal authentication method is effectively dead for corporate builds, whether or not anybody decided that.
Microsoft is also unusually direct about when to skip this door entirely. If users primarily use Microsoft apps, or apps built with the Intune App SDK, they should download those from the App Store and be protected with app protection policies, and in that scenario you do not need account driven user enrollment at all. Line-of-business apps are the case that changes the answer, because application management does not support them and account-driven User Enrollment deploys them into the work partition. [9.4.3] owns the app protection side of this argument and this series does not rebuild it.
The comparison, arranged by what it costs
Read the rows downward rather than the columns across. The columns tell you what each door does. The rows tell you where the estate diverges.
| What you are deciding | Automated Device Enrollment | Apple Configurator | Device enrolment, web or app | Account-driven User Enrollment |
|---|---|---|---|---|
| Does the device get wiped | Yes, always, on iPhone and iPad | Setup Assistant mode wipes, direct enrollment does not | No | No |
| Is it supervised | Yes, and it is the only iPhone and iPad path that supervises | Only if you choose supervision in Configurator | No | No, and Apple says so explicitly |
| Ownership record | Corporate, automatically | Corporate, automatically | Personal by default, corporate if you pre-load the serial or IMEI | Personal, and corporate is structurally impossible |
| Can Intune see the serial, IMEI and UDID | Yes | Yes | Yes | No, by Apple’s design |
| Can an app the user installed first become managed | Yes, silently | Yes, silently if supervised | Yes, with the user accepting a prompt | No. Delete and redeploy |
| Can the user remove management | No, with Locked enrollment set | Depends on the supervision level chosen in Configurator. Intune’s Configurator enrolment policy has no Locked enrollment setting. | Yes | Yes |
| Apple Business required to enrol | Yes | No | No | Yes in practice, for Managed Apple Accounts |
| Volume purchased apps | Device or user licensing | Device or user licensing in Setup Assistant mode; device only on direct enrollment, which has no user | Device or user licensing | User licensing only |
| Getting out of it | Wipe | Wipe, or re-add and wipe for ADE | Wipe to reach ADE | Unenrol, then re-enrol, and every managed app goes with it |
One row deserves emphasis because it is the row people design around and then discover they were wrong about. Supervision on iPhone and iPad comes from Automated Device Enrollment. Apple’s supervision page lists the automatic cases and iPhone with iOS 13 or later under ADE is the relevant one; Apple’s own comparison table gives profile-based Device Enrollment as not supervised on iPhone, iPad and Apple TV, and supervised on Mac. Microsoft adds the retrospective route and its cost: if a device is enrolled without supervision, you need Apple Configurator to make it supervised, and to reset the device in that way you connect it to a Mac with a USB cable.
Two smaller notes on the ADE supervision toggle, because both vendors have quietly made it decorative. Intune ignores the is_supervised flag for devices running iOS 13.0 and later because those devices are automatically supervised at enrolment, and Apple’s protocol documentation says the same thing more bluntly: in iOS 13, all ADE devices will be supervised and the OS will ignore the flag completely. The toggle still has to be set correctly, though, because Apple’s own API refuses to lock the management payload onto a device unless the supervision flag is true. A control that the operating system ignores and the provisioning API depends on is an odd artefact, and it is worth knowing which half is which before you reason about it.
The fifth door, which Apple built and Intune has not opened
There is a method that is exactly right for the case every organisation has, and you cannot use it with Intune.
Account-driven Device Enrollment is Apple’s answer for organisation-owned devices already in use by the user. It is initiated by the user signing in with a Managed Apple Account, it needs no cable and no wipe, and it produces a Device Enrollment rather than a User Enrollment, which means the serial number is visible and software updates can be enforced. Apple discovers the management service through a well-known file at your own domain, and the file carries a Version key whose value determines which enrolment method the device uses: mdm-byod for User Enrollment, and mdm-adde for account-driven Device Enrollment.
Intune publishes only mdm-byod. Every documented Intune well-known file, across commercial, US Government and 21Vianet, carries that value and no other. There is no Intune article on account-driven Device Enrollment and nothing on Intune’s in-development page. The supporting signal is weaker than it first looks and it is worth being honest about that. When Microsoft broke out Device Management Type values for managed-app assignment filters in the February 2026 service release, the iOS list ran to Automated Device Enrollment user-associated devices, Automated Device Enrollment userless devices, Account Driven User Enrollment, and Device Enrollment with Company Portal and Web Enrollment. Account-driven Device Enrollment is not there. Neither is Apple Configurator, which Intune plainly supports, so treat the omission as suggestive rather than probative.
The defensible statement, and the one this series makes, is that Microsoft does not document support for account-driven Device Enrollment and publishes no mdm-adde discovery file for it. That is a documented absence rather than a documented refusal, and the distinction matters if you are writing a design document somebody will hold you to.
One correction to the enthusiasm, because the capability is narrower than the name implies. Apple’s comparison table answers the supervision question for account-driven Device Enrollment as no for iPhone, iPad and Apple Vision Pro, and yes for Mac. So on Apple mobile the delta over web based device enrolment is smaller than it sounds. What it would buy you is an account-initiated flow with full device identifiers and enforceable software updates on a device nobody had to wipe. That is worth having and it is not supervision.
The door that closed
User enrollment with Company Portal is gone for new work. Microsoft’s wording: Apple user enrollment with Company Portal has been deprecated as an enrolment option and is no longer available for newly enrolled devices, support remains available to devices that already have the enrolment profile, and for new enrolments the recommendation is account-driven user enrollment.
If you are inheriting an estate, expect to find devices on it, and expect the migration to be an unenrol and re-enrol rather than a conversion. There is a community claim, which I have not been able to verify against Apple, that Apple itself removed profile-based User Enrollment at the platform level in iOS 18 rather than Microsoft retiring a feature. The circumstantial support is that Apple’s current enrollment methods comparison does not list profile-based User Enrollment as a method at all, and its User Enrollment page describes only the account-driven variant. That is suggestive and it is not proof, and the difference matters: a Microsoft product decision can be reversed and a platform removal cannot.
The other path with a retirement signal is Setup Assistant (legacy), which the next article deals with properly because the documentation disagrees with itself about whether you can still select it.
Choosing, in the order the decision actually gets made
The decision is not “which enrolment method”. It is a short sequence of prior questions, and by the time you have answered them the method has usually chosen itself.
Who owns the device. If the organisation does not own it, you are on the account-driven User Enrollment branch or on app protection without enrolment, and the rest of this article is background. If the organisation owns it, keep going.
Has it been activated. This is the question that removes most of the options, and it is the one people answer last. A device in a box goes through door one. A device in somebody’s hand does not, and no amount of design changes that on iPhone and iPad.
Do you need supervision. Be honest about the answer rather than defaulting to yes. Supervision buys the restriction set, app allow and block lists, Managed Lost Mode, Always On VPN, a global HTTP proxy, the ability to set the device name and Activation Lock management on iPhone and iPad. If none of those is in your control set, supervision is a reason to wipe a fleet that you have not justified. If any of them is, there is one door.
Can you get physical access. If yes, and the device is in use, Configurator is the only route to a supervised, corporate device without buying new hardware, and the cost is a person, a Mac and a cable for every device. Price it as labour, because that is what it is.
Do you need line-of-business apps on a device you do not own. This is the only question that makes account-driven User Enrollment the right answer rather than a compromise, and Microsoft says so in its own words.
The uncomfortable case, and it is the common one, is an organisation-owned iPhone already in someone’s hands. Your documented options in 2026 are exactly three: collect it and cable it to a Mac, wipe it and run ADE, or accept a device-enrolment record that is corporate on paper and unsupervised in fact. Apple built the fifth door for precisely this and Intune has not opened it. A later article in this series is about that gap and about what you can genuinely recover on a device that is already in use.
The design position
Pick the door per device population, not per organisation, and write down why. The estates that go wrong are the ones that picked a method once, applied it to everything, and then discovered a population it was wrong for after the devices were activated. Every remedy in this article costs a wipe or a cable, and both of those are conversations with people who have work to do.
Second, treat the ownership record as a control rather than as reporting metadata. You can flip a device to corporate in its properties after the fact, and the inventory follows. What you cannot recover is the enrolment restriction decision, which is evaluated once, at enrolment, against the identifier list as it stood at that moment. That is the reason to upload serials first, and it is a narrower and more defensible reason than the one usually given.
Third, and this is the one that separates a design from a deployment: enrolling a device and governing a device are different acts. Every door in this article gets you the first. None of them gets you the second on its own, because the object Conditional Access evaluates is a Microsoft Entra device registration and that is created by a human signing in, after enrolment, in an app. [CA 1] makes the argument that Conditional Access is the real control plane. This series’ contribution to that argument is that on Apple mobile there is a window, of unbounded length, in which a device is fully managed and entirely ungoverned.
That window is the subject of the next article, along with the enrolment policy that a device reads once and the authentication decision inside it that determines whether the window is measured in seconds or in weeks.
Apple Business
‹ Previous: [AB 7.1] Build Sheet: Connecting Apple Business to Intune
Next: [AB 9] Zero Touch: Enrollment Policies and the Authentication Decision ›
