The MAM article in this phase argued that iOS has no middle ground, and nothing here retracts that. But when device enrollment of a personal iPhone is the deliberate call, or when the lightweight path genuinely earns its complexity, both builds changed underneath the documentation most teams still follow. Device enrollment is browser first now, and account-driven User Enrollment is the only user enrollment left standing. This is the build for each, and the argument for which.
Web-Based Device Enrollment
Device enrollment for personal iOS devices now comes in two flavors sharing one enrollment type profile screen: the traditional Company Portal app flow, and web-based enrollment, which runs entirely in Safari and the Settings app on iOS 15 and later. The web flavor is the one to build. Create the enrollment type profile with Web based device enrollment selected, assign it to the BYOD group, and pair it with just-in-time registration: a single sign-on app extension policy carrying the Microsoft bundle identifiers and configuration pairs, so Entra registration and compliance checks happen inside the work apps instead of through repeated sign-ins. Recommend Authenticator ahead of enrollment; the flow leans on it. Devices on iOS 14.9 or earlier assigned this profile fall back to the app-based flow automatically, which is the right kind of backward compatibility: invisible.
Two behaviors are worth knowing before the first pilot user hits them. Apple requires the management profile download to happen in Safari, and the user has a limited window to finish installing it in Settings once downloaded; a user who wanders off mid-flow starts over, which is a briefing note, not a defect. And new enrollments now receive ACME certificates rather than SCEP, a quiet upgrade in certificate hygiene that costs nothing and requires nothing.
The Company Portal app is the wrong self-service surface for a device that never needed it to enroll.
That pullquote is a real defect, not a philosophy. There is a known issue where the Company Portal app cannot recognize a web-enrolled device that lacks the SSO extension policy, which produces the worst kind of ticket: a user staring at an app insisting their enrolled device is not enrolled. Deploy the Company Portal website as a web app for self-service instead, and if the native app must be in the picture, make sure the SSO extension policy and Authenticator reach the device after enrollment.
Account-Driven User Enrollment, If You Must
The profile-based User Enrollment that ran through Company Portal is deprecated and closed to new enrollments, so the lightweight path has exactly one door: the user adds their work account under VPN and Device Management in Settings, and the enrollment profile installs silently into a separate work partition. Three prerequisites make or break it. Managed Apple IDs, which means federating Apple Business Manager with Entra unless you enjoy provisioning Apple accounts by hand. The same JIT registration setup as above, with Authenticator as a required app. And service discovery, which is where most first attempts die.
Service discovery is a single JSON document published at https://yourdomain/.well-known/com.apple.remotemanagement, on the same domain users sign in with. The file carries your tenant ID in the BaseURL, must be served with a content type of application/json, and must be saved without a file extension – a .json suffix breaks it. HTTP redirects are permitted, so the file can live on a different server than the domain implies. Validate it with a curl of the well-known URL, with and without the user-identifier query parameter Apple appends, checking the content type header both times. When discovery is wrong, users see Apple’s marvelously unhelpful “Your Apple ID does not support the expected services” error, which says nothing about JSON and everything about it. Apple added a fallback that lets devices on iOS 18.2 and later fetch discovery through Apple Business Manager instead, but Intune does not support that fallback as of early 2026, so the hosted file remains mandatory for now.
One interaction bites mixed environments: users targeted by an account-driven user enrollment policy will fail Automated Device Enrollment flows that authenticate through the Company Portal. Corporate iOS enrollment in the same tenant should authenticate with Setup Assistant with modern authentication, which coexists cleanly.
Choosing Between Them
The design argument from earlier in this phase still governs: MAM-only remains the default for personal iPhones, and neither build here changes that. Account-driven User Enrollment earns its service discovery file in exactly one common case, line-of-business apps on BYOD, because app protection policies do not support LOB apps and the work partition does. Web-based device enrollment is the call when both sides genuinely accept platform-level management of a personal device, and its only honest advantage over the old app flow is friction: fewer steps, no store visit, less abandonment. Choose the model first, as the design article insists, and let these builds be plumbing rather than policy. Plumbing is what they finally are.
Intune Deployment Guide · Phase 9: Mobile and BYOD
‹ Previous: [9.4.2] iOS Supervised Mode: What It Unlocks and What It Still Can’t Do
Next: [9.5] App Protection ›
