Almost everything in Intune is a policy that converges. You change it, devices check in, the change lands. The Apple enrollment policy is not that. The device reads it once, while it is activating, and never asks again. Change it afterwards and you have edited a document that describes a fleet you no longer have.
[AB 8] argued that the enrolment method is a permission boundary rather than a deployment preference. This article is about the object that carries that decision on the zero touch path, why its fixity changes how you design it, and the one setting inside it that determines whether Conditional Access ever sees the device at all.
Two housekeeping facts before the argument. Microsoft renamed the blade: current guidance is written against Enrollment program tokens, then Enrollment policies, and the older Profiles experience differs, will not receive new features, and is stated to be retiring eventually with no date given. And there is a limit of 1,000 enrolment policies per token, which sounds generous until you read the next section and understand why estates end up with dozens.
Read once, at activation
Microsoft states the consequence and Apple states the mechanism, and it is worth having both because the Microsoft sentence on its own reads like a product limitation that a future release might fix.
Microsoft, as an Important inside the policy creation steps: if you make changes to an existing enrolment policy, the new settings will not take effect on assigned devices until devices are reset back to factory settings and reactivated. The device name template setting is the only setting you can change that does not require a factory reset to take effect, and changes to the naming template take effect at the next check-in.
Apple, in the protocol documentation for the endpoint that removes a profile from a set of devices: after this call, the devices in the list will have no profiles associated with them, however, if those devices have already obtained the profile, this has no effect until the device is wiped and activated again.
Apple says that about profile removal, which is a different operation from an edit. The two statements sit either side of the same model: Microsoft describes the consequence for edits, Apple describes the mechanism that produces it.
The model is a fetch, not a subscription. During activation the device asks Apple’s servers which management service it belongs to and pulls the profile down; from that point the profile is resident and there is no channel by which a server-side change reaches it. Everything you configure in the Intune enrolment policy that maps to a key in that profile is therefore frozen at the moment the user swiped through the setup screens.
Which explains the exemption, and the explanation is more useful than the exemption. The device name template is the one editable setting because it is not carried in the Apple profile at all. Intune renames the device by management command at enrolment and at each successive check-in, so it travels on the ordinary converging channel with everything else Intune sends. Expect the exempt list to stay at exactly one item for as long as the rest of the policy maps to Apple’s profile keys.
Two settings are stricter than the general rule and are worth knowing separately. User affinity cannot be changed in an existing enrolment policy at all. Microsoft states, on the shared device mode article rather than on the main enrolment policy page, that you cannot change the user affinity setting in an existing enrolment policy and that if you need to modify it you must create a new one. Whether the portal refuses the edit or accepts it inertly is not stated, and I have not tested it. And a Shared iPad configuration that needs to stop using temporary sessions requires the device to be fully reset and a new policy sent down. Both are stated as requiring a new policy rather than as edits that quietly fail, which is the opposite failure mode from the general case. The general case lets you save a policy whose stored state has diverged from your fleet’s actual state, and that is the dangerous one, because nothing tells you.
What this does to the way you design
Three consequences follow, and none of them is a feature request.
The policy is a decision with the lifetime of the hardware. Whatever you choose applies to every device enrolled under it until that device is wiped, which in practice means until it is replaced. An organisation that changes its mind about Locked enrollment eighteen months in does not change its mind about anything; it acquires a second population and waits three years.
Put configuration in configuration profiles. Anything expressible both in the enrolment policy and in a device configuration profile belongs in the configuration profile, because that surface converges and this one does not. The enrolment policy should carry only what genuinely has to be present at activation: the authentication method, user affinity, supervision, Locked enrollment, the Setup Assistant screens and the awaiting-configuration behaviour. Everything else is somebody making a permanent decision to save a five minute job.
Version the policy rather than editing it. The estates that handle this well create a new policy when the design changes, assign it to new and rebuilt devices, and keep the old one until the last device under it is gone. That is what the 1,000 policy ceiling is really for. The estates that handle it badly edit in place, see the change save without error, and believe it has applied.
There is a small irony worth carrying, because it is the cleanest illustration of the whole model. Microsoft’s documented fix for the failure “ADE enrolment does not start” is to edit the enrolment policy, change anything at all purely to update its modification time, then synchronise. That is the exact action the immutability note calls inert. Microsoft’s stated cause is different, that the policy was created before the token was uploaded, and its stated purpose for the edit is to update the modification time so the assignment is served again. My reading of why the same action works here and not elsewhere is that these devices have never activated, so there is no cached profile for the edit to fail against, and that is my reading rather than Microsoft’s. Same action, opposite outcome, and the variable is whether the device has been switched on.
Two Apple keys in the 26 cycle bear on this and Intune exposes neither. do_not_use_profile_from_backup makes a device restoring from a backup read the current profile from the server rather than reusing the cached one, and from iOS 26.4 and visionOS 26.4 it also makes the device remove all configuration profiles when it restores a backup. Apple says that behaviour will become nonelective in a future OS update. is_return_to_service configures Rapid Return to Service, which is the wipe-and-resetup automation that would make fleet-wide policy change tractable. Neither appears in the Intune enrolment policy, in the what is new page, or in the in-development page. If the immutability problem ever gets an operational answer, it will come from there.
User affinity is three options, and the third one is not a variant of the other two
Most write-ups give two. There are three on iOS and iPadOS, and macOS has two, which is part of why the third gets dropped by anyone who learned this on Mac.
| Option | What it is for | What it commits you to |
|---|---|---|
| Enroll with User Affinity | Devices belonging to a person, who will use the Company Portal for things like installing apps | Every user on such a device needs an Intune licence. This is the only option that leads to the authentication decision below. |
| Enroll without User Affinity | Devices not affiliated with a single user and not accessing local user data: kiosk, point of sale, shared utility | An Intune device licence unless an Intune-licensed user is associated. Enrolment restrictions stop working, in a way described below. |
| Enroll with Microsoft Entra ID shared mode | Frontline devices shared through the day, with users signing in and out | Locked enrollment must be Yes. Microsoft Authenticator must be assigned as required to all devices and must have been purchased through a volume programme. The single sign-on extension carries the shared-device flag. |
The userless option has a well-known escape hatch and one under-documented consequence.
The escape hatch is device staging. You can associate a primary user with a device enrolled without user affinity by sending the IntuneUDAUserlessDevice key to the Company Portal app in an app configuration policy for managed devices. The first user who signs in becomes the primary user, and Microsoft is explicit that if that user signs out and a second signs in, the first remains the primary user. Stickiness is the design, not a bug, and a shared device staged this way carries the name of whoever happened to open Company Portal first.
There is a reporting quirk attached that will otherwise cost somebody an afternoon. Microsoft documents that this app configuration is a one-time operation, is removed from the policy in the background once it has applied, and that the assignment will exist but will never report success. A STATE Policy Error on this policy is the expected steady state. Once it has applied you can unassign it.
The under-documented consequence is more serious and it sits in a single bullet on a different page. Enrolment restrictions apply to enrolments that are user-driven; for scenarios that are not user-driven, Intune enforces the default policy. The list of non-user-driven scenarios includes, in Microsoft’s words, userless Apple automated device enrollment without user-device affinity.
For every kiosk, shared iPad and frontline device in your estate, the carefully scoped enrolment restriction you assigned to a group does nothing. The default All Users policy is the only one evaluated.
That fact is filed on the restrictions page, which never mentions Invalid Profile, while the warning about Invalid Profile is filed on the enrolment page, which never mentions that userless devices bypass every non-default restriction. A reader needs both pages to understand the trap, and there is no cross-reference between them. [3.1.1] owns enrolment restrictions in general; the Apple-specific point is that your userless estate hangs entirely on one policy’s platform setting.
Invalid Profile, which is a restriction and almost never anything else
The device comes out of the box, joins the network, reaches the remote management pane, and reports that the configuration could not be downloaded from your organisation: Invalid Profile. It looks like a token problem, a certificate problem or an Apple outage, and it is a checkbox.
Microsoft’s note, in full because the tail of it is the part people cut: ensure that Device Type Restrictions under Enrollment Restrictions does not have the default All Users policy set to block the iOS and iPadOS platform. This setting causes automated enrolment to fail and your device shows as Invalid Profile, regardless of user attestation. To permit enrolment only by company-managed devices, block only personally owned devices, which permits corporate devices to enrol. Microsoft defines a corporate device as a device enrolled through a device enrolment programme or manually entered under Corporate device identifiers.
The phrase “regardless of user attestation” is doing real work. A platform block is not a filter that a corporate device passes; it is a wall. The intended control, which is to allow only devices the organisation owns, is expressed by blocking personally owned rather than by blocking the platform, and it works because ADE enrolment is itself the ownership attestation. This is the same rule [AB 8] sets out from the other direction.
Two things worth knowing about restrictions before you touch them. Edits apply to new enrolments and do not affect devices that are already enrolled, so this is not a lever you pull during an incident. And Microsoft’s fifteen minute note is about assignment propagation rather than about the setting itself: the update between Microsoft Entra and Intune that processes user, group and filter assignments typically happens within fifteen minutes and is not instant, and its own advice is to wait several minutes after adding an enrolling user to a group rather than testing immediately.
Microsoft documents exactly one cause of Invalid Profile. In the field the string is Apple’s generic client-side message for a management server that did not return a usable enrolment profile, so it is unlikely to be the only cause in existence, and it is the only one you can look up. Check the restriction first because it costs thirty seconds and it is almost always the answer.
The authentication decision
If you chose user affinity, you now choose how the person proves who they are during Setup Assistant. This is the setting that determines whether the device becomes a governed object or merely a managed one, and Microsoft’s own documentation cannot agree on how many options there are.
| Where you read it | How many options it gives | What it says about legacy |
|---|---|---|
| The iOS enrolment policy article, revised May 2026 and scoped explicitly to the new Enrollment policies blade | Two: Company Portal, and Setup Assistant with modern authentication | Legacy is not in the list, and the step immediately afterwards begins with the words “If you selected Setup Assistant (legacy)” |
| The authentication methods reference | Four: Company Portal, Setup Assistant with modern authentication, JIT Registration for Setup Assistant with modern authentication, Setup Assistant (legacy) | Documented as a full method with its own section |
| The ADE overview, revised at the end of April 2026, three weeks before the two enrolment policy articles | Three | “Not recommended or supported” |
| The macOS enrolment policy article, same date as the iOS one | Two: modern and legacy | Selectable, and explicitly supported for local account settings |
| The iOS enrolment guide, which manages to disagree with itself a few hundred words apart | Two in its decision preamble, three in its policy instruction | Absent from one list, present as not recommended in the other |
This is not pedantry about documentation quality. It is the difference between a build sheet that works and one that sends a reader looking for a control. The reference article is unambiguous that legacy exists as a current method and documents it as Option 4, so the open question is narrower than it looks: it is whether legacy is still selectable in the iOS picker of the new blade, not whether it exists. The most defensible reading is that it was removed from that picker and retained in the macOS one, and that the iOS article’s next step was not cleaned up when the list was shortened. I have not verified that against a live tenant and no Microsoft page states the removal, so this series says what the documents say and tells you to read the dropdown. If you are writing a runbook, write down which options you actually saw and the date you saw them.
What legacy actually is, from Microsoft’s own description of when to use it, is the interesting part. You use it when you want to wipe a device, when you do not want modern authentication features such as multifactor authentication, and when you do not want to register devices in Microsoft Entra ID; Microsoft adds, in the same list, that Setup Assistant (legacy) authenticates the user with the Apple .p7m token from [AB 7]. The user still authenticates, and in a federated tenant they authenticate through the legacy path: enrolling ADE devices with user affinity requires a WS-Trust 1.3 Username and Mixed endpoint to request user tokens, and if it is not enabled the devices cannot enrol at all. What legacy does not produce is a registered device object, and the modern features layered on top of that exchange, multifactor in particular, do not work.
The multifactor point is worth stating with its symptom, because it is how you recognise it: Microsoft documents that enrolment sticks after the user enters credentials, gives the cause as multifactor authentication being enabled with the method set to legacy, and gives the remedy as changing the method. And there is a silent downgrade: Setup Assistant with modern authentication is supported on iOS 13.0 and later, and older devices assigned that kind of policy fall back on legacy. Nothing warns the administrator. The practical exposure is now near zero given where the supported OS floor sits, but the shape of the failure is worth remembering, because a policy that silently degrades to a weaker authentication mode is a category of defect rather than an artefact of one product.
The Company Portal option is the one to be careful about for a different reason. It is blocked outright if the user is targeted by an account-driven Apple user enrollment policy, and the recommended remedy is to use Setup Assistant with modern authentication. In any tenant that has adopted account-driven user enrolment, that method is effectively unavailable for corporate builds regardless of what anybody decided.
The window where the device is managed and ungoverned
Choose Setup Assistant with modern authentication and the device finishes Setup Assistant enrolled, supervised, user-affiliated, receiving configuration policy, and invisible to Conditional Access.
Microsoft states it as a list of five things that have not happened. Until the user signs in to the Company Portal with their Microsoft Entra credentials and selects Begin, the device will not be fully registered with Microsoft Entra ID, will not show up in the user’s device list in Entra, will not have access to resources protected by Conditional Access, will not be evaluated for device compliance, and will be redirected to the Company Portal from other apps if the user tries to open any managed application protected by Conditional Access.
And it states the same fact as a compliance split on the enrolment guide, twice, in two slightly different wordings. The sharper of the two: the device is not fully registered with Microsoft Entra ID and shows as non-compliant in a user’s device list in Microsoft Entra ID, while the device shows as compliant in the Microsoft Intune admin center.
Those two Microsoft statements do not agree with each other, and both are about iOS, on pages a click apart. One says the device will not show up in the user’s device list in Microsoft Entra ID; the other says it shows as non-compliant in a user’s device list in Microsoft Entra ID. They cannot both describe the same instant. My reading is that the first is technically accurate about the object and the second is describing the user-visible outcome, but Microsoft has not reconciled them and neither should you when quoting them. There is a third state to hold alongside them: the same authentication methods page says the device will not be evaluated for device compliance, and Microsoft’s compliance monitoring documentation gives Not evaluated as the initial state for a newly enrolled device, which is not the same thing as compliant. What is not in dispute is the operationally important half. Intune reports a managed device it is satisfied with, and Conditional Access has nothing to evaluate. The macOS guide, for contrast, says the device does not show in the user’s Entra device list at all and makes no compliance claim either way.
The reason is an ordering inversion, and the framing is mine rather than Microsoft’s. Microsoft’s page on Entra registered devices says that Entra registration is not the same as device enrolment, and describes registration happening first with enrolment as a further control an organisation may choose to add. That page is scoped to bring-your-own-device and mobile scenarios rather than stating a universal ordering, but the shape it describes is the one people carry into an ADE build, and on an ADE iPhone the two happen the other way round. The device is enrolled in Setup Assistant, before any Entra device object exists, and registration happens afterwards when a human opens an app.
Which produces the property that matters for design: the window has no timer. It is bounded by a human action. A device whose user never opens Company Portal, or never opens a designated app, stays in this state indefinitely, enrolled and supervised and receiving policy and entirely outside your access control. The failure looks like a working deployment.
There is a documented failure branch that widens the window into a permanent state. If the Company Portal is delivered through the store rather than through a volume purchase and the user does not sign in to the store, the app does not install; if the app is not installed the user cannot register the device; and the device shows as noncompliant in Entra with any resource depending on Conditional Access unavailable. That is the chain that turns a five minute gap into a support ticket three weeks later, and it is the reason the Company Portal is deployed as a required volume-licensed app rather than left to the user.
One related thing not to do, since the failure is invisible until a user reports it. During initial enrolment, for devices enrolled with Setup Assistant with modern authentication and with the enrolment policy setting Install Company Portal set to Yes, Intune automatically pushes app configuration policy settings to the Company Portal. Deploying that configuration manually conflicts with the one sent during enrolment, and Microsoft’s symptom is that Intune incorrectly prompts device users to sign in to the Company Portal and download a management policy they have already installed. Microsoft names no mechanism and the note sits in the device staging section rather than anywhere near registration, so treat the instruction as absolute and the reason as undocumented.
Just-in-time registration, and where the code actually lives
JIT registration is the answer to the window, and it is worth being precise about what it does, because it does not remove a sign-in.
Microsoft: the Intune Company Portal is not required when using JIT registration; instead, JIT registration uses the Apple single sign-on extension to complete Microsoft Entra registration and compliance checks. And, on the authentication methods reference, the Company Portal is still sent to devices as a required app even though it is not required for registration or compliance, because it is useful for gathering and uploading logs.
There are still two authentications. Microsoft says so plainly: one handles enrolment and user-device affinity and happens in Setup Assistant, and another handles Entra registration and happens when the user signs in to the designated app, where the compliance checks are also done. The gain is not fewer prompts. The gain is that the second prompt can be Microsoft Teams, which the user was going to open anyway, instead of the Company Portal, which they were not. Microsoft recommends Teams by name, on the grounds that it is integrated with the latest identity libraries and provides the most streamlined experience from the home screen.
Now the architectural point, and it is the thing to take from this section.
The single sign-on extension binary ships inside Microsoft Authenticator. The Intune policy does not deliver it. The policy only activates it.
Microsoft’s wording, on the Apple device features reference rather than on any page about JIT: to achieve single sign-on with the Microsoft Entra extension type, first install the iOS Authenticator app on devices, because the Authenticator app delivers the Microsoft Enterprise single sign-on plug-in to devices, and the MDM extension settings activate the plug-in. On macOS the same role is played by the Company Portal app.
Read that as a dependency rather than as a prerequisite list. Until Authenticator has actually landed on the device, your single sign-on extension policy is a correctly configured, successfully deployed, completely inert profile. Microsoft’s guidance to end users treats a late Authenticator as a transient wait: users may be unable to access work apps if they sign in while Authenticator is still deploying, and they should wait a few minutes and try again. That is fine as a support script. As a design statement it means the zero touch experience you promised depends on an app store download completing before the user’s curiosity does.
The configuration itself is small and unforgiving. It is a device configuration policy under Device features, Single sign-on app extension, with the extension type set to Microsoft Entra ID, plus two additional configuration entries. Microsoft attaches the same warning to both of them, twice on the same page: remove trailing spaces before and after the value and the key, otherwise just-in-time registration will not work. A policy that silently does nothing because of an invisible character is the kind of failure that gets blamed on Apple.
Three traps, all documented, all easy to walk into by being helpful. Do not add bundle identifiers for Microsoft apps, because the extension applies to them automatically and adding them causes authentication problems. Do not add the Authenticator bundle identifier, for the same reason. And if your organisation uses Microsoft Defender for Endpoint, make sure the Defender app is not the first app users open, because Microsoft states that just-in-time registration and compliance remediation will not work as expected if it is. That is the consequence; the mechanism, the failure signature and the error text are all absent.
There is an apparent contradiction on that third point worth defusing rather than inheriting, because it circulates. Defender for Endpoint’s iOS deployment guidance does tell administrators to add the Defender bundle identifier com.microsoft.scmx to the single sign-on extension policy alongside the registration key, which reads as a direct reversal of the instruction not to add Microsoft apps. It is not. That instruction sits under a heading scoped to Intune user-enrolled devices, which is the bring-your-own-device path rather than this one. On an ADE build the just-in-time guidance stands and you add no Microsoft bundle identifiers at all.
Finally, the scope, because it is broader than most people assume and narrower in one direction that matters. Microsoft supports JIT registration for all iOS and iPadOS enrolments, and enumerates account-driven user enrollment, user enrollment with Company Portal, web based device enrollment, device enrollment with Company Portal, and automated device enrollment using Setup Assistant with modern authentication. It is not available on macOS, where the equivalent capability arrived in 2026 as Platform single sign-on registration during Setup Assistant, on macOS 26 and newer, and is a separate feature with a separate name. [11.6] and the macOS article later in this series carry that thread.
The phishing-resistant conflict, which is real and which nobody is writing about
Here is a sentence Microsoft publishes, in a Caution box, on the authentication methods reference and on no other page I can find: phishing-resistant multifactor authentication is not supported on Setup Assistant for iOS and iPadOS, and users enrolling iOS and iPadOS devices via Automated Device Enrollment using Setup Assistant with modern authentication must have an alternate MFA method available to complete device enrolment.
Set that against what the rest of this site tells you to do. [ZT 2] argues that the access decision is the control point. [CA 4] builds a Conditional Access framework on authentication strength. Microsoft’s own baseline recommendation is a policy targeting all users and all resources with no app exclusions, though the strength it names in that procedure is Multifactor authentication, and its phishing-resistant recommendation is scoped to administrator directory roles. The industry direction, and the position this site takes, goes further than Microsoft’s baseline: phishing-resistant strength, all users, all resources.
Take that step and your iPhones will not enrol.
Why it fails, which Microsoft never says
The built-in Phishing-resistant MFA strength permits three combinations: Windows Hello for Business or platform credential, a FIDO2 security key, and Microsoft Entra certificate-based authentication in its multifactor form. Look at those against an iPhone that is four screens into Setup Assistant. There is no Windows Hello. There is no practical way to present a security key inside the Setup Assistant authentication web view on an out-of-box device. And there is no client certificate, because certificates arrive with management and management has not happened yet. All three phishing-resistant methods are unavailable for the same structural reason: they assume a device that has already been provisioned, and this is the act of provisioning it.
Microsoft documents that same bootstrap paradox elsewhere, in a different context, which is oddly reassuring about the diagnosis. The Register or join devices user action in Conditional Access does not support Windows Hello for Business or device-bound passkeys, and Microsoft’s stated reason is that those scenarios require the device to be already registered.
The remedy Microsoft offers, and why it does not close
Microsoft’s enrolment guidance says that a second device or a Temporary Access Pass is required to complete the MFA challenge for iOS and macOS devices enrolled via Apple automated device enrollment, along with two Android corporate types, because the primary device cannot receive calls or text messages during provisioning.
A Temporary Access Pass does not satisfy the phishing-resistant strength. Entra’s own authentication strength table ticks Temporary Access Pass under Multifactor authentication strength and leaves it blank under both Passwordless MFA strength and Phishing-resistant MFA strength, and Microsoft’s passwordless guidance says it in prose: a Temporary Access Pass is not a permanent passwordless method and is not phishing-resistant.
[CA 4.3] is the article on this site about protecting the bootstrap with a Temporary Access Pass. This is the case where that pattern and Microsoft’s own strongest recommendation point in opposite directions, and the collision is not acknowledged on either side. The Intune page states the limitation and does not mention authentication strength. The Entra authentication strength page lists four limitations and device enrolment is not among them. An identity team reading only the Entra deployment guidance for phishing-resistant authentication will never encounter this.
What the shape of an answer looks like
Microsoft documents no supported pattern for this on iOS. I want to be exact about that, because the temptation is to present a reasonable design as though it were guidance. What exists is the following, and no more.
There are two Intune resources in the Conditional Access picker, and Microsoft describes them by where the prompt lands rather than by leg. Targeting Microsoft Intune Enrollment, application ID d4ebce55-015a-49b5-a083-c84d1797ae8c, requires multifactor authentication during device enrolment and it appears once, on the Company Portal sign-in page. Targeting Microsoft Intune, application ID 0000000a-0000-0000-c000-000000000000, requires it during enrolment and again every time the user signs in to the Company Portal app or website. Note what that means: both reach the Setup Assistant leg. They are two scoping choices for the same requirement rather than a first-leg resource and a second-leg one. The enrolment app is also not created automatically in new tenants, and Microsoft documents adding it by creating a service principal with that application ID.
So an exclusion aimed only at the provisioning prompt is harder to scope than it looks, because the resource that governs the second prompt also governs the first.
Microsoft does document excluding these two apps, and only for Windows. The Autopilot known issues article says exceptions excluding the Microsoft Intune Enrollment and Microsoft Intune cloud apps are needed to complete Autopilot enrolment where restrictive policies are present, and that where a policy requires a compliant device for all cloud apps with no exclusion list, Microsoft Intune Enrollment is excluded by default so that the device can register and enrol and avoid a circular dependency. It is written for Windows, it is about the compliant-device control rather than about authentication strength, and it names no compensating control. Nothing equivalent exists for iOS.
Two more constraints worth having before anybody designs around this. You cannot use the Require multifactor authentication grant control and the Require authentication strength control in the same policy. And Microsoft’s ADE guidance says external authentication methods are supported so you can use your preferred MFA solution during enrolment, while the Entra page it links to says external authentication methods are currently incompatible with authentication strength and you should use the grant control instead. Both constraints push toward the same place, and no page says so.
My own position, offered as a position rather than as documentation: the Setup Assistant leg is the weakest authentication in the chain and it is also the leg where the device is least useful to an attacker, because at that moment it holds nothing. The device is already hardware-bound to your tenant through Apple Business and the enrolment token, and every resource worth protecting sits behind the registration sign-in and behind resource access, both of which happen in a real app with the broker present and can carry whatever strength you like. Enforcing the strength there and letting the provisioning prompt run at a lower bar is defensible. What makes it awkward in practice is the scoping problem above: the resource that carries the provisioning prompt also carries the Company Portal prompt, so the exclusion is coarser than the argument. It deserves a named compensating control and a review date rather than a permanent exclusion that outlives the person who made it.
What is not defensible is discovering this during a rollout. [ZT 4] is about the vocabulary of these frameworks. The vocabulary here says phishing-resistant everywhere, and one platform’s provisioning flow cannot honour it, and the two documentation sets that would tell you have never been introduced.
Two settings that shape the first five minutes
Await final configuration. Just before the home screen loads, Setup Assistant pauses and lets Intune check in with the device, and the user experience is locked while they wait. It is Yes by default for new enrolment policies and No for existing ones, so a policy written before the default changed keeps the old answer until somebody looks. Only device configuration policies start installing during that screen; applications are not included. Microsoft explicitly disclaims any minimum or maximum time and then offers a measurement: during product validation, most devices they tested were released and able to access the home screen within fifteen minutes. That qualifier travels with the figure. It is an observation from a laboratory, not a service level, and the duration scales with the number of policies and apps you assign.
The reason to turn it on is that it is the only mechanism that guarantees a device arrives at the home screen already carrying your critical configuration rather than acquiring it over the following minutes. The reason to be careful is that if a third party is provisioning devices for you, they need to be told, because a locked screen for a quarter of an hour reads as a fault to anyone who has not seen it before.
Locked enrollment. This disables the iOS settings that let the management profile be removed, hiding the button in the Settings app. Two carve-outs matter. On devices not originally purchased through Apple Business but added later, users can see the remove management button for the first thirty days after activating their device, after which it is hidden. That is the provisional period from [AB 6.2] showing up on the enrolment side. And regardless of how Locked enrollment is configured, the Remove Device and Factory Reset options in the Company Portal app are unavailable on ADE devices anyway, on the app and on the website.
There is a dependency between Locked enrollment and Supervised that Intune presents as two independent toggles and Apple enforces at the provisioning API. Apple’s profile schema states that is_mdm_removable can be set to false only if is_supervised is true, and its error list rejects the combination by name, as FLAGS_INVALID. Microsoft handles that for you rather than leaving it to the toggle: Intune ignores the is_supervised flag for devices running iOS 13.0 and later because those devices are supervised automatically at enrolment, and Apple’s own protocol note says the operating system ignores it from iOS 13 as well. So the toggle is a formality on the Intune side and a hard precondition on the Apple side, and the dependency between the two is invisible in the blade.
The certificate question, left open on purpose
Microsoft’s ADE overview says this enrolment type supports the Automated Certificate Management Environment protocol, that when new devices enrol the management profile from Intune receives an ACME certificate, and that ACME provides better protection than SCEP against unauthorised certificate issuance. Supported on iOS 16.0 or later, iPadOS 16.1 or later, and now tvOS and visionOS 26.0 or later.
The macOS equivalent of that page adds a sentence the Apple mobile one has dropped, that devices already enrolled do not receive an ACME certificate unless they re-enrol, and gives the macOS floor as 13.1 or later. A different Microsoft page again, describing device distribution, says that if you are enrolling with ADE and user affinity the error The SCEP server returned an invalid response. can happen during setup, that you can resolve it by downloading the management profile again within fifteen minutes, that after fifteen minutes you have to factory reset the device, and that the error occurs because of a fifteen minute time limit on SCEP certificates enforced for security.
Both pages carry the same content date. The SCEP paragraph sits on the page that has been rebuilt more recently. It carries no operating system qualifier of any kind, and its scope, ADE with user affinity, is not carved out of the ACME statement either. Apple has not deprecated SCEP and documents ACME and SCEP as coexisting payload types. Microsoft still ships an active SCEP-only fallback for a neighbouring Apple enrolment path, so the SCEP code is demonstrably live in 2026.
The tempting conclusion is that the SCEP paragraph is stale. I lean that way and I am not going to print it as settled, because the evidence points both directions and the paragraph has been through the editorial pipeline since ACME shipped. A third reading I cannot rule out is that the enrolment identity certificate is now ACME while something SCEP-issued still sits in the user-affinity handshake, which would make both paragraphs correct and would explain why the qualifier is user affinity rather than an OS version.
Closing this needs a profile dump from a current enrolment or a statement from Microsoft, and neither is available by reading. What you should take operationally is smaller and useful: if a device fails at that stage with a SCEP error, retry the profile download immediately rather than investigating, because the documented recovery window is short and the documented alternative is a factory reset. [12.3] owns everything certificate-shaped beyond this note.
The design position
Design the enrolment policy as an artefact with the lifetime of the hardware, and review it on that cadence rather than on a change request. Put everything you might want to revisit somewhere that converges. Create a new policy instead of editing one, and keep the old one until the population under it is gone.
Treat Setup Assistant with modern authentication plus JIT registration as the default shape, on the understanding that JIT does not close the registration window so much as make it likely to close on its own. The window is real either way, and the honest way to describe your fleet’s state is that a device is managed from the moment Setup Assistant ends and governed from the moment somebody signs in to an app.
Settle the phishing-resistant question before the first device ships rather than during the pilot, because the failure is at the enrolment screen in front of a new starter and the fix is a Conditional Access change that somebody will make in a hurry. Whatever you decide, write down the compensating control and the date you will revisit it. An exclusion with a reason attached is a design decision. An exclusion without one is what an auditor finds in three years.
The build sheet takes it from here: one iPhone, out of the box, through an enrolment policy, a single sign-on extension, a compliance policy and a Conditional Access grant, with the state you should see at every stage and what it means when you do not.
Apple Business
‹ Previous: [AB 8] Four Ways In, and What Each One Costs You
Next: [AB 9.1] Build Sheet: A Zero-Touch iPhone, Box to Conditional Access ›
