macOS Software Updates: Patching Macs Fast and Reliably

Keeping macOS current is the single cheapest hardening control you have. Most of the other guides on this site, from Gatekeeper and XProtect to System Integrity Protection, assume the operating system underneath is patched. A Mac that is several point releases behind is exposed to publicly documented vulnerabilities, some of which Apple describes in its security release notes as possibly exploited in the wild. This guide covers how updates are delivered on macOS 15 Sequoia and macOS 26 Tahoe, how to check and install them from the command line, how to configure automatic behavior, and how to enforce deadlines across a fleet.

How Apple delivers updates

macOS receives several distinct kinds of updates, and each has its own channel and its own switch:

From Rapid Security Responses to Background Security Improvements

Starting with macOS Ventura, Apple shipped Rapid Security Responses: small security patches that could be applied between regular point releases, identified by a letter suffix on the version, such as "(a)". With macOS 26, Apple describes this mechanism as Background Security Improvements. The goal is the same: deliver urgent security fixes, for example to WebKit or other system components, without waiting for the next full point release. Treat them like any other security update. They are governed by the same automatic security response setting, so turning that setting off also delays these fixes.

Security configuration data

XProtect signatures and XProtect Remediator are updated independently of macOS itself, often more frequently than point releases. These updates are what keep built-in malware detection useful. Disabling "Install Security Responses and system files" is one of the most damaging changes a user or a misconfigured profile can make, because it silently freezes that detection data.

The softwareupdate command

softwareupdate is the built-in CLI for Apple updates. The most useful options:

# List available updates
softwareupdate --list

# Show the history of installed updates
softwareupdate --history

# Download and install all available updates, restarting if required
sudo softwareupdate --install --all --restart

# List full macOS installers available from Apple
softwareupdate --list-full-installers

A typical listing looks like this (labels and versions vary):

Software Update Tool

Finding available software
Software Update found the following new or updated software:
* Label: macOS Tahoe 26.x-...
	Title: macOS Tahoe 26.x, Version: 26.x, Size: ...KiB, Recommended: YES, Action: restart,

Volume owners and Apple silicon

On Apple silicon, installing a macOS update requires authorization from a volume owner. A volume owner is a local user with a Secure Token, typically the first account created during setup and any account granted a token afterwards. The root user is not a volume owner, which is why sudo softwareupdate --install can stall or prompt even though it runs as root. softwareupdate offers --user and --stdinpass options to supply owner credentials, but scripting a password into an update workflow is a poor pattern for a fleet.

The supported answer is MDM. When a Mac is enrolled and has escrowed a bootstrap token with the MDM server, the MDM can authorize software updates on the user's behalf. This is one of the strongest practical arguments for managing Macs with MDM and configuration profiles rather than scripts alone.

Automatic update settings

In System Settings > General > Software Update > Automatic Updates, users see toggles for checking, downloading, installing macOS updates, installing app updates from the App Store, and installing Security Responses and system files. These map to preferences in /Library/Preferences/com.apple.SoftwareUpdate.plist, and the same keys can be delivered in a com.apple.SoftwareUpdate configuration profile payload:

An example payload that locks these settings on:

<dict>
    <key>PayloadType</key>
    <string>com.apple.SoftwareUpdate</string>
    <key>PayloadIdentifier</key>
    <string>com.example.softwareupdate.settings</string>
    <key>PayloadUUID</key>
    <string>REPLACE-WITH-UUID</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>AutomaticCheckEnabled</key>
    <true/>
    <key>AutomaticDownload</key>
    <true/>
    <key>CriticalUpdateInstall</key>
    <true/>
    <key>ConfigDataInstall</key>
    <true/>
</dict>

When these keys are managed by a profile, the corresponding toggles are greyed out in System Settings, which prevents users from switching them off. Note that Apple has signaled that legacy MDM software update mechanisms, including this payload and deferral restrictions, are being deprecated in favor of Declarative Device Management. On newer releases, prefer the declarative software update settings configuration (com.apple.configuration.softwareupdate.settings) where your MDM supports it, and keep the legacy payload only for older macOS versions.

