By the end of this you have an iPhone that went from a sealed box to a Conditional Access grant without an administrator touching it, and you have the eight checkpoints that tell you which half of the chain broke when it does not. Two of the decisions in step 1 cannot be revisited on that device without erasing it, which is why they are step 1 and not step 6.
The worked estate is CatSnackJack, continuing from Wave 1. It has a verified, federated Apple Business organization, the Verizon supplier link from [AB 6.1], seven Configurator-added devices from [AB 6.2], and the Intune connection from [AB 7.1]. The test device is a new iPhone that arrived on the Verizon account and appeared in the register on its own. Nothing in the estate is enrolled.
Prerequisites. An enrolment program token connected and syncing, with at least one unassigned device visible against it. An Apple MDM push certificate that is active in both Intune and Apple’s portal. Intune licences for the users who will enrol. Enough rights to create an enrolment policy, a device configuration policy, an assignment filter, a compliance policy and a Conditional Access policy, which in practice means Intune Administrator plus a Conditional Access role, and worth narrowing afterwards. A volume purchase location token with Microsoft Authenticator and Company Portal licences on it, because both apps are deployed rather than downloaded. And one iPhone you are willing to erase.
Surfaces. This is a browser walkthrough and that is the product rather than a compromise. Apple Business exposes no command line for any of this. On the Intune side, Microsoft documents no supported API for the new Enrollment policies experience; a beta Graph object for the older Profiles blade exists and a practitioner published a Graph migration script against it in July 2026, which is unsupported and out of scope here. The two retypable literals in this sheet are the filter rule and the dynamic group rule, and both are given in full because they are product expressions rather than commands, and both are exactly the kind of string that fails silently when it is mistyped.
Naming convention. Two of these names become properties of every device that enrols under them, so they are worth ten minutes now.
| Artefact | Convention | CatSnackJack value |
|---|---|---|
| Enrolment policy | Platform, then population, then a version ordinal. The ordinal is not decoration: you will create version two rather than editing version one, and both will exist at once. | iOS-Corp-UserAffinity-v1 |
| Assignment filter | The word filter, the platform, and what it selects | filter-iOS-Corp-UserAffinity-v1 |
| Dynamic device group | The word dyn, so nobody edits it by hand, then the population | dyn-Devices-iOS-Corp |
| Compliance policy | Platform, then the standard it encodes, not the settings it contains | iOS-Compliance-Baseline |
| Conditional Access policy | Your existing CA naming, which this sheet does not override | Per [CA 4] |
| Device name | A template, never a literal. Intune derives the name from tokens at enrolment and at each check-in. | Template {{DEVICETYPE}}-{{SERIAL}}, which is Microsoft’s own example and which produces a name you read off the device record rather than one you type anywhere. The rendered name is capped at 63 characters, so a long prefix plus a serial will silently truncate. |
The enrolment policy name is the one that matters most, because it is not only a label. It is written onto every device that enrols under it as the enrollmentProfileName property, and that property is what steps 6 and 9 target. Rename the policy later and you have orphaned the filter and the group with no error anywhere. Choose it as though it is immutable, because for your existing devices it effectively is.
Step 1. Settle the two irreversible decisions on paper
An Apple enrolment policy is read by the device once, during activation. Changes you make afterwards do not reach devices that have already enrolled, and Microsoft says so in an Important inside the policy creation steps: the new settings will not take effect until devices are reset back to factory settings and reactivated, with the device name template as the single exception, and naming template changes taking effect at the next check-in. [AB 9] argues why that is structural rather than a product gap.
Verification gate, and it is the first step rather than a review at the end because after step 4 there is nothing to verify. Before you create anything, get a written answer to both of the following from whoever owns the outcome, not from whoever is building it.
| Decision | What you are committing to | Cost of changing your mind |
|---|---|---|
| User affinity: with, without, or Microsoft Entra ID shared mode | Whether this population is people’s devices, shared devices, or frontline devices signing in and out | Microsoft refuses the edit outright. You must create a new policy, and every device already enrolled keeps the old answer until it is wiped. |
| Locked enrollment: Yes or No | Whether the user can remove the management profile from the Settings app | Silent. The policy saves, the setting changes in the portal, and no enrolled device notices. This is the worse failure of the two because it looks like it worked. |
Expected result: a one-page decision record naming the population, the two answers, the person who signed them off and the date. For CatSnackJack that is corporate-issued iPhones for named staff, user affinity, Locked enrollment Yes, signed off by the IT manager. The conversation took ten minutes and it is the reason the estate will not have three enrolment policies by Christmas.
While you are here, decide the other question that has no undo, which is the one in step 3. It is separated because it belongs to a different team.
Step 2. Clear the enrolment restriction that presents as a broken device
Do this before the policy exists, because the symptom it produces looks like a token or certificate fault and you will spend an hour in the wrong place.
In the Intune admin center go to Devices, expand Device onboarding, select Enrollment, then under Enrollment options select Device platform restriction. Select the iOS/iPadOS restrictions tab and open the default All Users policy. Note the control you are looking for is labelled MDM rather than Platform on this tab; Platform is the Android label.
| Setting | Value | Why |
|---|---|---|
| MDM, on the iOS/iPadOS restrictions tab | Allow | Microsoft’s warning is explicit: if the default All Users policy blocks the iOS and iPadOS platform, automated enrolment fails and the device shows as Invalid Profile, regardless of user attestation. A platform block is a wall rather than a filter, and a corporate device does not pass it. |
| Personally-owned | Block, if your intent is corporate only | This is Microsoft’s own instruction for expressing that intent: block only personally owned devices, which permits corporate devices to enrol. It works because ADE enrolment is itself the corporate ownership attestation. |
Verification gate on userless populations, and it is the finding in this sheet most likely to be new to you. If any part of the estate enrols without user affinity, including kiosks, Shared iPad and Microsoft Entra ID shared mode, then every restriction you have written except the default one is invisible to it. Microsoft’s restrictions article lists userless Apple automated device enrollment among the scenarios that are not user-driven and for which Intune enforces the default policy. Confirm before you go further: that the default All Users policy, not a higher-priority policy, allows iOS and iPadOS; and that nobody has scoped the platform allowance to a group, because for these devices the group is never consulted.
Two timing facts so you can interpret what happens next. Edits apply to new enrolments and do not affect devices that are already enrolled. And the assignment processing between Microsoft Entra and Intune typically completes within fifteen minutes rather than instantly, so a restriction change followed immediately by a test enrolment gives you a result you cannot read. Change it, then go and do step 3.
Expected result: the default All Users policy allows iOS and iPadOS, personally owned is blocked if that is your intent, and you have written down which policy you edited and at what time. [3.1.1] covers restrictions properly and this step is only the Apple-specific gate.
Step 3. Settle the multifactor question with the identity team
This step produces no configuration. It exists because the alternative is discovering the problem at an enrolment screen in front of a new starter, and then making a Conditional Access change in a hurry.
Microsoft’s statement, in a Caution box on one page: phishing-resistant multifactor authentication is not supported on Setup Assistant for iOS and iPadOS, and users enrolling via Automated Device Enrollment using Setup Assistant with modern authentication must have an alternate MFA method available to complete device enrolment.
Two facts make this sharper than it first reads. The built-in Phishing-resistant MFA strength permits only Windows Hello for Business or platform credential, a FIDO2 security key, and multifactor certificate-based authentication, and none of the three is available inside Setup Assistant on an out-of-box iPhone. And Microsoft’s own stated remedy for the enrolment case, a second device or a Temporary Access Pass, does not satisfy that strength either: Entra’s authentication strength table ticks Temporary Access Pass under Multifactor authentication strength only, and Microsoft’s passwordless guidance states plainly that a Temporary Access Pass is not phishing-resistant.
Verification gate before you ship a single device. Establish all of the following with whoever owns Conditional Access, and record the answers.
Whether any Conditional Access policy applies a phishing-resistant authentication strength to all resources, since that is the shape Microsoft’s own Entra guidance recommends and it is the shape that breaks this. Which of the two Intune resources your enrolment MFA policy targets, because they govern different legs: Microsoft Intune Enrollment, application ID d4ebce55-015a-49b5-a083-c84d1797ae8c, controls the enrolment workflow and is the one Microsoft’s own procedure targets, while Microsoft Intune, application ID 0000000a-0000-0000-c000-000000000000, additionally covers the Company Portal sign-in. Whether the enrolment resource exists in your tenant at all, because Microsoft documents that it is not created automatically for new tenants and has to be added by creating a service principal with that application ID. And whether anybody has configured device-based access rules for Intune enrolment, which Microsoft tells you not to do in an Important.
Two constraints to have in hand for that conversation. You cannot combine the Require multifactor authentication grant control and the Require authentication strength control in the same policy. And Microsoft’s ADE page says external authentication methods are supported for 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.
Microsoft documents no supported exclusion pattern for iOS. The nearest thing is a Windows out-of-box page that describes, without endorsing, a tenant that has excluded both Intune application IDs from a phishing-resistant strength policy. [CA 4.3] is this site’s article on protecting the bootstrap with a Temporary Access Pass, and this is the case where that pattern and Microsoft’s strongest recommendation point in different directions. [AB 9] argues the position I would take. The point of this step is that somebody decides it deliberately.
Expected result: a named decision, a named compensating control, and a review date. If the answer is an exclusion, the exclusion has a reason attached to it in writing. An exclusion without one is what an auditor finds in three years.
Step 4. Create the enrolment policy
In the Intune admin center go to Devices, expand Device onboarding, select Enrollment, then the tab for the Apple mobile platform family, then under Bulk Enrollment Methods select Enrollment program tokens. Open your token and select Enrollment policies, then create a policy.
Two navigation warnings, both carried from [AB 7.1] and both still true. Microsoft’s live articles disagree about whether that tab is called Apple or Apple mobile, and the disagreement is not in date order, so read the screen rather than trusting any procedure including this one. And make sure you are in Enrollment policies rather than Profiles: Microsoft states that the older Profiles experience differs, will not receive new features and is eventually retiring, with no date given.
Work through the policy in this order. The Why column is the part worth reading; the values are the easy half.
| Setting | Value | Why |
|---|---|---|
| Name | iOS-Corp-UserAffinity-v1 | This string is written onto every device as the enrollmentProfileName property and is what steps 6 and 9 target. Renaming it later orphans both with no error. |
| Description | The population, the decision record reference, and the date | The only field in the policy that can tell a future administrator why the immutable settings are what they are. |
| Device group tab | Leave empty, or select a static security group if you are using enrolment time grouping | This tab is enrolment time grouping and it is easy to walk past. Only static Microsoft Entra security groups appear here, and the picker returns nothing unless you hold the enrollment time device membership assignment permission in a custom role under Enrollment programs. See the aside in step 6 before you use it. |
| User affinity | Enroll with User Affinity | The decision from step 1. Microsoft will not let you change it in an existing policy at all. Every user on such a device needs an Intune licence. |
| Authentication method | Setup Assistant with modern authentication | The only option that authenticates the person against Microsoft Entra ID and establishes affinity at the Setup Assistant screen. Company Portal is the alternative in the picker, and it is blocked outright if the user is targeted by an account-driven Apple user enrollment policy. Read the picker. The enrolment policy article lists two options and the step immediately after it refers to Setup Assistant (legacy), while the authentication methods reference it links to documents four current methods with legacy as Option 4. What the reference tells you is that legacy still exists as a method, not whether it is selectable in this blade. |
| Install Company Portal | Yes, if the setting is present | Deploying it through Intune is the only way to reach already-enrolled devices and to get automatic updates. Do not tell users to install the App Store version. Two practitioners writing in 2025 and 2026 report this setting is gone or automatic in the new blade while the May 2026 article still documents it, so this is a read-the-screen item and not a typo in this sheet. |
| Install Company Portal with VPP | Your location token, if the setting is present | Without it the app installs only if the user signs in to the store, and if the app never installs the device never registers with Entra. This is the documented route from a working enrolment to a permanently ungoverned device. |
| Run Company Portal in Single App Mode until authentication | No. Note it only appears at all if you selected a token for Install Company Portal with VPP | Microsoft states that multifactor authentication is not supported on a device locked in Single App Mode, because the device cannot switch apps to complete the second factor. It also appears in the documented trigger configuration for the stuck-at-enrolment-screen failure, although that configuration additionally requires Company Portal authentication, which this policy does not use. |
| Supervised | Yes | Apple supervises ADE-enrolled iPhones automatically from iOS 13 and Intune ignores the flag on those devices, so this is belt and braces rather than the thing that produces supervision. Set it to Yes anyway. Apple’s provisioning API rejects a non-removable management payload unless the supervision flag is true, with the error name FLAGS_INVALID, and a device that somehow enrols unsupervised can only be fixed with Apple Configurator over USB. |
| Locked enrollment | Yes | The decision from step 1. Hides the button in the Settings app that removes the management profile. Two carve-outs: on devices added to Apple Business after purchase rather than bought through it, the button stays visible for the first thirty days after activation; and regardless of this setting, Remove Device and Factory Reset in the Company Portal are unavailable on ADE devices anyway, in the app and on the website. |
| Shared iPad | No | Not applicable to iPhone, and a policy with Shared iPad enabled sent to an unsupported device requires a wipe. Also note that changing a Shared iPad configuration away from temporary sessions later needs a full reset and a new policy. |
| Await final configuration | Yes | Setup Assistant pauses just before the home screen and lets Intune check in, so the device arrives configured rather than acquiring configuration while the user explores it. Yes is the default for new policies and No for existing ones, which catches anyone who cloned. Only device configuration policies install during this screen; applications do not. |
| Activate cellular data plan | No, unless you have eSIM devices and a carrier activation server | Present in the flow and irrelevant to most builds. It is listed here so you know you have not missed a page. |
| Device name template | Enabled, with the template from the naming convention | The only setting in the whole policy you can change afterwards, because it is not carried in Apple’s profile. Intune renames by command at enrolment and at each check-in. Never write the resulting name into a document; read it off the device record. |
| Department and Department Phone | Your service desk name and number | Department appears when the user taps About Configuration during activation. Department Phone appears when they tap Need Help. They are the only thing a confused user has to look at, and a blank one reads as a phishing attempt. |
Setup Assistant screens. Each screen is Show or Hide. Hide means the screen is not shown during setup and the user can still configure the feature afterwards from Settings. Two of them are documented as broken and should be hidden on every current device: Microsoft states that the Passcode screen and the Touch ID and Face ID screen do not work correctly on devices running iOS 14.5 and later, and tells you to hide both and enforce passcodes through a compliance or configuration policy instead. Step 8 does exactly that.
Two of the entries in that list are recent enough to be missing from anything you read last year, Multitasking and OS Showcase, both from iOS and iPadOS 26.0. Two are marked deprecated, Zoom at iOS 17 and Display Tone at iOS 15. And one caution Apple publishes that Intune does not repeat, attached specifically to the Passcode and password lock pane: it is not skipped if it appears before the device retrieves the configuration from the server. That is a single-pane exception rather than a general excuse. Any other hidden pane that appears anyway is a fault worth chasing.
Worked example. CatSnackJack hides Apple ID, Terms and conditions, Apple Pay, Siri, Diagnostics Data, Screen Time, iMessage & FaceTime, Passcode, Touch ID and Face ID, Restore, Android Migration, Watch Migration, Appearance, Intelligence and OS Showcase, and shows Location Services and Software Update. The reasoning is a single sentence you can defend: hide anything that asks the user to make a decision the organisation has already made, and show anything whose absence would leave the device less functional or less current. Fifteen hidden screens is roughly ninety seconds off the out-of-box experience, which sounds trivial until it is a hundred and twenty devices.
Expected result: the policy exists and appears in the list under the token. No device has changed.
Step 5. Assign the policy, and decide the default deliberately
Assignment happens against the token’s device list. You can assign the policy to selected serial numbers, and you can set it as the default policy for the token so that devices arriving in future are handled without anybody remembering.
Set the default. The failure it prevents is documented and unhelpful: if a device you synced from Apple is not assigned an enrolment policy and somebody turns it on to set it up, enrolment fails. A device with no policy is not a device that waits politely; it is a device that has to be erased.
Then assign explicitly to the serial number of your test device, whether or not the default already covers it, because you want the assignment visible on the device record when you check it in step 10.
The ordering trap that has its own troubleshooting article. If the enrolment policy was created before the enrolment program token was uploaded, enrolment never starts. Microsoft’s fix is to edit the policy, change anything at all because the purpose is to update its modification time, and then synchronise the ADE-managed devices. Note the shape of that instruction against step 1: editing a policy is inert on activated devices and effective on devices that have never activated. The variable is whether the device has been switched on, not what you edited.
Expected result: the policy is the token default, your test serial shows the policy assigned, and the device has still never been switched on.
Step 6. Build the targeting, and use the right mechanism for each half
This is the step most builds get wrong, and the failure is silent: everything is configured correctly and the policies arrive too late to matter.
There are two ways to target an ADE fleet by the policy it enrolled under, they use the same property name, and they behave completely differently in time.
| Intune assignment filter | Microsoft Entra dynamic device group | |
|---|---|---|
| What it can target | Intune workloads: compliance policies, configuration profiles, apps, app configuration | Anything a group can target, including Conditional Access and licensing |
| When it resolves | At the first check-in, with no further evaluation delay once the assignment itself has propagated, which Microsoft puts at up to fifteen minutes. | After an Entra device object exists, then whenever dynamic processing gets to it |
| How long that takes | Immediately | Microsoft gives four answers across two pages: less than a few minutes for small directories, thirty minutes or longer for large ones, typically within a few hours, and processing can take more than twenty four hours. Plan against the last one. |
| On a zero-touch iPhone | Works from the first check-in, because it reads Intune’s own property | Cannot contain the device until the second sign-in has created the Entra object |
So the rule for this build is: everything Intune delivers goes through an assignment filter, and only Conditional Access goes through the group.
The filter. Go to Tenant administration, then Assignment filters, then Create. The first thing the wizard asks is Managed devices or Managed apps: choose Managed devices, because a managed apps filter will not attach to a compliance policy. Platform is iOS/iPadOS. The rule is a literal you retype:
(device.enrollmentProfileName -eq "iOS-Corp-UserAffinity-v1")Replace the quoted string with your own policy name exactly as you typed it in step 4. Microsoft documents the property as case insensitive along with the operators, and supports the full-string operators -eq, -ne, -in and -notIn, plus the partial-match operators -startswith, -contains and -notcontains. A filter that matches nothing produces no error and no policy; the failure mode is an assignment that reports success against zero devices.
The group. In the Microsoft Entra admin center create a Security group with membership type Dynamic Device. The rule, again a literal:
device.enrollmentProfileName -eq "iOS-Corp-UserAffinity-v1"Microsoft’s own worked example uses the same property with the same shape. One interface detail that will otherwise cost you five minutes: the rule builder is available only for user-based dynamic membership groups, and device-based dynamic groups can be created only by using the text box. Two limits worth knowing, one of which Microsoft states two ways: the reference article caps a tenant at 15,000 dynamic membership groups and the troubleshooting article says 5,000 with no way to raise it, so plan against 5,000. The membership rule body cannot exceed 3,072 characters.
Two behaviours to expect rather than debug. There is no supported on-demand reprocess; Microsoft’s documented way to trigger one manually is to edit the membership rule by adding a trailing whitespace. And changing a rule removes existing members who no longer match, so a rule edit on a live group is a membership event and not a metadata change.
The feature that addresses the ordering problem directly. Enrolment time grouping became generally available for Apple ADE on iOS, iPadOS and macOS in June 2026. In Microsoft’s words, you can identify a device’s Microsoft Entra security group during enrolment, so policies, apps and settings can be applied earlier in the setup process. The prerequisites are the part that stops people, and there are four. The group must be a static Microsoft Entra security group; dynamic groups do not appear in the picker. You must add the Intune Provisioning Client service principal as an owner of that group, application ID f1346770-5b25-470b-88bd-d5744ab7952c, and Microsoft notes that in some tenants the same principal is named Intune Autopilot ConfidentialClient instead. To add a first-party app as a group owner you need to be a Microsoft Entra Group Administrator or an existing owner. And you need the enrollment time device membership assignment permission in a custom Intune role, under Enrollment programs, before the picker returns anything at all. Two further constraints worth knowing before you design around it: the feature applies to new device enrolments rather than to devices already enrolled, and Microsoft records a known issue that the Remove option for the group is unavailable when you edit an existing enrolment policy, so adding one is easier than taking it away. It is also unavailable in some sovereign clouds.
Expected result: a filter that resolves to your test device’s enrolment policy name, and a group that is currently empty and will stay empty until step 11.
Step 7. Deploy Microsoft Authenticator, then activate the extension it contains
The order of the words in that heading is the whole point of the step. The single sign-on extension is not delivered by the Intune policy. Microsoft’s own wording, which lives on the Apple device features reference rather than on any page about enrolment: the Authenticator app delivers the Microsoft Enterprise single sign-on plug-in to devices, and the MDM single sign-on app extension settings activate the plug-in.
A correctly configured extension policy on a device without Authenticator is inert. It reports success. Nothing happens.
7a. Assign Microsoft Authenticator as a required app. Go to Apps, then All apps, and assign Microsoft Authenticator to the target groups as a required app. Deploy it from your volume purchase location token rather than leaving it to the store, for the same reason the Company Portal is deployed that way: a user who never signs in to the store never receives it, and a device without it never registers.
7b. Create the single sign-on app extension policy. Go to Devices, then Manage devices, then Configuration, and create a policy for platform iOS/iPadOS, profile type Templates, template Device features, and open the Single sign-on app extension section.
| Setting | Value | Why |
|---|---|---|
| SSO app extension type | Microsoft Entra ID | Selects the Enterprise single sign-on plug-in that ships inside Authenticator. |
| App bundle IDs | Non-Microsoft apps only | Microsoft states the extension automatically applies to all Microsoft apps, and that adding them causes authentication problems. Do not add the Authenticator bundle ID either. See the Defender exception below. |
| Additional configuration, key one | Key device_registration, type String, value {{DEVICEREGISTRATION}} | This is the entire just-in-time registration feature. Without it the extension does single sign-on and never registers the device. |
| Additional configuration, key two | Key browser_sso_interaction_enabled, type Integer, value 1 | Microsoft marks it recommended and attaches the same hard warning as the required key. It lets users bootstrap the extension from Safari and from apps that do not use the Microsoft authentication library, and Microsoft separately states it is required for compatibility with Conditional Access policies and password change events. |
Verification gate on those two key-value pairs, because the failure is invisible and Microsoft warns about it twice on one page. Its words: remove trailing spaces before and after the value and the key, otherwise just-in-time registration will not work. Before you save, confirm three things. That the key names contain no leading or trailing space, which is easiest to prove by clicking into the field and pressing End rather than by looking. That the value {{DEVICEREGISTRATION}} is typed with two braces at each end and in that case, since the field accepts anything. And that the type of the second key is Integer rather than String, because the field offers String, Boolean and Integer and a string 1 is not the documented value.
Assign the policy to All devices, then on that assignment select the filter from step 6 in Include mode. A filter narrows an assignment; it is not a target in its own right, and there is nowhere to select one without first selecting a group. Microsoft’s own worked equivalent of this build does exactly that: assign to All devices, then add the assignment filter.
The Defender instruction that does not apply here, and it circulates as though it does. Microsoft’s Defender for Endpoint iOS deployment article tells you to add the Defender bundle ID com.microsoft.scmx to this policy alongside the registration key. Read the heading above that instruction: it sits under User Enrollment setup and is scoped to Intune user-enrolled devices, which is the bring-your-own-device path rather than this one. On a supervised ADE build the just-in-time registration guidance stands and you add no Microsoft bundle IDs at all. What does apply here is the other Defender note: if your organisation uses 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 checkpoint 7’s failure mode, so name Teams in the user instruction rather than leaving app order to chance.
Expected result: Authenticator is a required app against the target, and the extension policy is assigned through the filter. Nothing on the device yet.
Step 8. The compliance policy, which is a thinner surface than you expect
Go to Endpoint security, then Device compliance, and create a policy for iOS/iPadOS. Microsoft’s own create-policy article routes through Devices, then Manage devices, then Compliance instead, so read the screen rather than either path. The whole authority available to you on this platform is a managed email requirement, passcode, operating system version and build, jailbreak detection, a mobile threat defence device threat level, a Defender for Endpoint machine risk score, and a restricted app list. Those last two are separate settings in separate sections rather than one. There is no encryption toggle, because on iOS encryption follows the passcode; no firewall; no antivirus; and no custom compliance script.
| Setting | Value | Why |
|---|---|---|
| Jailbroken devices | Block | The cheapest control in the policy. Supported for iOS 17.0 and later. |
| Minimum OS version | Your supported floor, written as a version | Set it at a version you will actually maintain. A floor nobody updates becomes a floor that blocks the fleet after an Apple release. |
| Minimum OS build version | Consider it, and understand what it buys | Microsoft’s own note: when Apple publishes security updates the build number is typically updated rather than the OS version. If your standard is “patched”, the build number is the field that expresses it and the version number is not. |
| Require a password to unlock mobile devices | Require | This is where the passcode requirement lives, because step 4 hid the Setup Assistant passcode screen on Microsoft’s own instruction. Expect the documented user experience: after the policy applies, users are prompted to set a passcode every fifteen minutes until they do, and encryption starts automatically when they do. |
| Minimum password length, Required password type, Maximum minutes after screen lock before password is required | Your standard | These three carry an iOS 17.0 and later qualifier in the interface. Maximum minutes of inactivity until screen locks does not, which is worth knowing when you are reading the blade and wondering why the qualifiers are inconsistent. |
| Restricted apps | Use sparingly, if at all | Microsoft states this applies to unmanaged apps installed outside the management context. It is a blunt instrument and it produces noncompliance rather than removal. |
Assign it to All devices with the step 6 filter in Include mode, as in step 7.
Verification gate on the tenant setting, which is the one nobody checks and which quietly inverts the meaning of your Conditional Access policy. In Endpoint security, then Device compliance, open Compliance policy settings and read Mark devices with no compliance policy assigned as. Its default is Compliant, which means a device with no policy passes. Microsoft’s own guidance is that if you use Conditional Access with compliance policies you should change it to Not compliant to ensure that only devices confirmed as compliant can access resources. Change it and you have made a tenant-wide change affecting every platform, so do it with the change record rather than while you are here. Leave it and know that you have left it, because a Conditional Access policy requiring compliance is doing nothing for any device your filter missed.
While you are on that page, note the Compliance status validity period (days), default 30, configurable from 1 to 120. A device that fails to report for longer than that is treated as noncompliant, which is the control that catches a device that quietly stopped talking to you.
Expected result: one compliance policy assigned through the filter, and a recorded decision about the tenant default.
Step 9. The Conditional Access grant
This step is deliberately short, because [CA 1] and [CA 4] own Conditional Access and this series does not rebuild it. What belongs here is only the Apple-specific shape.
Target the dynamic device group from step 6, not the filter, because Microsoft states plainly that assignment filters are for Intune workloads and that Conditional Access needs a group. Require the device to be marked as compliant. Then read step 3’s decision record and apply whatever you agreed there about authentication strength, remembering that both Intune resources reach the Setup Assistant prompt and neither of them is the resource behind the registration sign-in, which happens against the app the user opens.
Verification gate before you enable it, because the failure mode is locking a population out of everything. Confirm in report-only mode first, on your test user only, and confirm three things before you flip it. That the dynamic group contains your test device, which it will not until step 11 has completed and dynamic processing has caught up. That your break-glass accounts are excluded, per [CA 4.4]. And that you have not created a circular dependency in which the device must be compliant to register and must register to be evaluated for compliance.
Expected result: a report-only policy targeting the group, with nothing in the group yet.
Step 10. Sync, and read the device record before you touch the device
In the token’s device list, synchronise. The constraints are worth knowing before you sit there pressing the button: a manual sync no more than once every fifteen minutes, all sync requests have fifteen minutes to finish, an automatic delta sync every twelve hours, a full sync no more than once every seven days, and roughly three thousand devices per minute of throughput.
Then read three things on the device record for your test serial. That the device is present. That the enrolment policy assigned to it is the one you built. And that its profile status is not Blocked, which is the diagnostic filter Microsoft points at for the volume purchase token failures.
Expected result: the serial is present, the policy is named on it, and the profile status is clear. If any of those is wrong, fix it here rather than at the Setup Assistant screen, because at the Setup Assistant screen the remedy is an erase.
Step 11. The end-to-end test, in eight checkpoints
Nothing so far proves anything about a device. It proves a set of objects exist and reference each other. Take the sealed iPhone, hand it to the person it belongs to, and watch.
Do not use your own administrative account for this. The user affinity, the licence check, the multifactor prompt and the Conditional Access evaluation are all properties of the person, and an administrator with different licences and different policy assignments will produce a test that passes for a fleet that fails.
| Stage | Expected output | What it proves | |
|---|---|---|---|
| 1 | Power on, choose language and network | A Remote Management pane naming your organisation, with the department and phone number from step 4 | The device asked Apple who owns it, and Apple answered with your organization. The token, the assignment and the sync are all working. |
| 2 | Continue past Remote Management | A Microsoft sign-in page inside the Setup Assistant window | The authentication method is Setup Assistant with modern authentication and the configuration web URL resolved. If you see the setup finish with no sign-in, the policy in force is not the one you think. |
| 3 | The user signs in and completes multifactor authentication | Sign-in succeeds using whatever method step 3 settled on | The multifactor decision was correct. A device that stalls here with a valid password is the phishing-resistant conflict, not a network fault. |
| 4 | The Setup Assistant screens you chose to show | Only those, in Apple’s order | The skip keys applied. Any screen you hid that appears anyway is one of Apple’s pre-configuration panes. |
| 5 | Awaiting final configuration | A locked screen, then the home screen. Microsoft’s product-validation observation was that most devices they tested reached the home screen within fifteen minutes, with no minimum or maximum enforced. | Await final configuration is on and Intune is delivering device configuration policy. Applications are not included in this wait. |
| 6 | Read the device in Intune, and read the user’s device list in Microsoft Entra ID, side by side | Intune shows the device enrolled, corporate and supervised. Its compliance state may read Not evaluated, which is the documented initial state for a newly enrolled device and matches the authentication methods reference saying the device will not be evaluated for device compliance; the enrolment guide says instead that it shows as compliant in the Intune admin center. Entra either does not list the device or lists it as non-compliant, and Microsoft’s own two sentences disagree about which. Read both surfaces and record what you actually saw. | This is the window, and seeing it is the point of the checkpoint. The device is fully managed and Conditional Access has nothing to evaluate. Everything up to here has worked and the device is ungoverned. |
| 7 | Wait for Microsoft Authenticator to install, then have the user open Microsoft Teams and sign in | Sign-in completes, possibly with a brief spinner while compliance is checked, and the user reaches their messages | The extension activated and just-in-time registration ran. Microsoft’s just-in-time registration article recommends pointing employees to the Microsoft Teams app by name, on the grounds that it is integrated with the latest identity libraries. If Authenticator has not landed yet the user gets an error and should wait a few minutes rather than retrying in a loop. |
| 8 | Read Entra again, then read the Conditional Access sign-in log for that session | A device object exists, registered rather than joined, and the sign-in log carries the device ID with a compliant state | The window closed. This is the first moment the device is governed rather than merely managed, and it is the outcome the whole of Waves 1 and 2 exist to produce. |
Two things to know about the timing so you do not misread a slow success as a failure. A newly enrolled iOS device checks in roughly every fifteen minutes for the first hour and then around every eight hours, so if the first compliance evaluation misses, the next unattended one is a long way off and the user can force it by opening the Company Portal and syncing. And the dynamic group from step 6 will not contain the device the instant registration completes; Microsoft’s own answers range from a few minutes to more than twenty four hours. Until it does, your Conditional Access policy has no device to apply to, which is exactly why step 9 is in report-only mode.
When checkpoint 8 passes, enable the Conditional Access policy for real and repeat checkpoints 7 and 8 on a second device. A report-only pass is evidence that the policy would have matched. It is not evidence that the grant works.
Step 12. The failures you will actually see
Every entry here is a documented cause. Check them in this order, because they are sorted by how often they are the answer rather than by how interesting they are.
| What the device or the portal says | Documented cause | What to do |
|---|---|---|
| The configuration could not be downloaded: Invalid Profile | Blocked by a device type restriction, regardless of user attestation | Step 2. Allow the iOS and iPadOS platform in the default All Users policy and block personally owned instead. Then erase and retry. |
| Enrolment never starts at all | The enrolment policy was created before the token was uploaded. A second documented cause is no management profile assigned to the device. | Edit the policy to change anything, which updates its modification time, then synchronise ADE-managed devices. |
| Stuck on Awaiting final configuration or on a Guided Access message for more than ten minutes | An Apple service outage, or a problem with the volume purchase token. Microsoft documents five exact strings: the token has expired, is out of Company Portal licences, is being used by another service, is being used by another tenant, or was deleted. | Filter the token’s device list by Profile status equals Blocked and note the serials. After fixing the token you must wipe the blocked devices. |
| Setup sticks immediately after credentials are entered | Multifactor authentication with the authentication method set to Setup Assistant (legacy), which does not support it | Change the authentication method. On a new build this means the wrong policy applied. |
The SCEP server returned an invalid response. | Microsoft documents a fifteen minute time limit on SCEP certificates, and this appears in the ADE with user affinity flow | Retry the management profile download immediately. After fifteen minutes the documented remedy is a factory reset. Do not investigate first; the window is the constraint. [12.3.2] for the wider certificate picture. |
XPC_TYPE_ERROR Connection invalid | A connection issue between the device and the Apple enrolment service | Change network and retry. Microsoft’s own escalation is to contact Apple if it persists. |
| User Name Not Recognized, or the account is not authorized to use Microsoft Intune | The user has no Intune licence | Licence the user. Devices with user affinity require it; userless devices need a device licence instead. |
| Couldn’t map device record with a user, after signing in to Company Portal | The device does not meet the OS requirement, so it cannot create the Entra device record used to evaluate Conditional Access. OS version restrictions do not block ADE enrolment itself. Microsoft scopes this specifically to ADE enrolments that authenticate with Company Portal, so if you built the policy in step 4 you are not in that flow and step 7 is the better place to look. | Update the device. The enrolment succeeded and only the registration failed, which is the window becoming permanent. |
| Everything is green in Intune and Conditional Access still refuses | Two candidates. The device may never have registered with Entra, which is checkpoint 6. Or the app being used may not present a device identity: a practitioner writing in July 2026 reports native Mail, Apple Internet Accounts, Safari and Safari web view sign-ins failing with no device ID in the sign-in log at all, while Outlook and Authenticator worked, and attributes it to the single sign-on extension configuration. | Read the sign-in log and look for whether the device ID is absent or present and noncompliant. Absent is an identity presentation problem and points at step 7. Present and noncompliant is a compliance problem and points at step 8. |
| Users are asked to sign in to the Company Portal and download a management policy they have already installed | An app configuration policy for the Company Portal deployed manually, conflicting with the one Intune pushes automatically during enrolment | Remove the manual one. Intune sends it by itself when Install Company Portal is set to Yes. |
| A one-time Microsoft Entra join failure on the very first device in the tenant | Documented as a one-time failure affecting one device per tenant | Sync the device manually from the admin center or the Company Portal, which resolves it for all future enrolments. Microsoft’s alternative workaround is to add the Microsoft Intune Certificate Authority client production app with application ID 3dde09a2-ff4f-4ebd-9b9a-d24a7a819b6f. |
One diagnostic habit worth building from that last-but-two row, because it collapses a whole class of investigation. When a compliant device is refused by Conditional Access on iOS, the first question is not why the device is noncompliant. It is whether the device appeared in the sign-in log at all.
Completion checklist
A decision record exists naming the population, the user affinity answer, the Locked enrollment answer, and who signed them off. The default All Users device platform restriction allows iOS and iPadOS, personally owned is blocked if that was the intent, and somebody has confirmed that any userless population is covered by the default policy rather than by a scoped one. The multifactor question has a written answer, a named compensating control and a review date, and whoever owns Conditional Access gave it. An enrolment policy exists under a name you are willing to live with, because it is written onto every device that enrols under it. That policy is the token default, so a device that arrives unassigned cannot reach a user. An assignment filter on the enrolment policy name narrows everything Intune delivers, and a dynamic device group on the same property carries only Conditional Access. Microsoft Authenticator is a required app deployed from a volume purchase token, and the single sign-on extension policy is assigned to All devices with the filter in Include mode, and both key-value pairs are verified free of trailing spaces. A compliance policy is assigned the same way, and the tenant setting for devices with no compliance policy is a decision rather than a default. One device has gone from sealed box to a Conditional Access grant with an ordinary user account, and somebody watched checkpoint 6 happen and understood what they were looking at. And the enrolment policy is under a version ordinal, because the next change to it will be a new policy rather than an edit.
What this build does not give you is a way to change your mind. Every setting in step 4 except the device name template is now fixed for every device enrolled under this policy until that device is erased. Treat the next revision as a new policy, assign it forward, and let the old population age out. The alternative is an estate whose stored configuration and actual configuration diverged the first time somebody edited a policy and saw it save without an error.
Next in this series: web enrolment and BYOD, for the device that is already in somebody’s hand and cannot be wiped.
Apple Business
‹ Previous: [AB 9] Zero Touch: Enrollment Policies and the Authentication Decision
