Streamlining macOS Patch Management with Update Rings via Intune DDM policies
- Steffen Schwerdtfeger
- Aug 1
- 5 min read
Updated: Aug 21
Windows Update for Business uses update rings to test and gradually roll-out updates, supporting an automated patching process aligned with the Evergreen IT approach. Historically, patching macOS devices has been more challenging. However, with the introduction of Declarative Device Management, macOS and Microsoft Intune offer new capabilities for scheduling update installations. The goal is to segment users into "Insider/Beta", "Pilot" and "Broad" groups for a controlled roll-out.
Declarative Device Management (DDM)
DDM is a modern approach to manage devices where the desired state of a device is defined and communicated to it. Consequently, the device itself is responsible for achieving and maintaining that state. In short: This reduces the communication load between Intune and macOS via giving the device more "intelligence". Intune offers several settings via this modern way:

Software Update policies
For managing Software Updates, we will use the new DDM policies. So, old profiles/settings like the following are not needed any more:
Intune > Devices > macOS > macOS updates
Intune > Settings catalog > Software Update
Intune > Templates > Software updates
The new settings are offered via Settings catalog under category "Declarative Device Management (DDM):
Software Update Settings
General settings like allowing Beta program enrolment, enablement of Notifications, Deferrals and Rapid Security Response settings.
Enforce Latest Software Update Version
Updates devices to the latest version with a defined installation deadline.
Software Update
Pin devices to a specific OS version with a defined installation deadline.
In addition, DDM policies take precedence over legacy update configurations.
Update rings
For implementing different "rings", we will split our users into three groups:
Insider/Beta: can opt-in and test Beta releases
Pilot: receive the current version directly after release
Broad: receive the current version after testing with pilot group

Intune Configuration
General update settings
Our first policy will contain general update settings like allowing standard users to install updates, activation of automatic update downloads and enablement of Rapid Security Responses:
macOS - Default - Software Update - Settings
assigned to: All devices
Software Update Settings
Allow Standard User OS Updates: Allowed
Automatic Actions:
Download: AlwaysOn
Install OS Updates: Allowed
Install Security Update: Allowed
Rapid Security Response:
Enable: Enabled
Enable Rollback: Disabled
Notifications: Enabled
Automatically Install App Updates: True
Beta policy
For allowing our "Insider/Beta" group of users the enrolment to Beta channel, we exclude them from the following policy (while simultaneously restricting access for all other users)
macOS - Default - Software Update - Beta - Off
assigned to: All users, exclude: Beta users group
Software Update Settings
Beta:
Program Enrollment: AlwaysOff
The default is "allowing" the Beta program. But, enabling the Beta option only worked stable with a counter policy:
macOS - Default - Software Update - Beta - Allowed
assigned to: Beta users group
Software Update Settings
Beta:
Program Enrollment: Allowed
Note, that users have to be logged in with a private Apple ID on their Mac (onboarded to Apple Developer) to get "Beta updates" option under Settings > General > Software Update.
If desired, you could also consider using the option "AlwaysOn" to enforce enrollment in the Beta program. In addition, you will need a token from Apple Business/School Manager.
Pilot policy
Out pilot users group should receive the latest version released by Apple directly:
macOS - Default - Software Update - OS Version - Latest
assigned to: Pilot users group
Software Update Enforce Latest
Enforce Latest Software Update Version: True
Delay In Days: 3
Install Time: e.g.: 17:00
So, once an update has been release by Apple, they will get it pushed with an installation deadline of 3 days.
Note, that "Delay In Days" is not a deferral period for the latest update (naming is misleading here). It is a "deadline for installation".
Also note that the installation deadline will be calculated like this: - after Apple releases an new update, deadline is based on this - deadline will be recalculated when policy was touched (last modified date) - if policy is new on a device, deadline is based on this local application date
Broad policy
You might think about using "Deferrals"... Wouldn't those settings be great for deferring updates for our broad users group?

The problem is that deferrals are overwritten by policies such as 'Software Update' or 'Enforce Latest Software Update Version'. As a result, the specified or latest version is offered immediately, bypassing any configured deferral period.
What about just using "Deferrals" for our broad ring? The downside is that we'd lose the ability to set an installation deadline
So, our broad users group will receive the desired OS version via this policy:
macOS - Default - Software Update - OS Version - Broad
assigned to: All users, exclude: Pilot users group
Software Update
Target OS Version: e.g. 15.5
Target Date Time: e.g.: xx/xx/xxxx, 17:00
Since, we cannot combine "Software Update Enforce Latest" with a deferral, we have to specify and update the desired version for our broad ring manually.
Hopefully, Microsoft will introduce a deferral option for "Software Update Enforce Latest" policy in future. This would enable a fully automated process without touching the OS version manually (e.g.: pilot policy with 0 days deferral, broad policy with 5 days deferral).
If desired, the broad ring can even be divided into multiple ones to achieve a more gradual rollout: Split this policy into multiple policies with different broad groups and adjust the target OS version step-by-step.
Update release flow
Admin
group your users into:
Beta users group
Pilot users group
all other users will automatically be in the broad ring
inform Beta users to opt-in for Beta program and test those versions
pilot users will automatically get the current version on the release day with enforcement after 3 days
if no issues occur: update the broad policy to the latest version after, for example, a 5-day delay
if issues occur: leave broad policy untouched until issues are resolved
End user experience
Users will automatically be informed via notifications. First one will appear once the update policy has been applied and an update is scheduled (displaying the deadline):

If the update installation reaches the deadline, users will see a countdown before the enforced restart:

If the deadline has been exceeded (e.g.: device turned off), it will try again on regular basis.
Policy download
Download the described policies as JSON to easily import them into Intune:
Changelog
21.08.2025:
added counter policy for Beta program: "macOS - Default - Software Update - Beta - Allowed"
detailed clarification of the installation deadline calculation process
It's interesting that you have choosen to use one of Apple's most unreliable API to build this upon. The legacy software update API is terrible and has never been reliable enough with getting OS updates out to devices. That's why DDM was created. It's also why other vendors came up with band-aid solutions to force software updates to work.
HI regarding beta program - why would admin create an 'AlwaysOff' policy for all users and exclude beta users if they had no intentions of also creating an "always on' policy for beta users. you mentioned "if desired..."
Appreciate the time & effort you’ve taken to share with the community. Looking forward to future endeavors.
Thanks for an interesting article. I did however, have a question. You state that we shouldn't need policies from the section: Intune > Settings catalog > Software Update Yet you also recommend the use of the policy: Automatically Install App Updates: As best as I can determine this is only available in the Software Update section of Settings Catalog and not under the DDM section. Or have I missed something here?