macOS 27 for Mac Admins: MDM Update Commands Gone, Stricter TLS

macOS 27 drops legacy MDM software update commands and blocks management servers that fail new TLS rules. What breaks, how to audit, what replaces it.

If you manage Macs, macOS 27 Golden Gate changes two things that don't show up on any user's screen but can take down a patching process or an enrollment flow in a day. First, the MDM software update commands, queries and restrictions that most fleets have used for a decade no longer function on devices running 27.0. Second, every connection in the management path — MDM, Declarative Device Management, Automated Device Enrollment, profile installation, app installation and software updates — now refuses servers that don't meet App Transport Security rules, where earlier releases only logged a warning.

Neither change is new information. Apple announced both before and at WWDC 2026. But now that 27.0 has shipped (on 14 September, build 26A428), they're live on any Mac that upgrades. This guide goes through what stops working, using Apple's own schema and support documents, how to audit your servers before your first Macs hit the problem, and what replaces each legacy mechanism.

Key Takeaways

Legacy software update management is gone on 27.0. Apple: "Legacy software update management no longer functions in all 27.0 operating systems." That covers the ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates and OSUpdateStatus commands, the com.apple.SoftwareUpdate payload, and the deferral restrictions.
The replacement is declarative. softwareupdate.enforcement.specific enforces a version by a deadline. softwareupdate.settings covers deferrals, automatic actions, Background Security Improvements and beta enrollment. Status items replace the queries.
Recommended cadence has no macOS equivalent. Apple's schema marks the declarative RecommendedCadence key as not available on macOS.
The TLS rules are now enforced for the management path. That means TLS 1.2 or later, forward-secret cipher suites, RSA ≥ 2048 or ECDSA ≥ 256 certificates signed with SHA-2, and the extended master secret extension. Only SCEP servers and content caching servers are exempt.
You can audit before devices upgrade. On earlier releases the same checks log warnings. Apple documents the log predicate for finding them.

Change 1: Legacy Software Update Management No Longer Functions

Apple's WWDC 2026 device management update put it in one sentence: "Legacy software update management no longer functions in all 27.0 operating systems." It then lists what that covers: software update commands, software update queries, recommended cadence settings, and software update restrictions, including deferrals and Background Security Improvements.

Apple's published device-management schema — the YAML files in the apple/device-management repository that MDM vendors build against — gives the precise status for each item. For macOS:

Legacy mechanism	Schema status (macOS)	Declarative replacement
`ScheduleOSUpdate` command	Deprecated 26.0, removed 27.0	`com.apple.configuration.softwareupdate.enforcement.specific`
`ScheduleOSUpdateScan` command	Deprecated 26.0, removed 27.0	Not needed — the device scans on its own and reports status
`AvailableOSUpdates` query	Deprecated 26.0, removed 27.0	Status item `softwareupdate.pending-version`
`OSUpdateStatus` query	Deprecated 26.0, removed 27.0	Status items `softwareupdate.install-state`, `softwareupdate.failure-reason`, `softwareupdate.install-reason`
`com.apple.SoftwareUpdate` profile payload	Deprecated 26.0, removed 27.0	`com.apple.configuration.softwareupdate.settings`
Restrictions `forceDelayedSoftwareUpdates`, `forceDelayedMajorSoftwareUpdates`, `forceDelayedAppSoftwareUpdates`, `enforcedSoftwareUpdateDelay`	Deprecated 26.0, removed 27.0	`softwareupdate.settings` → `Deferrals`

The schema snapshot we used is the repository's release branch as of 18 September 2026. If your MDM vendor's console still shows the legacy options, they're for devices on 26.x and earlier. On a Mac running 27.0 they do nothing.

What the declarative settings cover

The softwareupdate.settings configuration is where most legacy restrictions have moved. Its top-level keys, from Apple's schema:

Key	What it controls
`Notifications`	Whether the user sees update notifications
`Deferrals`	`CombinedPeriodInDays`, `MajorPeriodInDays`, `MinorPeriodInDays`, `SystemPeriodInDays`
`AutomaticActions`	`Download`, `InstallOSUpdates`, `InstallSecurityUpdate`
`RapidSecurityResponse`	`Enable`, `EnableRollback` — titled "Background Security Improvements settings" in the schema
`AllowStandardUserOSUpdates`	Whether a non-admin user can install OS updates
`Beta`	`ProgramEnrollment`, `OfferPrograms`, `RequireProgram` for AppleSeed and developer betas
`RecommendedCadence`	Marked "n/a" for macOS in the schema

