If your Mac is running macOS Sequoia version 15.2 and you keep an eye on its security data updates, you may have noticed that those have changed again. Perhaps the only way to make sense of what has happened is to understand how XProtect updates work in recent versions of macOS.

Before doing that, there are two important issues to make clear:

• Despite their names, XProtect and XProtect Remediator are different, and in Sequoia are updated using different mechanisms. XProtect is run on-demand when macOS is about to execute code, while XProtect Remediator runs scans for malware in the background about once a day. This article is only about how XProtect updates, as XProtect Remediator is still updated using the softwareupdate mechanism, and that hasn’t changed.
• Sequoia obtains XProtect updates through a connection to iCloud that is independent of whether your Mac is logged into your Apple Account in iCloud. So long as your Mac is connected to the internet and nothing blocks its iCloud connections, those updates will be available to it, regardless of whether it’s connected to your Apple Account or iCloud Drive. This is in common with other services that macOS relies on, such as making notarization checks on apps, and updating linguistics data and those used by AI.

macOS Sonoma and earlier

Like other security data updates including XProtect Remediator, XProtect is updated through Software Update, or the command tool softwareupdate, which is how SilentKnight obtains its updates too. Shortly after starting up, and at least daily after that, your Mac’s softwareupdated service contacts Apple’s software update servers and checks whether there are any updates available. If there are, they’ll be automatically downloaded and installed, provided that’s enabled in System Settings.

In this case, XProtect is installed in its traditional place, in /Library/Apple/System/Library/CoreServices as XProtect.bundle.

mcOS Sequoia 15.0-15.1.1

For this brief period, XProtect updates have been available using either of two methods.

The traditional method using Software Update or softwareupdate continues to install the XProtect bundle in its old location, where it could still be used, but the XProtect service in Sequoia expects to find it in a different location, in /private/var/protected/xprotect, where it’s still known as XProtect.bundle.

The new method installs the XProtect bundle directly into its new location, and doesn’t obtain it using Software Update or softwareupdated, but an undocumented service that connects to iCloud instead. That appears to activate at least once a day, independent of softwareupdated, and silently checks for XProtect updates in iCloud. When it finds one, that’s installed directly to /private/var/protected/xprotect but not the traditional location in /Library/Apple/System/Library/CoreServices. It’s therefore perfectly possible for the two XProtects to get out of sync, although the only one that Sequoia uses is that stored in the new location.

Sequoia also introduces a new command tool xprotect to help manage these new updates. If you run
sudo xprotect update
and the version of the XProtect bundle in the traditional location is greater than that in the new location, then the newer version will be copied to the new location to install it there as an update, instead of having to wait for the update through the new iCloud mechanism. This also provides redundancy, but relies on the two sources providing identical updates.

To add a final twist of confusion, if xprotect copies the XProtect bundle from the traditional to the new location, it does so by copying its contents, so its version number changes but the bundle itself retains its previous date of creation and modification, which can prove thoroughly confusing. The lesson here is to check the bundle by its version number, not by its dates.

macOS Sequoia 15.2 and later

In the latest release of Sequoia, the traditional method of updating XProtect is no longer used. If softwareupdate were to download and install an update, then it will only end up in the traditional location, and xprotect update can’t use that to update the new location.

In normal use, this means that the user can’t update XProtect until that new version is made available from iCloud. This ensures that the only versions provided to Macs running 15.2 and later are those intended to be used in Sequoia, but it also means that any delay in providing those via iCloud will leave Macs without the latest update.

Apple has modified the xprotect command to provide one let-out, though: use
sudo xprotect update --prerelease
and it “will attempt to use a prerelease update, if available.” Note that still can’t use a traditional XProtect update installed in the traditional location, and still has to be able to obtain the update from iCloud, but it might work when xprotect check and xprotect update can’t offer a new update yet. Note that Apple describes that early-bird version as prerelease, and it shouldn’t therefore be used as if it’s a regular release, and only for good reasons.

SilentKnight

Because of these changes, as of Sequoia 15.2, SilentKnight is no longer able to provide any assistance in updating XProtect, and its next version 3.0 will also be unable to do anything more useful than inform you that your current version of XProtect is up to date, or out of date. If it is out of date, then it’s up to you what you decide to do about it. In most cases, that should be to leave well alone and let macOS handle the update as it’s intended to.

Because time of release of XProtect updates through softwareupdate and iCloud differ, and vary around the world, availability from one source is no guarantee that the other will also be offering that update. For example, on 17 December, the softwareupdate version became available by about 1830 GMT. A prerelease version for 15.2 was available several hours before that, but the regular release wasn’t available from iCloud until early the following day. If Apple is intending to fork XProtect data for 15.x from those for older versions of macOS, the two update services will be offering quite different bundles anyway, as we experienced briefly in the early days of Sequoia.

