HomeKb › Intune ios supervised vs unsupervised
Knowledge base · iOS / iPadOS

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:

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:

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

CapabilitySupervised (ADE / Configurator)Unsupervised (Company Portal / BYOD-style)
Silent app installationYes — apps push without consent promptsNo — user must approve each install
Full restriction catalogue (block AirDrop, iMessage, app removal, defer OS updates, and many more)YesSubset only — settings Intune marks (supervised only) are silently ignored
Web content filterYesNo
Single App Mode / kioskYesNo
Non-removable management profileYes (ADE with the option locked)No — the user can remove the MDM profile at any time
Activation Lock bypassYesNo
Managed Lost ModeYesNo
Forced OS updates / update deferralYesNo
Home screen layout and wallpaperYesNo

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

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