Intune iOS update policy not working: what each status means

An Intune iOS update policy that is not working usually does report something, just rarely in words: 0x87d13c28 on one iPad, -2016330697 on another, and nothing at all for the devices that are fine. This post decodes those statuses, separates the two kinds of iOS update policy Intune now runs, and puts the causes Microsoft documents in the order I would check them.

Most public answers to this question are forum threads, and most of them predate the move to declarative device management (DDM), so the fix offered often belongs to the other policy type. If the symptom is wider than updates, start from which Intune layer an update fault sits in. Every Microsoft fact below was checked against Microsoft Learn on 26 October 2026.

Two kinds of Intune iOS update policy, with different rules

Intune now has two ways to update an iPhone or iPad, and they fail differently. The older one is the MDM-based policy under Devices > Apple updates > iOS/iPadOS update policies. The newer one is a settings catalog policy in the Declarative Device Management category. Microsoft’s page on MDM-based iOS/iPadOS update policies now opens with a warning: “Apple has deprecated MDM-based software update workloads. To align with this change, Microsoft Intune will soon end support for MDM-based Apple software update policies.” The page gives no end date.

The row that matters most is the OS scope. Microsoft documents the MDM-based policy as applying to iOS 10.3 to iOS 18 and iPadOS 13.0 to iPadOS 18. An iPhone on iOS 26 sits outside that documented scope. I have not tested what the legacy policy does on an iOS 26 device and Microsoft does not say, but if the stuck devices are on 26.x and the policy is the old kind, I would stop troubleshooting the policy and move those devices to DDM, which the Apple update policy configuration page documents for iOS/iPadOS 17.0 and later.

The Intune iOS update policy status codes, decoded

The legacy policy reports per-device status as a hex code in the portal, and forum posts quote the same code as a negative decimal. Both come from one Microsoft Graph enum, iosUpdatesInstallStatus, which lists every name and value and gives no description for any of them. The hex column is my conversion of the documented decimal. The last column is my reading of the member name, not Microsoft’s.

Three of these account for most of the public threads. 0x87d13c28 is downloading; the answer on the Microsoft Q&A thread about it was to wait, and a later commenter reported devices that download and then still need the user to accept the prompt. 0x87d13c33 is notSupportedOperation, which answers on Microsoft Q&A attribute variously to a device not enrolled through Automated Device Enrollment, to a target older than the installed version, and to a target the hardware cannot run. 0x87d13c37, quoted in forums as -2016330697, is updateError, the least informative of the set.

Why a legacy policy reports nothing, or stops short

Work down this list in order. Each step is cheaper to check than the one after it.

1. Supervision. Microsoft is explicit that the MDM-based policy manages devices “enrolled as supervised devices”, and defines a supervised device as one that “enrolls through one of Apple’s Automated Device Enrollment (ADE) options.” A device the user enrolled through Company Portal is not supervised, and the policy has nothing to act on. If supervision itself is in doubt, check the Automated Device Enrollment token in Apple Business Manager before anything else.
2. The device is already ahead. Microsoft states that you cannot use Intune software update policies to downgrade the OS version. A policy pinned to an old version reports against every device that has since moved on.
3. An older version with no deferral. If you select a previous version rather than the latest, the page says you must also deploy a device configuration policy to delay visibility of software updates. Without it, users can see and install something newer, and the policy and the device disagree about what success looks like.
4. The deferral and the schedule are separate controls. Microsoft notes that software update policies “install updates based on their own schedule, regardless of the update being hidden or visible to the device user.” Hiding an update for 30 days does not stop a policy from installing it on day two. The visibility delay runs from 1 to 90 days, and 90 is the maximum Apple supports.
5. A schedule that does nothing. If Start time and End time are both set to 12 AM, Intune does not check for restrictions and updates can install at any time.
6. The device itself. Devices check in about every eight hours by default, and the update installs at a later check-in within the schedule. Microsoft’s planning guide adds that a device with a PIN needs the PIN entered to start the update, and that automatic install needs the device powered on, plugged in and connected to the internet. A Shared iPad updates only while charging and with no user signed in.