The schema also notes that Background Security Improvements "aren't considered in Major, Minor, or System deferral mechanism". A deferral on major updates doesn't hold back a background security fix. If you need to control those, use the RapidSecurityResponse keys. Our Background Security Improvements guide explains what those updates are.

The recommended cadence gap

Legacy MDM let you set a "recommended cadence" that decided which update a user saw when both a minor update and a new major version were available. Apple lists recommended cadence among the legacy settings that stop working, and the declarative RecommendedCadence key in the current schema says introduced: n/a for macOS. That means there's no like-for-like replacement on the Mac today.

In practice, you shape what users see with deferrals, which hide a release for a set number of days, and enforcement, which pins the version you want by a deadline. That's more work than a single cadence switch, and it's worth telling your service desk about the change before users start asking why a major upgrade suddenly appears.

Enforcing a version on 27.0

The enforcement declaration is the one you'll use most. It names a target and a deadline:

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.su.macos-27-0-1",
  "Payload": {
    "TargetOSVersion": "27.0.1",
    "TargetLocalDateTime": "2026-10-15T18:00:00",
    "DetailsURL": "https://intranet.example.com/updates"
  }
}

TargetOSVersion and TargetLocalDateTime are the core keys. There's also TargetBuildVersion for pinning an exact build, which takes precedence when both are set. The version in the example is illustrative — as of this writing no 27.0.1 has shipped. Your MDM vendor will usually give you a form rather than raw JSON, but knowing the keys helps when you're reading the declaration in a device's status to find out why it didn't install.

One Policy, Written Both Ways

A concrete example makes the migration easier to picture. Take a common policy: hold major upgrades for 30 days, and keep automatic downloads and security updates switched on.

The legacy version is a set of restriction keys in a com.apple.applicationaccess payload:

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>30</integer>

A Tahoe Mac honours this. A Golden Gate Mac ignores it.

The declarative version puts the same intent in one configuration:

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "com.example.su.settings",
  "Payload": {
    "Deferrals": { "MajorPeriodInDays": 30 },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallSecurityUpdate": "AlwaysOn"
    }
  }
}

Three details from Apple's schema are worth knowing before you write your own:

Deferral values run from 1 to 90 days, the same range as the legacy delay keys.
When several declarations set the same key, the device combines them by rule. Deferrals use number-max (the longest deferral wins), the automatic actions use enum-last, and Notifications uses boolean-and — if any declaration turns notifications off, they're off. A leftover test declaration with a 90-day deferral will quietly override your 30-day policy, so check what's assigned before you debug anything else.
The automatic actions take Allowed, AlwaysOn or AlwaysOff, and default to Allowed. Apple's schema describes AlwaysOn as "always enabled" and AlwaysOff as "always disabled". Allowed is the one to pick if you want to leave the choice to the user.

Reading the result back

Declarative management reports state through status items instead of queries. The softwareupdate.install-state item takes one of five values: none, downloading, prepared, installing or failed. Paired with softwareupdate.pending-version, which says what the device intends to install, and softwareupdate.failure-reason when something goes wrong, that's everything the old OSUpdateStatus query told you. And the device sends it when the state changes, rather than when you remember to ask.

The Mixed-Fleet Trap

For the next year your fleet will include Macs on Tahoe 26.x, which still honour the deprecated legacy mechanisms, and Macs on Golden Gate 27.0, which ignore them. That creates three risks:

A deferral that only half works. A legacy forceDelayedMajorSoftwareUpdates restriction still holds Tahoe Macs back. Once a Mac is on 27, only a declarative Deferrals setting affects it. If you want the same policy on both, define it in both places.
Reporting that goes blank. Dashboards built on OSUpdateStatus and AvailableOSUpdates responses show nothing for 27.0 devices. Switch your reports to the declarative status items before those devices look "unknown".
Scripts that assume the command landed. Automation that sends ScheduleOSUpdate and waits for a result will wait forever on a 27.0 Mac. Check your runbooks and any API scripts against your MDM for legacy command calls.

