Your Mac update policy says Success. Half the fleet is still unpatched. Both statements can be true.
Declarative device management moves Apple devices from waiting to be told to acting on their own: the device applies settings asynchronously and reports its state back, no constant polling. Software update enforcement is the flagship example, the older MDM approach to it is deprecated, and the behaviour at the deadline, a one-minute countdown followed by a forced install and restart, deserves knowing before you set one. Remote-first from Gachibowli, Hyderabad, for organisations across India.
- AutonomousDevices act without constant polling
- iOS 17, macOS 14Minimums for update enforcement
- One minuteCountdown before forced install and restart
- One hourGrace period if the device was powered off
A policy reporting Success does not mean the device updated.
This is documented behaviour, and it is the single most likely reason an Apple update programme looks healthy while devices sit unpatched.
- Microsoft states plainly that a policy reporting success only means the configuration policy successfully installed on the device. It says nothing about whether the update itself happened. The advice is to monitor the OS version of targeted devices to confirm they actually updated.
- There is a second and stranger consequence. Once devices have updated past the version configured in a targeted policy, the policy reports an error, because the device treats the instruction as an attempt to downgrade. The recommendation is to remove the older version policy from devices in that state.
- So a targeted version policy left in place after the fleet has moved on generates errors that look like failures and are actually the opposite. An administrator reading the dashboard without knowing this concludes the deployment is broken, when what it needs is the obsolete policy removed.
- The practical discipline: report on OS version distribution across the fleet rather than on policy status, and retire targeted version policies once their version has been overtaken. Both are small habits, and they are what makes the reporting mean something.
Eight things about declarative management and update enforcement.
The device acts, rather than waiting to be told
Instead of a service polling a device and issuing commands, the device applies settings asynchronously and reports state back through a status channel, sending only the relevant changes. For an Indian estate spread across offices and home connections, with laptops frequently asleep or off the network, that is a materially more reliable model than command and response.
The older approach to software updates is deprecated
Microsoft describes configuring Apple update policies through the declarative model as more reliable and autonomous than traditional MDM-based policies, and states those are now deprecated. If your Apple update policies were configured before this shift, they sit on a mechanism with a stated end, not one that is merely older.
What actually happens at the deadline
The deadline is scheduled in the local time zone of the device. If the user has not triggered the update by then, a one-minute countdown prompt appears, and when it ends the device force installs the update and forces a restart. If the device was powered off at the deadline, a one-hour grace period runs from power-on, then it force installs and restarts.
Two policy models, for two different situations
Latest version installs the newest eligible release after a deferral period you set, with devices installing autonomously within the declared deadline and no manual trigger. Targeted version specifies exactly which OS version, a precise deadline, and an optional help URL. The first suits rapid patching; the second suits application compatibility constraints and phased rollouts.
The deferral counts from release, not from availability to users
A nuance worth understanding before setting a number. The delay is based on either the posting date of the update when Apple releases it, or on when the policy is configured, and it determines only the target enforcement date, not the date the update is offered to users. A deferral is a runway to the deadline, not a hold on the update appearing.
Enforcement overrides the settings on the device
When an update enforcement is assigned, the device ignores software update settings including automatic update actions, and the update may install before the deadline if the device is idle. That is intended behaviour, and it is worth telling users, because somebody who deliberately turned automatic updates off will otherwise conclude something is broken.
Separate settings control the experience before the deadline
Software update settings policies cover the run-up: whether an administrator or a standard user can perform updates, how users interact with automatic download and install, hiding updates for a defined period, suppressing update notifications up to one hour before the enforcement deadline, and whether users are offered the latest major update, the latest minor update, or both.
The four declaration types underneath
Apple defines configurations, similar to existing profile payloads; assets, reference data supporting one-to-many relationships; activations, sets of configurations applied atomically with predicates such as device type or OS version; and management, conveying overall management state and service capabilities. Activations and their predicates make targeting conditional at the device rather than at the service.
Four things that make Apple update enforcement work rather than annoy.
We design the deadline around how people actually work
The deadline runs in the device local time zone, a one-minute countdown appears if the user has not acted, then the device force installs and restarts. Set that for mid-afternoon on a team rendering video or closing month-end books and you get exactly the reaction you would expect. Choosing the install time thoughtfully is most of the user experience design here.
We split the fleet between the two policy models
Latest version for the general population, where rapid patching matters and compatibility is not a constraint. Targeted version for teams whose software has a validated OS requirement, where landing on a specific version deliberately is the whole point. Applying one model to the whole estate satisfies neither group.
We report on OS version, not policy status
Because a policy reporting success only means the configuration installed, not that the update happened. The number that matters is version distribution across the fleet. We also retire targeted policies once the fleet has passed them, since they then report errors that look like failures and are actually devices being ahead of the policy.
Remote-first, and we tell users what will happen, once, clearly
That enforcement overrides their own update settings, that an update may install while the device is idle before the deadline, and that at the deadline a one-minute countdown appears and then a restart. One clear message prevents most of the tickets; its absence generates all of them. Delivered remotely from Gachibowli, Hyderabad, with a 30 minutes response SLA for managed clients.
Six Indian situations where Apple update enforcement earns its place.
A firm asked about patch currency on Macs
The usual asymmetry: the Windows estate has a patch story and the Mac estate does not. For a CERT-In aligned security posture, an ISO 27001 audit or a client questionnaire, declarative enforcement with a defined deadline plus reporting on actual OS version distribution produces the same quality of answer for Apple devices as the Windows side already has.
A design, media or development team on pinned versions
Where a software vendor supports a particular macOS version and jumping to the newest release would break a workflow mid-project. Targeted version policy exists for exactly this: land the fleet on a validated version with a precise deadline, rather than choosing between no control and no compatibility.
A Mac population that never restarts anything
Laptops awake for weeks with forty applications open, where a restart is something the user will get around to eventually. The enforcement model resolves it by making the restart happen at a time you chose rather than never, which is the only version of this that produces a patched fleet.
An education or shared device estate
Shared iPads and Macs where nobody personally owns the device and therefore nobody accepts an update prompt. Autonomous enforcement means devices act on their own within the declared deadline with no manual trigger, the only realistic model when no individual is responsible for the device.
A distributed estate across cities and home offices
Where devices are rarely on a network anybody manages and command-based approaches fail because the device is unreachable when the command is issued. The declarative model, where the device applies settings asynchronously and reports state back, is considerably more reliable in exactly this situation, which describes most hybrid Indian workforces.
An organisation still on the deprecated update policies
Apple update policies configured through the older MDM approach, which Microsoft states is now deprecated in favour of the declarative model. Nothing breaks tomorrow, but the direction has no realistic alternative, so the migration belongs in a plan rather than a panic.
How Apple devices actually get updated in Indian organisations.
| Feature | Declarative enforcement | Deprecated MDM policies | Left to the user |
|---|---|---|---|
Updates enforced by a deadline | Yes | Attempted | No |
Device acts autonomously without a trigger | Yes | No | Not applicable |
Behaviour at the deadline is defined | Yes | Unreliable | Not applicable |
On a supported mechanism | Yes | Deprecated | Not applicable |
Specific version targetable for compatibility | Yes | Partly | No |
Enforcement overrides user update settings | Yes | Partly | No |
Notification experience controllable | Yes | Limited | No |
Reporting reflects actual OS version | If configured that way | Misleading | No |
Devices reliably current | Yes | Partly | No |
Frequency in the Indian market | Uncommon | Common | Very common |
Latest version or targeted version, and which suits what.
| Model | How it behaves and where it fits | |
|---|---|---|
| Latest version | Installs the newest eligible release after a deferral period you set, with an install time you specify | |
| Latest version, best for | Rapid patching, audit and client-questionnaire compliance, minimal administrative overhead | |
| Targeted version | A specified OS version, a precise deadline, and an optional help URL for users | |
| Targeted version, best for | Strict application compatibility, phased deployment and formal change management | |
| Version precedence | Where a build version and an OS version disagree, the OS version value takes precedence | |
| Deadline behaviour | One-minute countdown, then forced install and restart, in the device local time zone | |
| Powered off at the deadline | One-hour grace period from power-on, then forced install and restart | |
| Before the deadline | The update may install anyway if the device is idle |
Five steps, and the version audit comes first.
- 1
Audit the current OS version spread
Week 1
Update enforcement requires iOS or iPadOS 17 and later and macOS 14 and later, and the current spread determines what is enforceable now against what needs an upgrade path first. This audit also becomes the baseline you report against afterwards.
- 2
Split the fleet by policy model
Week 1-2
Latest version for populations where rapid patching is the priority, targeted version for teams with a validated compatibility requirement. Confirming which teams genuinely have a version constraint, rather than assuming they all do, is worth doing properly because it is usually fewer than claimed.
- 3
Design the deadline and the run-up experience
Week 2
Deferral period, install time in the device local time zone in twenty-four hour format, and the separate settings controlling the run-up: whether updates are hidden for a period, whether notifications are suppressed near the deadline, and whether users are offered major updates, minor updates or both.
- 4
Communicate once, clearly, before enforcing anything
Week 2-3
That enforcement overrides personal update settings, that an update may install while the device is idle before the deadline, and that at the deadline a one-minute countdown appears and then the device restarts. This single message prevents most of the support load a first enforcement generates.
- 5
Pilot, then report on version rather than policy status
Week 3-4
A pilot group through a real update cycle, then reporting built on OS version distribution rather than policy status, since success only confirms the configuration installed. Plus the habit of retiring targeted policies once the fleet has moved past them, so the dashboard stops showing errors that are not failures. Managed clients then run under a 30 minutes response SLA.
What Indian organisations ask about Apple declarative management.
Fifteen questions worth answering first.
Prerequisites
- Are your devices on iOS or iPadOS 17 or later?The stated minimum for update configuration.
- Are your Macs on macOS 14 or later?The stated minimum for macOS.
- How are the devices enrolled?Device Enrollment and Automated Device Enrollment are supported.
- Are older MDM update policies still in place?That approach is deprecated.
- Do you know your current OS version spread?It determines what is enforceable now.
Policy design
- Latest version or targeted version?Application compatibility usually decides.
- What deferral period, and counted from what?From Apple release or policy configuration.
- What install time, in the device local time zone?Twenty-four hour format, leading zero required.
- Is a forced restart acceptable for that population?That is what happens at the deadline.
- Do you want a help URL shown to users?Available on the targeted version model.
Monitoring and experience
- Are you reporting on OS version, not policy status?Success does not mean updated.
- Who removes superseded targeted version policies?They report errors once the fleet moves on.
- Should notifications be suppressed near the deadline?Supported up to one hour before.
- Should updates be hidden for an initial period?A separate settings policy controls this.
- Have users been told enforcement overrides their settings?It does, including automatic update actions.
The pages around this one.
macOS management
The wider Mac management picture: enrolment, configuration, security and the annual release cycle.
Learn moreiPhone and iPad management
The mobile side of the Apple estate, where the same enforcement model applies from iOS 17 onwards.
Learn moreApple device management India
The overview of managing an Apple fleet, and how the pieces fit together across platforms.
Learn moreGet the OS version spread across your Apple fleet.
That single report tells you what can be enforced now, what needs an upgrade path first, and whether your current update policies are achieving anything. It is also the number to report on afterwards, rather than policy status, which does not mean what people think it means. Initial reply within 4 business hours.