Jamf Pro and OS 27: move software updates to declarative MDM
Jamf Pro 11.31 maps the Apple software update mechanisms removed in macOS, iOS, iPadOS and tvOS 27 to the Jamf features that rely on them. For IT teams, the risk is now concrete: remote commands, restrictions and automations can stop working or retain stale data unless they are replaced by supported declarative workflows.
1. What Jamf documents
Jamf recalls that Apple deprecated legacy MDM software update commands at WWDC 2025 as it shifted OS update management to Declarative Device Management. In the Jamf Pro 11.31 release notes, it says ScheduleOSUpdate, the macOS com.apple.SoftwareUpdate payload, and the forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay restriction keys are removed in OS 27.
In Jamf Pro, this affects the Download and Download and Install commands, nearly all managed software update commands, and the corresponding deferral settings. Jamf warns that workflows, Smart Groups or automations that depend on them may fail silently or expose stale data.
2. The mechanisms that remain supported
The softwareupdate.enforcement.specific declaration remains supported. It powers Download and schedule to install and the Software Updates Blueprint component. The softwareupdate.settings declaration used by the Software Update Settings Blueprint component also remains available.
Jamf also lists the policy payload based on the macOS softwareupdate binary as supported. This coexistence does not make every path operationally equivalent: teams need to identify the mechanism actually invoked by each interface action, script or API call.
3. What does this announcement change for a Belgian or French organization?
For an SME, the immediate question is whether its MDM provider still controls updates exclusively through legacy commands. For a mid-market organization, large enterprise or public body in Belgium or France, the project also covers dynamic groups, maintenance windows, compliance dashboards, support procedures and patching evidence.
A mixed OS 26 and OS 27 fleet can hide the issue: one workflow may succeed on devices that remain on OS 26 and fail on the new systems. Security teams must therefore measure the outcome by OS version and device, rather than treating a command sent by Jamf as proof of installation.
4. Underside analysis: audit dependencies, not only profiles
Our view is that migration should start with an inventory of intentions — enforce a version, defer an update, schedule installation or prove compliance — and then map each one to the underlying Jamf mechanism. Removing an old profile is insufficient if a script, mass action or Smart Group still depends on its state.
This work complements our guide to the retirement of legacy Apple MDM update workflows and our analysis of Apple Software Lookup for declarative patching. Apple Business Manager and Automated Device Enrollment establish ownership and supervision; Jamf must then apply and verify the update policy.
5. Recommended migration plan
- Inventory remote commands, profiles, policies, Blueprints, Smart Groups, scripts and API calls related to software updates.
- Identify dependencies on
ScheduleOSUpdate,com.apple.SoftwareUpdateand the legacy deferral keys. - Rebuild compatible intentions with
softwareupdate.enforcement.specificandsoftwareupdate.settings. - Test Mac, iPhone, iPad and Apple TV separately in an OS 27 pilot ring.
- Verify installation, deadline, user deferral and returned status; do not treat command delivery as proof.
- Define a dashboard by OS version and a recovery runbook before expanding deployment.
Objective: preserve a measurable patching chain when OS 27 removes legacy MDM mechanisms, before silent failures reach production.
Audit your Jamf and Apple update workflowsOfficial source: Jamf Pro 11.31 — OS 27 Software Update Deprecations and Affected Jamf Pro Features.