The simplest approach is to move every Mac to declarative software update management now, including those still on Tahoe, where DDM software update declarations already work. Keep the legacy settings only as a safety net for devices you can't move yet. Our guide to why macOS 27 isn't showing in Software Update covers how deferrals decide whether the upgrade is offered in the first place.

Two groups of Macs receiving different kinds of update policies side by side

Change 2: Stricter TLS for the Management Path

Apple published the requirements in its support article Prepare your network environment for stricter security requirements, dated 9 June 2026, and repeats them in the macOS 27 release notes. Servers in the management path must:

Requirement	Detail
Protocol	TLS 1.2 or later; TLS 1.3 "whenever possible"
Cipher suites	Forward secrecy — any TLS 1.3 suite, or TLS 1.2 suites with ECDHE
Certificate keys	RSA at least 2048 bits, ECDSA at least 256 bits
Signature hash	SHA-2 with a digest of at least 256 bits
TLS 1.2 extension	Extended master secret (EMS), RFC 7627

The affected workflows, in Apple's list: mobile device management, Declarative Device Management, Automated Device Enrollment, configuration profile installation, app installation (including enterprise app distribution), and software updates.

Two exceptions are spelled out. Connections to a SCEP server, while installing a profile or resolving a DDM asset, aren't affected. Neither are content caching servers, even when they serve app or software update assets.

What changes on 27.0 is the consequence. Apple's article: "Non-compliant connections are blocked and the log messages appear as errors instead of warnings." The check itself isn't new. Earlier releases already logged these violations as warnings, and that's what makes it possible to audit now.

Where old TLS is still hiding

Public MDM services have been compliant for years. The risk lives in what you host or put in the path yourself:

Self-hosted MDM behind an older reverse proxy or load balancer, where the TLS configuration was set once and never revisited
In-house app distribution — the server hosting enterprise app manifests and .ipa or .pkg files
Package and asset hosts that DDM asset declarations or custom install workflows point to
TLS-inspecting firewalls and proxies that re-sign traffic with their own certificate, which then has to meet the same key-size and hash requirements
Old certificate chains — RSA 1024 keys or SHA-1 signatures on an internal CA
Old TLS stacks that negotiate TLS 1.2 but not the extended master secret extension

How to Audit Before Your Macs Upgrade

Step 1: Test each server with `nscurl`

macOS includes an ATS test tool. Point it at each server in your management path:

nscurl --ats-diagnostics https://mdm.example.com

It tries the connection under a series of ATS configurations and prints Result : PASS or Result : FAIL for each one. The first block, Default ATS Secure Connection, is the one that matters here. As a sanity check we ran it on a Tahoe Mac against two public servers. www.apple.com passed all 61 checks. A public test server that only offers TLS 1.0 passed none, starting with the default secure connection.

Step 2: Check the extended master secret

nscurl doesn't break out EMS separately, and it's the requirement older TLS stacks are most likely to miss. OpenSSL 3.x reports it directly. The system openssl on macOS is LibreSSL, so use one from Homebrew:

echo | openssl s_client -connect mdm.example.com:443 -tls1_2 -servername mdm.example.com 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Extended master secret"

Against www.apple.com, this prints Protocol: TLSv1.2, an ECDHE-RSA-AES256-GCM-SHA384 cipher, a 2048-bit server key and Extended master secret: yes. You want every server in the path to look like that or better.

Step 3: Let the devices tell you

Server-by-server testing only covers servers you know about. Apple's recommended audit catches the rest by recording what devices actually connect to:

Install Apple's Network Diagnostics Logging profile on a test Mac.
Run the workflows you care about: enrollment, profile installation, app installation, a software update.
Collect a sysdiagnose from that Mac.
Search the log archive with Apple's predicate:

log show --archive system_logs.logarchive --info -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

On a Mac running 26.x, any hits are warnings: those connections will be blocked when that Mac upgrades. On a 27.0 Mac, the same hits appear as errors, and those connections are already failing.

Run the test on a Tahoe Mac and you get a list of what will break, before anything actually has.

A checklist of server connections with most marked secure and one flagged for attention

A Rollout Checklist

Here's the order we'd work through it in, for a fleet that's about to see its first 27.0 upgrades:

