Your Apple patch policy says Success. That means the policy installed, not that the Mac updated.
Microsoft says exactly that in its own documentation, and it is the most common reason an Indian organisation believes its Apple estate is current when it is not. Enforced updates through Apple Declarative Device Management genuinely work, provided you design the deadlines around real working patterns and measure the OS version rather than the policy status. We do both, remotely from Gachibowli, Hyderabad, for organisations across India.
- 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 switch enforcement on.
Declarative policies, because the old ones are deprecated
Intune configures Apple update policies through Apple Declarative Device Management, which Microsoft describes as a more reliable and autonomous approach than traditional MDM-based policies, now deprecated. Devices enforce compliance independently without waiting for a management command, which is what makes the model work for Indian estates where devices are scattered across cities and 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, with Device Enrollment or Automated Device Enrollment. Devices below those versions, or enrolled another way, sit outside the policy entirely. Finding them is usually the first task in an estate that grew organically, and the group is nearly always larger than anyone expected.
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 update when Apple releases it, or when the policy is configured, and it only determines the target enforcement date, not when the update is offered to users. Users see and can install updates before the deadline, and often do.
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. One rule worth knowing before you fill in both fields: if the build version is not consistent with the Target OS Version, the Target OS Version takes precedence.
What happens at the deadline
Target Date Time schedules in 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 footnote: choose deadlines outside Indian working hours, and remember your estate may span teams on very different schedules.
What happens if the device was off
A device powered off at the deadline gets a one hour grace period from when it powers back on, then force installs and restarts. For a laptop opened at the start of a Monday review meeting, that hour is the entire margin, which is why enforcement dates need to account for travel, leave and long weekends before they go live.
Software Update Settings, the user experience layer
A separate policy family governs the run-up to enforcement: whether an admin or a standard user performs updates, how automatic download and install and Rapid Security Responses behave, whether updates are hidden for a period, whether notifications are suppressed up to one hour before the deadline, and whether major or minor updates are offered. Enforcement without this layer is technically correct and unpleasant to receive.
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 instead of OS version produces a number that is confidently wrong, and that number ends up in front of management.
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 they update, which is a different report and a different number.
- There is a second artefact that catches teams out. After devices update past the OS version configured in a targeted 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, targeted policies accumulate errors until the report becomes noise, which is exactly the point at which people stop reading it.
- The practical rule for any Indian estate answering a client questionnaire or a CERT-In-driven internal review: report Apple patch compliance from OS version distribution, and treat policy status as a deployment check. That one change separates a report that reflects the estate from 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, a missed deadline produces a one-minute countdown followed by a forced install and restart, and a powered-off device gets one hour from power on. We choose those times against travel, festivals, leave and meeting patterns, which is what keeps an enforcement cycle from becoming an incident.
We split the estate by compatibility constraint
Latest version policy for the general workforce, targeted version policy for devices running applications certified to a specific release. One model across everything either holds the whole estate back to the slowest application or breaks that application. Splitting the groups correctly is most of the answer.
We configure the experience, not only the enforcement
Software Update Settings decide whether standard users can update, how notifications behave, whether updates are hidden for a period, and whether major upgrades are offered. Managed clients get the whole layer configured and a 30 minutes response SLA when something needs attention, delivered remotely from Hyderabad to teams anywhere in India.
Four phases across roughly four weeks.
- 01Week 1
Establish eligibility and current state
Which devices meet the macOS 14.0 or iOS and iPadOS 17.0 requirement, which are enrolled through Device Enrollment or Automated Device Enrollment, and what the OS version distribution actually looks like today. Everything outside those boundaries needs its own plan, and listing it now prevents silent gaps later.
- 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 real working patterns, since a missed deadline produces a one-minute countdown and a forced restart wherever the user happens to be, including mid-demo with a customer.
- 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
Update 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 upgrades are offered, because enforcement without that layer arrives as a surprise.
- Update policies configured and assigned to pilot
- Software Update Settings policies configured
- Pilot group observed through a real enforcement cycle
- 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 actual deadline. Reporting is built on OS version distribution rather than policy status, with a housekeeping routine to remove targeted policies once devices have moved past them, so the error state never accumulates into noise.
- Full estate deployment completed
- Compliance reporting based on OS version
- Stale targeted policy removal routine established
- Exception process agreed for constrained devices
Six Indian Apple estates where enforced updates change the position.
A creative or media business running mostly Macs
Studios in Mumbai and Bengaluru run high-value applications with specific version support statements, and editors who genuinely cannot restart mid-render. Targeted version policies for 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
When an auditor, a client, or an internal review driven by CERT-In expectations asks how quickly critical updates reach endpoints, the answer has to be measured, not described. Enforced deadlines with reporting built on OS version distribution produce an answer with a number in it, which is the difference between a closed question and a follow-up.
A school, university or training institute
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: a term-start enforcement wave designed without it will restart devices during the first classes of the year.
A clinic or diagnostics group with version-locked software
Where a clinical or diagnostic application is supported only on a specific macOS release, an unmanaged estate drifts past it and vendor support is quietly lost. Targeted version policies hold those devices deliberately, with the decision recorded and owned, rather than accidentally with nobody accountable.
An organisation that just failed a vulnerability review
Unpatched macOS shows up in vulnerability scans as clearly as unpatched Windows, and it is usually the part nobody owned. Enforcement plus version-based reporting closes the finding, and more usefully, turns the next review into a five-minute conversation instead of a remediation project.
A business still on the legacy update approach
Traditional MDM-based software update policies are now deprecated in favour of the declarative model. Estates still relying on the old mechanism are running on borrowed time, and migrating is a small, contained piece of work that removes a dependency nobody wants to discover at an awkward moment.
How Indian 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 with minimal 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 | Needs 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 Indian estates that group includes the oldest machines and the ones bought outside procurement.
- 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 someone outside IT to make the call.
- 3
Configure policies and the user experience together
Enforcement policies plus Software Update Settings for the run-up: who may perform updates, how notifications behave, whether updates are hidden for a period, whether major upgrades are offered. Both layers together, or enforcement arrives without warning and the helpdesk pays for it.
- 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 on devices that were powered off. That cycle tells you whether the chosen deadline is workable before the whole estate finds out.
- 5
Broaden, and build reporting that reflects reality
Full deployment, compliance reporting built on OS version distribution rather than policy status, and a routine that removes targeted policies once devices have moved past them, so the error state never accumulates and the report stays worth reading.
What Indian 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.
- Is every device 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, studios and clinics.
- Are there devices that must never auto-restart?They need an exception path.
- What does change management require?It may force targeted version.
Experience
- What install time suits the workforce?24-hour format, and think about shifts.
- 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.
The pages around this one.
macOS management
The wider platform view for managing Macs in an Indian business: encryption, admin rights, software and evidence.
Learn moremacOS security hardening
The hardening baseline that update enforcement belongs inside: FileVault key management, Gatekeeper and tamper protection.
Learn moreApple device management in India
The parent page for Apple in the enterprise: enrolment, platforms and the operational disciplines around them.
Learn morePull 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 usually decides whether this is a review or a project. Enquiries are answered within 4 business hours.