Although I do periodically poll traditional softwareupdate servers for new updates, repeatedly doing so for iCloud updates doesn’t appear a good way to proceed, and could in any case be misleading. On the other hand I don’t think it’s intended that apps like SilentKnight should check for prerelease updates as a matter of course, and abuse of that option could lead to its removal. In other words, Apple wants full control over when your Mac can and will update to new versions of XProtect, presumably because Sequoia will be getting different updates in the future.

Summary

• If your Mac hasn’t been upgraded to Sequoia, XProtect updates continue as usual, and SilentKnight will continue to be able to find and install them as it has done in the past.
• If your Mac is running Sequoia 15.0 to 15.1.1, then it will continue to be offered XProtect updates both ways, and should continue to do so until you update it to 15.2.
• Macs running 15.2 and later now get XProtect updates differently. Neither you nor SilentKnight can alter that, unless you want to try obtaining prerelease updates through the xprotect command in Terminal. While SilentKnight and Skint will warn you when an XProtect update is expected, you should rely on macOS to handle those updates for you.

If, like me, you pay close attention to firmware updates released with macOS, you may have noticed something highly unusual if not unique this week, in the firmware updates that came with macOS Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2: those could mark the end of an era.

All new Macs since Apple transitioned to using Intel processors have one of three classes of firmware:

• Intel Macs without a T2 chip only have EFI firmware, whose version reads something like 529.140.2.0.0. These are model-specific.
• Intel Macs with a T2 chip have firmware for both their Intel systems in EFI, and iBridge for the T2, giving them a double firmware version like 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). All models with a T2 chip can run the same EFI and iBridge versions.
• Apple silicon Macs have iBoot, with a version like 11881.61.3, which is common across all models.

This complexity was the reason for my first developing EFIcienC, predecessor to SilentKnight, compiling and maintaining databases of firmware versions, and trying to help those whose Macs stubbornly refused to update their EFI firmware when they should have done. This site still has long lists of the latest firmware versions for Macs running Catalina, for example.

As the number of supported Intel Macs without a T2 chip has steadily fallen, what used to be a long and complex list has shrunk to just seven models. With the release of macOS Sequoia 15.0, Sonoma 14.7 and Ventura 13.7, Apple stopped updating the EFI firmware for Intel Macs without T2 chips, which are now frozen as they were last June and July.

When Apple released Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2 this week, it appears to have ceased updating the EFI firmware in Intel Macs with T2 chips.

T2 models were updated to EFI 2069.0.0.0.0 and iBridge 22.16.10353.0.0,0 when Sequoia 15.0 was released on 16 September 2024. No firmware updates came in the rapid update to 15.0.1, but in 15.1 those models were updated to EFI 2069.40.2.0.0 and iBridge 22.16.11072.0.0,0.

Sequoia 15.1.1 also didn’t bring any change in firmware, and 15.2 updates T2 models to EFI 2069.40.2.0.0 and iBridge 22.16.12093.0.0,0: while the T2’s firmware has been updated, no change has been made in the EFI version. As far as I’m aware that’s the first time that has happened since the initial releases of T2 firmware at the end of 2017 and early 2018. The first record I have of their version numbers is of EFI 1037.147.1.0.0 and iBridge 17.16.16065.0.0,0, since when they have come a very long way.

While I’m sure that Apple could still update EFI firmware if necessary, I think we have seen the last planned updates, with only iBridge for the T2 and iBoot for Apple silicon Macs to continue to advance with future releases of macOS. As the T2 is also Apple silicon, that means an end to the last firmware for Intel processors, after more than 18 years. The end of an era indeed, and time to pour one out for EFI firmware in Macs.

I wouldn’t like to hazard a guess at how much longer Apple will continue to support iBridge firmware for T2 chips. Firmware updates aren’t a required part of macOS updates, and most Macs cease to enjoy them well before they’re updated to their last macOS.

This is the time of year when macOS keeps offering you the upgrade to the new version of macOS, but you may not want to go there yet. This article explains how you can stay running your existing version of macOS, while keeping it up to date.

Skint and SkintM

By default, SilentKnight is intended to download all the latest updates from Apple’s software update servers. Although you can configure it to behave differently, as I explain below, you may like to look at Skint or its menu bar sibling SkintM. Those don’t check for updates, they only check installed versions. They will warn you when your Mac has fallen behind with updates, and let you decide what you want to do.

Skint and SkintM do check that your Mac is running the latest version of its major release of macOS, and is happy if you’re still running Monterey, Ventura or Sonoma, as well as Sequoia, but it will advise you when they fall behind with their security updates; after all, that’s what it’s for.

Switching SilentKnight to manual

For many, SilentKnight’s button to Install all updates is most worrying, as that might inadvertently upgrade macOS to Sequoia. In fact, it isn’t dangerous at all, but before I explain why, you can remove that button altogether. Open SilentKnight, and its Settings, and set them to look as below.