List every server in the management path: MDM server and check-in URLs, the Automated Device Enrollment configuration, app manifest and package hosts, DDM asset URLs, and any proxy or firewall that inspects that traffic.
Run nscurl --ats-diagnostics against each one and fix anything that fails the default secure connection.
Check EMS with OpenSSL 3.x on every server that terminates TLS 1.2.
Run Apple's log audit on one Tahoe test Mac through a full enrollment-to-update cycle.
Recreate your update policy declaratively: enforcement declarations for target versions, softwareupdate.settings for deferrals, automatic actions and Background Security Improvements.
Switch reporting from OSUpdateStatus and AvailableOSUpdates to the declarative status items.
Search your automation for legacy command names: ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates, OSUpdateStatus.
Tell the service desk that cadence-based update hiding is gone on 27.0, and what users will see instead.
Upgrade a pilot group, and confirm that enrollment, app installation and update enforcement all still work on real 27.0 hardware before widening it.

Troubleshooting Common Issues

A 27.0 Mac ignores the update deadline you set

Problem: A Mac that upgraded to Golden Gate doesn't install the minor update your policy requires.

Solution: Check which mechanism the policy uses. If it's a legacy ScheduleOSUpdate command or MDM restriction, it no longer functions on 27.0. Deliver a softwareupdate.enforcement.specific declaration instead, and read the device's softwareupdate.failure-reason status if it still doesn't install.

Update reports show "unknown" for new Macs

Problem: Your patch dashboard shows no update data for Macs on 27.0.

Solution: The dashboard is reading legacy query responses. Switch it to the declarative status items softwareupdate.install-state and softwareupdate.pending-version.

Enrollment works on Tahoe and fails on Golden Gate

Problem: A new Mac running 27.0 fails during Automated Device Enrollment, while a Tahoe Mac with the same configuration succeeds.

Solution: This is the TLS change until proven otherwise. Test every URL in the enrollment flow with nscurl --ats-diagnostics, and check the device's logs for ATS errors from mdmclient, Setup Assistant or profiles.

Enterprise apps won't install on 27.0

Problem: Custom apps distributed from your own server fail to install.

Solution: The manifest or package host probably fails the TLS requirements. It's often an older web server that was never part of the MDM hardening effort. Content caching servers are exempt, so the problem is the origin host.

A TLS-inspecting firewall breaks management traffic

Problem: Everything works off the corporate network and fails on it.

Solution: The inspecting device re-signs connections with its own certificate and TLS settings, which now have to meet the ATS requirements. Either upgrade its configuration or exclude your management hosts and Apple's MDM endpoints from inspection.

FAQ

Do legacy software update commands still work on macOS 26?

Yes. Apple's schema marks them deprecated in 26.0 and removed in 27.0, so Macs on Tahoe still honour them. Macs on 27.0 don't. During the transition, define policies declaratively so every Mac gets the same result.

What replaces the recommended cadence setting?

On macOS, nothing directly. Apple's schema marks the declarative RecommendedCadence key as unavailable on macOS. Use deferrals to hide releases and enforcement declarations to require the version you want.

Are content caching servers affected by the TLS change?

No. Apple lists content caching servers as an exception, "even when requesting assets related to app installation or software updates". SCEP servers are also exempt.

How do I know which of my servers fail before any Mac upgrades?

Install Apple's Network Diagnostics Logging profile on a Tahoe test Mac, run your workflows, collect a sysdiagnose and search it with the log predicate in Apple's support article. On 26.x, violations appear as warnings, so you see them before they break anything.

Does this change anything for Macs that aren't managed?

The software update change doesn't. The TLS rule also covers software updates and app installation for every Mac, but those normally connect to Apple's own servers, which meet it. You can check whether a Mac is managed with profiles status -type enrollment. On an unmanaged Mac, both lines read "No".

Conclusion

macOS 27 finishes a move Apple has been signalling since declarative management arrived. Update control is now declarative-only on 27.0, and the management path now enforces the same transport security as any modern app connection. Neither change touches the user interface, so a fleet can walk into both without noticing — until a deadline is missed or an enrollment fails.

Both can be avoided with preparation you can do on Tahoe today. Test your servers, run Apple's log audit on one Mac, rebuild the update policy declaratively, and repoint your reporting. Do that before the first 27.0 Macs arrive, and the upgrade is routine.

Related tool: macOS Version Tracker - The latest release of each macOS version and whether it still receives security updates, taken from Apple's release record.