Enforcing updates with Declarative Device Management

Automatic updates are best effort: users can postpone restarts, and Macs that sleep or travel may lag behind. Declarative Device Management (DDM) adds an enforcement declaration, com.apple.configuration.softwareupdate.enforcement.specific, that tells the Mac to be on a specific version by a specific time. Its main keys:

The Mac downloads the update, notifies the user with increasing urgency as the deadline approaches, and installs it at the deadline if the user has not already done so. Because the Mac reports progress through the DDM status channel, the MDM can show which devices are pending, downloading, or failed without polling. For most organizations, a sensible pattern is: a short test window for a pilot group, then an enforcement deadline for everyone roughly one to two weeks after release, and much shorter for updates that fix actively exploited vulnerabilities.

Deferrals

Supervised Macs can have updates hidden for a period so that IT can test first. In the legacy restrictions payload (com.apple.applicationaccess), forceDelayedSoftwareUpdates enables the delay and enforcedSoftwareUpdateDelay sets it in days, up to 90. Declarative software update settings offer equivalent deferral controls on current releases.

Deferrals are a compatibility tool, not a security control. Every day of deferral is a day of exposure to published vulnerabilities. Keep deferrals short, apply them to major upgrades more than to minor security updates, and always combine them with an enforcement deadline.

Third-party application patching

Apple updates cover the OS, Safari, and Apple apps. Browsers, office suites, collaboration clients, runtimes and developer tools usually update through their own mechanisms, and they are frequent targets. Options include:

• Mac App Store apps: enable automatic app updates. Apps from the App Store update through the same Software Update settings.
• Vendor auto-updaters: many apps ship their own updater. Leave these enabled unless you replace them with a managed process.
• MDM app catalogs: many commercial MDMs maintain catalogs of common third-party apps and patch them automatically.
• Open-source tooling: Munki (managed software installation and updates), AutoPkg (automated packaging of vendor releases) and Installomator (a script that downloads and installs current versions of common apps) are widely used in Mac admin teams.
• Homebrew: for developer machines, brew upgrade keeps formulae and casks current, but it runs in user context and is not a fleet patching tool on its own.

Whatever you choose, inventory matters. You cannot patch what you do not know is installed, so collect application inventory through your MDM or a tool such as osquery, covered in the logging and detection guide.

Verify it

# Current OS version and build
sw_vers

# Pending updates
softwareupdate --list

# Installed update history
softwareupdate --history

# Automatic update preferences (managed values come from profiles)
defaults read /Library/Preferences/com.apple.SoftwareUpdate

# Installed XProtect definitions version
defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info.plist CFBundleShortVersionString

# Install history including background security data updates
system_profiler SPInstallHistoryDataType | grep -A 4 -i xprotect

Compare the OS version against Apple's security releases page. In a fleet, use your MDM's inventory reports rather than logging into individual machines, and alert on devices that fall behind the current supported version.

Common pitfalls

• Turning off security responses and system files. This freezes XProtect data and delays Background Security Improvements. Lock it on with a profile.
• Scripting updates as root on Apple silicon. Root is not a volume owner. Use MDM with an escrowed bootstrap token instead.
• Deferrals without deadlines. Deferrals quietly become permanent. Always pair them with enforcement.
• Ignoring unsupported hardware. Macs that cannot run a supported macOS release eventually stop receiving security fixes. Plan replacements.
• Forgetting third-party apps. A fully patched OS with an outdated browser is still exposed.

Checklist

• Automatic check, download, security responses and system data files enabled and managed.
• DDM enforcement declarations in place with a documented deadline policy.
• Bootstrap token escrowed so MDM can authorize updates on Apple silicon.
• Deferrals, if any, short and scoped to testing.
• Third-party apps inventoried and patched through a managed process.
• Fleet version compliance reviewed at least weekly and after every Apple security release.