Supervised vs unsupervised: why half of Intune's iOS controls silently don't apply
You deployed an iOS device restrictions profile from Intune, saw no error, and the device carried on as if nothing happened. The missing prerequisite is almost certainly supervision — a device state you cannot switch on after the fact without erasing the device. Here is the capability split, how to check where you stand, and how to fix it properly.
The problem
An Intune administrator assigns a device restrictions profile to a group of iPhones or iPads. The portal reports the assignment; nothing errors. Yet on some devices the settings simply do not take effect: AirDrop still works, the web content filter never appears, apps still prompt the user for install consent, and — most alarmingly — the user can open Settings and remove the management profile entirely, walking the device out of management at any time.
This bites hardest in two situations:
- Corporate-owned devices enrolled the BYOD way. Someone set up company iPhones by installing Company Portal and enrolling by hand. They are managed, but unsupervised, so a large slice of the restriction catalogue silently does not apply to them.
- Mixed fleets. A single restrictions profile is assigned to all iOS devices — some ADE-enrolled and supervised, some not — and behaves differently across the two populations with no obvious error to explain why.
The failure is silent by design: Apple's MDM protocol lets an unsupervised device ignore supervised-only payload keys rather than reject the profile, so there is no red status to catch your eye.
Why it happens
Apple splits MDM capability by a device state called supervision. Supervision signals that the organisation owns the device outright, and Apple gates the strongest management controls behind it. Crucially, supervision is set at activation time. There are only two ways to get it:
- Automated Device Enrollment (ADE) through Apple Business Manager or Apple School Manager — the device comes out of the box supervised (all ADE enrolments are supervised on iOS 13 and later); or
- Apple Configurator, which erases the device as part of preparing it.
Enrolling through the Company Portal app (device enrolment) never supervises. There is no toggle, script or profile that supervises a device retroactively — gaining supervision always means an erase and re-enrolment.
The capability split
| Capability | Supervised (ADE / Configurator) | Unsupervised (Company Portal / BYOD-style) |
|---|---|---|
| Silent app installation | Yes — apps push without consent prompts | No — user must approve each install |
| Full restriction catalogue (block AirDrop, iMessage, app removal, defer OS updates, and many more) | Yes | Subset only — settings Intune marks (supervised only) are silently ignored |
| Web content filter | Yes | No |
| Single App Mode / kiosk | Yes | No |
| Non-removable management profile | Yes (ADE with the option locked) | No — the user can remove the MDM profile at any time |
| Activation Lock bypass | Yes | No |
| Managed Lost Mode | Yes | No |
| Forced OS updates / update deferral | Yes | No |
| Home screen layout and wallpaper | Yes | No |
Intune does mark supervised-only settings in the profile editor, but a profile containing them still assigns cleanly to unsupervised devices — the unsupported keys are dropped on the device without a deployment error, which is why the gap is usually discovered in an incident rather than a status report.
The fix
Things you can do today, in order:
- Find your unsupervised devices. In the Intune admin centre, open Devices > iOS/iPadOS and check the Supervised property (it is a column you can add and a field on each device's hardware pane, and it appears in device exports). On the device itself, a supervised iPhone says "This iPhone is supervised and managed by…" at the top of Settings.
- Audit your profiles for supervised-only settings. Open each device restrictions profile and note every setting labelled (supervised only). Anything you were relying on from that list is not applying to your unsupervised population.
- Adopt the rule of thumb: corporate-owned = ADE-enrolled and supervised, always. Register corporate devices in Apple Business Manager, assign them to your Intune MDM server token, and use an ADE enrolment profile with the management profile locked so it cannot be removed.
- Plan a re-enrolment wave for existing unsupervised corporate devices. There is no in-place upgrade: back up what matters, erase, and re-enrol through ADE. Devices bought outside a channel that feeds Apple Business Manager can be added to it using Apple Configurator — note the user can release the device from the organisation during a 30-day provisional period after that route, so schedule accordingly.
- Stop assigning supervised-only profiles to unsupervised devices. Split your restriction profiles in two (baseline vs supervised-only) and scope the supervised-only set with assignment filters or dedicated groups — for example keyed on the ADE enrolment profile name — so behaviour is predictable per population.
- Treat genuine BYOD differently. For personal devices, do not chase device restrictions at all: use User Enrollment and app protection policies to protect corporate data, and accept that the device itself belongs to the user — including their right to remove management.
The strategic point: decide device ownership before choosing the enrolment method, because the enrolment method permanently fixes what you can manage. Supervision is the clearest example in the Apple world of a prerequisite that cannot be bolted on later without destructive action.
How Decolla handles it
Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not enrol, supervise or manage iOS devices, so the steps above are yours to run in Apple Business Manager and Intune.
What Decolla does address is the general failure mode this niggle belongs to: settings that silently fail to apply, and prerequisites you discover only after deployment. On the Windows side, Decolla works from a written, itemised plan that you approve before anything runs. Every item in the plan states its delivery method and a reversibility class — automatically reversible, reversible, or flagged irreversible — so an "you'd have to wipe to undo this" situation is declared up front rather than discovered in production. After deployment, Decolla can roll back its own changes per item. Its Library of pre-built policies and fixes exists for the same reason this article does: most provisioning pain comes from prerequisites and side effects nobody wrote down.
Decolla is pre-launch; if that approach to Windows provisioning appeals, the waitlist is open at decolla.app.
Sources
- Hexnode: How supervised iOS devices differ from non-supervised devices
- Scalefusion: iOS supervised vs unsupervised — benefits of supervising iOS devices
- NinjaOne: Supervised vs unsupervised devices
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access