A patch policy reporting Success only means the policy installed. It says nothing about whether the Mac updated.
Microsoft states that plainly in its own documentation, and it is the single most common reason organisations believe their Apple estate is current when it is not. Enforced updates through Declarative Device Management work well, and only if you monitor the OS version rather than the policy status.
- macOS 14.0+Required for declarative update policies
- iOS 17.0+Same requirement on iPhone and iPad
- 1 minuteCountdown before forced install at deadline
- 1 hourGrace period if the device was powered off
Eight things to get right before you turn enforcement on.
Declarative policies, because the old ones are deprecated
Intune configures Apple update policies using Apple Declarative Device Management, described by Microsoft as a more reliable and autonomous approach than traditional MDM-based policies, which are now deprecated. Devices enforce compliance independently without manual triggers, which is what makes the model work for estates that are rarely all online at once.
The version and enrolment prerequisites
Software update configuration requires iOS or iPadOS 17.0 and later, and macOS 14.0 and later. Supported enrolment methods are Device Enrollment and Automated Device Enrollment. Devices below those versions or enrolled another way are outside the policy, and finding them is usually the first task in an estate that grew organically.
Latest version policy, and what the delay actually delays
You set a Delay in Days and an Install Time. The detail teams misread: the delay is based on either the posting date of the new update when released by Apple, or when the policy is configured, and it only determines the target enforcement date, not the date the update is offered to users. Users see updates before the deadline.
Targeted version policy, for compatibility constrained estates
You specify a Target OS Version such as 26.0, optionally a Target Build Version such as 25A354, a Target Date Time, and a Details URL pointing at your own help page. If the build version is not consistent with the Target OS Version, the Target OS Version takes precedence, which is worth knowing before you enter both.
What happens at the deadline
Target Date Time schedules using the local timezone 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 and forces a restart. That is a design constraint, not a detail: choose deadlines outside working hours or expect complaints.
What happens if the device was off
If the device is powered off when the deadline is met, there is a one hour grace period from when it powers back on. After that it force installs and forces a restart. For a laptop opened at the start of a meeting, that hour is the entire margin, which is why enforcement dates need to account for travel and leave patterns.
Software Update Settings, the user experience layer
A separate policy family controls the run up to enforcement. It can require that an admin or a standard user performs updates, control how users interact with automatic download and install and Rapid Security Response behaviour, hide updates from users for a specified period, suppress notifications up to one hour before the deadline, and control whether latest major or minor updates are offered.
Monitoring the right number
This is where estates go wrong. A policy reporting Success only means the configuration policy successfully installed on the device. Microsoft recommends monitoring the OS version of targeted devices to confirm they actually update. Reporting compliance from policy status rather than OS version produces a number that is confidently wrong.
Success means the policy installed. It does not mean the Mac updated.
Microsoft states this directly, and it explains most cases where an Apple estate reports healthy patch compliance while the OS version report tells a different story.
- A policy that reports Success only means the configuration policy successfully installed on the device. Microsoft explicitly recommends monitoring the OS version of targeted devices to ensure that they update, which is a different report and a different number.
- There is a second reporting artefact that catches teams out. After devices have updated to a later OS version than the one configured in the policy, the policy reports an error, because the device sees the task as an attempt to downgrade. That error is not a failure, it is a stale policy.
- Microsoft recommends removing the older OS version policy from devices in that state. Without that housekeeping, a targeted version policy accumulates errors over time and the reporting becomes noise, which is exactly when people stop reading it.
- The practical rule is to report Apple patch compliance from OS version distribution, and treat policy status as a deployment check rather than a compliance measure. That one change makes the difference between a report that reflects the estate and one that reflects your intentions.
Four things that decide whether enforcement works or generates tickets.
We report on OS version, never on policy status
A policy reporting Success only means the configuration policy installed on the device, and Microsoft recommends monitoring the OS version of targeted devices to ensure they update. Building the compliance report on version distribution is a small change that makes the difference between a trustworthy number and a comforting one.
We design deadlines around how people actually work
Target Date Time uses the device local timezone, and a missed deadline produces a one-minute countdown followed by a forced install and restart. A device powered off at the deadline gets one hour from power on. Choosing those times against travel, leave and meeting patterns is what prevents an enforcement cycle becoming an incident.
We split the estate by compatibility constraint
Latest version policy suits the general workforce and targeted version policy suits devices running applications certified to a specific release. Running one model across everything either holds the whole estate back to the slowest application or breaks that application. Splitting the groups is the entire answer.
We configure the experience, not only the enforcement
Software Update Settings control whether standard users can perform updates, how automatic download and install behave, whether updates are hidden for a period, whether notifications are suppressed up to an hour before the deadline, and whether major updates are offered. Enforcement without that layer is technically correct and unpleasant to be on the receiving end of.
Four phases across roughly four weeks.
- 01Week 1
Establish eligibility and current state
Which devices meet the platform requirement of macOS 14.0 and later or iOS and iPadOS 17.0 and later, which are enrolled by Device Enrollment or Automated Device Enrollment, and what the current OS version distribution looks like. Everything outside those boundaries needs a separate plan.
- OS version distribution across the Apple estate
- Devices below the platform requirement identified
- Enrolment method confirmed per device group
- Devices outside declarative policy scope listed
- 02Week 2
Decide the model per group and the deadlines
Latest version policy for the general workforce, targeted version policy where an application constrains the OS. Then the deadlines, chosen against working patterns rather than convenience, since a missed deadline produces a one-minute countdown and a forced restart wherever the user happens to be.
- Device groups defined by update strategy
- Delay in days and install time agreed for latest version groups
- Target versions and dates agreed for constrained groups
- Details URL help page prepared
- 03Week 3
Configure, pilot and set the user experience
Settings catalog policies created and assigned to a pilot group first. Alongside them, Software Update Settings policies deciding whether standard users can perform updates, how notifications behave, and whether major updates are offered, since enforcement without that layer produces a jarring experience.
- Settings catalog update policies configured
- Software Update Settings policies configured
- Pilot group deployed and observed through a real update
- User communication issued before first enforcement
- 04Week 4
Broaden, and build reporting on OS version
Rollout to the full estate once the pilot has been through an enforcement cycle. Reporting built on OS version distribution rather than policy status, plus a housekeeping routine to remove targeted version policies once devices have moved past them.
- Full estate deployment completed
- Compliance reporting based on OS version
- Stale targeted policy removal routine established
- Exception process agreed for constrained devices
Six Apple estates where enforced updates change the position.
A creative or media business running mostly Macs
Creative estates run high-value applications with specific version support statements, and users who genuinely cannot restart mid render. Targeted version policies for the production machines and latest version for everyone else resolves the tension that otherwise keeps the whole estate on an old release.
A regulated firm asked to evidence patch currency
Where a supervisor or an auditor asks how quickly critical updates reach endpoints, the answer has to be measured rather than described. Enforced deadlines with reporting built on OS version distribution produce an answer with a number in it, which is the difference between a satisfactory response and a follow-up.
A school or university with shared and assigned devices
Education estates combine devices that are rarely offline with devices that spend the holidays in a cupboard. The one hour grace period after power on matters here more than anywhere, since a term-start enforcement wave will otherwise restart devices during the first lessons of the year.
A clinic where an application is certified to one version
Where a clinical or diagnostic application is supported only on a specific macOS release, an unmanaged estate drifts past it and support is quietly lost. Targeted version policies hold those devices deliberately, with the decision recorded, rather than accidentally, with nobody accountable.
An organisation that just failed a vulnerability review
Unpatched macOS shows up in vulnerability reporting as clearly as unpatched Windows, and it is frequently the part nobody owned. Enforcement plus version-based reporting closes the finding and, more usefully, makes the next review a five minute conversation instead of a project.
A business moving from a legacy update approach
Traditional MDM-based software update policies are now deprecated in favour of the declarative model. Estates still relying on the old approach are running on a mechanism with a limited future, and migrating is a small piece of work that removes a dependency nobody wants to discover at an awkward moment.
How UAE organisations patch their Apple estates.
| Feature | Enforced and measured on OS version | Policies deployed, status reported | Left to the user |
|---|---|---|---|
Updates enforced with a deadline | Yes | Yes | No |
Compliance measured on OS version | Yes | No | No |
Stale policies removed | Routinely | No | Not applicable |
Constrained apps handled separately | Targeted policies | One policy for all | No |
User experience configured | Yes | Partly | Default |
Forced restarts anticipated | Communicated | Surprise | Not applicable |
Devices below platform minimum found | Yes | No | No |
Rarely-online devices tracked | Yes | No | No |
Reporting trusted by security | Yes | Not once checked | No |
Time to patch a critical release | Days | Unknown | Indefinite |
Latest version against targeted version, decided on the estate not the preference.
| Consideration | Latest version | Targeted version | |
|---|---|---|---|
| What it does | Installs the latest eligible OS after a deferral | Installs a specified version by a set deadline | |
| Settings you configure | Delay in Days and Install Time | Target OS Version, build, date time, details URL | |
| Best suited to | Rapid patching and minimal IT overhead | Strict app compatibility and phased rollout | |
| Deadline basis | Apple posting date or policy configuration date | The exact date and time you set | |
| Timezone handling | Install Time is local device time | Target Date Time uses device local timezone | |
| Ongoing maintenance | Minimal, it follows Apple releases | Requires updating as versions move on | |
| Stale policy behaviour | Not applicable | Reports an error once devices pass the version | |
| User help pointer | Not applicable | Details URL to your own help page | |
| Typical audience | General workforce laptops | Devices running validated line of business apps | |
| Change control fit | Continuous | Formal change management workflows |
Five steps, and the first two are about the estate rather than the console.
- 1
Establish eligibility and the current version distribution
Declarative update policies require macOS 14.0 and later or iOS and iPadOS 17.0 and later, with Device Enrollment or Automated Device Enrollment. Devices outside those boundaries need their own plan, and in most estates that group is larger than expected and includes the oldest machines.
- 2
Identify the applications that constrain the OS version
Which devices run software certified to a specific release, and who owns the decision to move it. This determines the split between latest version and targeted version policies, and it is the conversation that most often needs somebody outside IT to make a call.
- 3
Configure policies and the user experience together
Settings catalog policies for enforcement, plus Software Update Settings for the run up: who may perform updates, how notifications behave, whether updates are hidden for a period, and whether major upgrades are offered. Both layers, or enforcement arrives without warning.
- 4
Pilot through a real enforcement cycle
A pilot group taken through an actual deadline rather than a deployment test, because the behaviour worth observing is the countdown, the forced restart and the grace period for devices that were powered off. That cycle tells you whether your chosen deadline is workable.
- 5
Broaden and build reporting that reflects reality
Full deployment, with compliance reporting built on OS version distribution rather than policy status, and a routine to remove targeted version policies once devices have moved past them so the error state does not accumulate and turn the report into noise.
What organisations ask about Apple patch management.
Fifteen checks worth doing first.
Eligibility
- How many Macs are below macOS 14.0?They cannot receive declarative policies.
- How many iPhones and iPads are below 17.0?Same requirement.
- Are all devices on a supported enrolment method?Device or Automated Device Enrollment.
- What is the current OS version distribution?Your actual baseline.
- Which devices are rarely online?They meet deadlines late.
Constraints
- Which apps are certified to a specific macOS version?They need targeted policies.
- Who owns the compatibility decision?Name them now.
- Do any devices run vendor-locked software?Common in labs and studios.
- Are there devices that must never auto restart?They need an exception path.
- What is the change management requirement?It may force targeted version.
Experience
- What install time suits the workforce?24-hour format, leading zero.
- Can standard users perform updates?A Software Update Settings choice.
- Do we suppress notifications near the deadline?Up to one hour before.
- Do we offer major updates or only minor?Controllable per policy.
- Where does the Details URL point?Your own help page.
Pull your Apple OS version distribution and compare it to your patch report.
Policy status and OS version are different numbers, and when they disagree the version is the true one. That comparison takes ten minutes and it usually decides whether this is a review or a project.
Related Services
Explore more solutions that work great with this service
macOS Security Hardening
Encryption, execution control and recovery keys
macOS Management Dubai
FileVault, admin rights, updates and the Rosetta deadline
Apple Declarative Management
Autonomous update enforcement, and what happens at the deadline
Apple Device Management
Mac and iPhone fleets, encryption, patching and the September cycle
iPhone and iPad Management
Remove company data from a phone you do not own
Microsoft Intune
Device management and endpoint security
Jamf Pro UAE
The specialist Apple management platform, and when it earns its place
Zero-Touch Deployment UAE
Sealed box to working device without IT touching it