One thread on Microsoft Q&A describes iPads that installed the version before the one targeted and then reported themselves up to date. The Microsoft answer pointed at supervision and the deferral requirement; the thread was never resolved, and I would not claim to know the cause.

Why a DDM update installs early, or the deferral looks ignored

DDM behaves the opposite way to the legacy policy in one important respect: the device enforces the deadline itself, and it is allowed to be early. Four documented behaviours explain most of the surprise.

• Delay in Days is not a deferral. For the Latest version model, Microsoft says the delay “only determines the target enforcement date and not the date that the update is offered to users.” Hiding an update is a different policy, Software Update Settings. In February 2026 a widely read blog reported a seven-day DDM deferral being ignored across a large iOS estate, with a suggested workaround that a reader later said the portal does not offer. I cannot tell from that post which setting was used, but the documented split between enforcement and visibility is the first thing I would check.
• Enforcement overrides your other settings. “When an update enforcement is assigned, the device ignores software update settings, including automatic update actions. The update may install before the deadline if the device is idle.” A device installing overnight ahead of its deadline is behaving as documented.
• The deadline is a hard stop. With Target Date Time, if the user has not updated by then they get a one-minute countdown, then a forced install and restart, in the device’s local time zone. A device that was powered off gets a one-hour grace period after it powers on.
• The target goes stale. Once a device is on a later version than the policy names, the policy reports an error, because the device reads the task as an attempted downgrade. Microsoft’s advice is to remove the older policy. If Target Build Version and Target OS Version disagree, Target OS Version wins.

The other trap is the status column. Microsoft is plain that a DDM policy reporting Success “only means that the configuration policy successfully installed on the device.” It says nothing about the OS version. A practitioner on Apple’s developer forums also reports a DDM update to 18.7.8 that showed Download and Install with no progress on cellular and proceeded once Wi-Fi was on. There was no Apple reply, so treat it as a lead, not a documented limit.

Where the status actually shows up

The reports are where most time is lost, because each policy type reports in a different place and neither shows what you would assume.

• Legacy: Devices > Monitor > Installation failures for iOS devices. This lists only failures, because iOS/iPadOS devices “only return information about installation failures.” A device missing from the list is not proof that it updated.
• DDM, fleet view: Reports > Device management > Apple updates > Summary, and the Apple software update report under Reports, which needs Generate before it shows anything. Intune checks with Apple once per day for new releases, so the latest version shown can trail Apple’s release.
• DDM, failures: Devices > Monitor > Apple software update failures, with the failure reason and timestamp.
• DDM, one device: open the device, expand Monitor and select iOS software updates. This shows the pending OS version, the install reason and the install state as the device reports them, which is the closest Intune gets to the truth.

All of the DDM reports need iOS/iPadOS 17.0 or later, according to Microsoft’s reporting page for Apple software updates.

The failure modes, side by side

What I would do differently

I would not build anything new on the MDM-based policy. Microsoft has said it is ending support, and its documented scope already stops at iOS 18. Every device on iOS/iPadOS 17 or later would go to DDM: the Targeted version model for estates with change control or app compatibility testing, the Latest version model for everyone else, with a Software Update Settings policy alongside it for visibility.

I would also stop treating the update policy as the enforcement mechanism on its own. Microsoft’s planning guide pairs update policies with a compliance policy with an OS minimum version and Conditional Access, and with enrollment restrictions that turn away older OS versions. That is the same layered thinking as update rings, the Windows equivalent, and it fails more gracefully: a device that misses its update loses access, rather than silently staying behind.

My own tenant is a lab with no enrolled iOS devices, so none of the statuses above were observed by me. Everything here is what Microsoft documents and what administrators report publicly, and the order of checks is my judgement about where an Intune iOS update policy is most likely to bite.

Last verified: 26 October 2026.