This will still download and install the updates you want, but you won’t be tempted to inappropriately install the lot of them.

Once you’ve done that, click the Set button, quit SilentKnight, and run it again. Now when it tells you there are updates to be installed, you can’t click on a button to bring upgrade disaster.

In fact, after testing SilentKnight with macOS updates and upgrades, they don’t work like that anyway. If SilentKnight were to download a macOS update or upgrade, it can’t complete its installation. macOS first tells you that the update couldn’t be installed, then offers to install it in Software Update. All you have to do is shut your Mac down at that point, then start it up in Safe mode and the update will be stopped.

However, for your comfort and safety, I recommend unticking Allow Install All Updates, just in case.

Installing only the updates you want

Having avoided the update you don’t want, you now need to download and install those that you do. Scroll the lower text view to the bottom, to reveal all the updates available. Each has an opening line that declares it’s a Label, like
* Label: XProtectPayloads_10_15-142
It’s that label you use to identify each update.

In the File menu, select the Install Named Update… command to open the manual updating window. One by one, copy and paste the label from the main window into the Name of update box and click on the Install Named Update button. SilentKnight will then tell you that it has been downloaded and installed. It only takes a few seconds to work through a list of updates like XProtect that you do want, and bring your Mac up to date without inadvertently upgrading it to Sequoia.

Further information

SilentKnight has a wealth of additional information that will help you solve problems like these. The most common are explained in its short text SilentKnight Help, in the Help menu, and there’s also a detailed Help Reference in the same menu.

Key points

Open Settings, and untick Allow Install All Updates, click Set, then quit the app. Open it again, and install each named update one at a time using that command in the File menu, pasting the Label in for each wanted update and clicking the Install Named Update button for each.

This assumes that you are running the latest version of SilentKnight, 2.11. If you’re still running version 1 you need to update for Catalina or later.

Many of you still seem puzzled as to how XProtect installs and updates in macOS Sequoia. This article tries to make this clear, so you can keep XProtect up to date.

Sonoma and earlier

Until this changed in Sequoia, XProtect has been straightforward: its data is stored in a bundle named XProtect.bundle, in the path /Library/Apple/System/Library/CoreServices, which is on the Data volume so it can readily be updated. When you or macOS downloads an XProtect update, it simply replaces that bundle with the new one. This is shown in the diagram below.

Sequoia

XProtect in macOS 15 prefers not to use the XProtect.bundle in its old location of /Library/Apple/System/Library/CoreServices (although it can do if there’s no alternative). Instead, it looks for XProtect.bundle in its new location, /var/protected/xprotect.

However, when you or your Mac use the old update system, including Software Update, softwareupdate or SilentKnight, that still installs the update in the old location, where it won’t normally be used by XProtect when making its checks. What’s supposed to happen is that at least once a day, macOS checks whether there’s a newer update in the old location. If there is, then it should automatically prepare and move that to the new location in /var/protected/xprotect for XProtect to use.

If you want that to happen immediately, then you can run the following command in Terminal:
sudo xprotect update
then enter your admin user’s password. The xprotect command tool will then complete the installation of that update from its old location in /Library/Apple/System/Library/CoreServices into its new location in /var/protected/xprotect.

There’s also a second way that XProtect in Sequoia can be updated, and that’s over a connection to iCloud. If that’s used, then the update is installed straight into its new location, and doesn’t change the XProtect bundle in the old location at all. Although Apple has used that earlier, all XProtect updates since the release of Sequoia have come using the old Software Update system, so have needed to be completed using the xprotect command in Terminal.

This is shown in the diagram below. The blue boxes show the old Software Update system, and the pink boxes are the new parts that ensure the update is installed in the new location.

SilentKnight

SilentKnight still works using softwareupdate, and can’t use the new xprotect command for updates yet, because that requires structural changes in the app that will be available in version 3. However, in Sequoia it reports the version of XProtect installed in the new location, as that’s the one that XProtect now uses.

When SilentKnight discovers a new version of XProtect via softwareupdate, it therefore installs that in the old location, in the path /Library/Apple/System/Library/CoreServices. It has no choice but to do that. Once that’s been installed to the old location, the version shown for XProtect won’t change, as that requires macOS to complete the second stage of the installation. You can then either:

• leave macOS to complete the installation itself, which should happen over the next day or so, or
• run sudo xprotect update in Terminal, which will complete that update immediately. SilentKnight will then show the updated version number correctly.

Key points

In Sequoia, when XProtect is updated by Software Update, softwareupdate or SilentKnight, you should either leave macOS to complete that installation, or run sudo xprotect update in Terminal if you want it to be updated immediately.

This only applies to macOS Sequoia: Sonoma and earlier still work as they always have done.