For a decade, managing Apple software updates meant a server nagging devices: send a command, hope the device checks in, ask again whether it complied. Apple has now ended that model, not with a recommendation but with a removal. Update management built on the old MDM commands stops functioning entirely in the 27.0 operating systems arriving this fall, and the replacement, Declarative Device Management, is not the same idea with new syntax. It moves the enforcement into the device itself, and that changes what an update policy is.
This closes a gap the Mac compliance article pointed at: macOS updates default to user-initiated, and compliance can only observe the result. This is the article about controlling the input, for macOS and iOS both, and about the deadline that makes the migration non-optional.
Why Apple rebuilt update management
Declarative Device Management, introduced in 2021 and extended since, inverts the management protocol. Instead of the server issuing commands and polling for results, the server hands the device a declaration of desired state, and the device takes responsibility for reaching it and proactively reports status back over a dedicated channel. For most workloads that is an efficiency improvement. For software updates it is a philosophical one, because an update is a long-running, user-entangled process that a command-based protocol was always wrong for. A command fires once against a device that may be asleep, offline, or on battery; a declaration lives on the device, survives all of that, and, in Apple’s words for the failure case, the device detects when the operating system does not achieve the declared state and resumes the process when it reconnects. Software updates became a DDM workload with iOS 17 and macOS 14, and that pairing is the floor for everything in this article.
The clock that is actually ticking
Apple deprecated the legacy update workload at its 2025 developer conference, with the usual language about continuing to work until removal. The removal then arrived on schedule: as of the 2026 announcements, legacy software update management no longer functions in any of the 27.0 operating systems, and the removal list is thorough, the update commands, the update queries, the recommended-cadence setting, the deferral restrictions that hid updates from users for up to ninety days, and the legacy controls for background security improvements. Intune told its customers the same thing ahead of time: a formal plan-for-change notice in mid-2025, published within weeks of the deprecation announcement, set out the end of support for the iOS and macOS update policy types, the software-update settings scattered through device restrictions and the settings catalog’s restriction sections, and the update reports built on them, steering everything to the DDM policies in the settings catalog.
The detail that concentrates the mind is that there is no separate Intune retirement date to negotiate with. The deadline ships inside the operating system: the moment a device upgrades to a 27.0 release, the legacy machinery it was managed by simply stops answering, whatever your policies say. A fleet that has not migrated does not fail on a flag day; it decays device by device as upgrades land, which is quieter and worse.
There is no separate Intune retirement date to wait for. The deadline ships inside the operating system itself.
How a declarative update actually behaves
Intune expresses the new model through the settings catalog’s Declarative Device Management category, and it comes in two shapes. The targeted policy names an exact OS version and a deadline, a date and time evaluated in the device’s local time zone. The enforce-latest policy skips the version bookkeeping: it takes whatever Apple most recently shipped, offset by a delay you choose in days from Apple’s release date, and installs it at your chosen local time. Either way, the enforcement is deadline-driven and the device does the work: it downloads and prepares ahead of time, notifies the user with escalating urgency as the deadline approaches, ignores Do Not Disturb in the final twenty-four hours, and at the deadline installs without further consent, force-quitting open applications on macOS and requiring the passcode after restart on iOS. The user experience is honest rather than gentle: a visible countdown toward an outcome that is no longer theirs to decline, which is exactly the property the compliance article wished for.
Rapid Security Responses, worth a footnote, have effectively given way to background security improvements in the current OS generation, and the declarative model handles them sensibly: pin only a target OS version and the device installs available background security improvements on its own.
Deferrals still exist, but they changed jobs
The old model’s only real lever was the deferral, hiding a new release from the user’s Software Update pane for up to ninety days and hoping. Deferrals survive in the declarative world, but demoted to what they always really were: a pacing control, not an enforcement mechanism. A newer settings declaration, which asks for iOS 18 or macOS 15 rather than the enforcement floor, carries the one-to-ninety-day deferral windows, on macOS with separate windows for major, minor, and system updates, and controls what users are offered in the meantime. Declaration-based deferrals take precedence over the old restriction-based ones, and none of them installs anything. Only the deadline installs. Design with that division of labor: deferrals shape what an eager user can pull, the enforcement policy guarantees what every user eventually gets.
The migration, in the right order
The mechanics of the migration are less delicate than they sound, because the protocols resolve their own overlap: when a declarative update policy is enforced on a device, the device ignores the legacy MDM update settings, and once an enforcement is assigned it ignores the software-update settings for that cycle too, sometimes installing before the deadline if the machine is idle. But do not lean on precedence as a strategy. Run the two models side by side and your reporting lies to you, the legacy reports counting policies that devices are ignoring. The clean order is the obvious one: build the DDM policies in the settings catalog, assign them to a pilot, verify enforcement and reporting, then remove the legacy update policies and deferral restrictions from every group the DDM policies now cover, rather than leaving both to argue. Scope is the last constraint to check: the declarative policies want supervised devices enrolled through device enrollment or automated device enrollment, not user enrollment, which for institutionally owned Apple fleets enrolled the way this series has described is already true, and any Mac on a modern OS properly enrolled in MDM is supervised by definition.
Updates are also the leading edge of something bigger. This year Intune added declarative delivery for required line-of-business apps on iOS 18, Apple moved its intelligence-feature restrictions from the old payloads into declarative configurations, and the settings catalog’s declarative section keeps growing, passcode policy, Safari extensions, disk management. Apple has made its direction unambiguous: declarations are the protocol, and the command era is being retired workload by workload. Updates are simply the workload where the retirement has a date, and the date is this fall. Migrate the update policies now, and treat everything you learn doing it as rehearsal for the rest.
Intune Deployment Guide · Phase 11: Mac Management
‹ Previous: [11.6] Migrating Macs to Intune from Jamf or No MDM
