Some who use SilentKnight for the first time discover that their Mac has been running for months with one of its security systems disabled. As macOS doesn’t have a dashboard to warn you of such dangerous settings, you may not notice until it’s too late. This article explains how to check those essential security settings on Macs with T2 or Apple silicon chips, and how to put them right. Intel Macs without T2 chips are different, and are covered in a previous version.

Secure Boot

Running your Mac in Full Security ensures it gets full protection from its Secure Boot technology. In an Apple silicon Mac this prevents it from loading third-party kernel extensions, and requires recent approved versions of macOS. Check this in System Information by selecting the Controller item in its Hardware section, or in SilentKnight.

This is controlled in Startup Security Utility, accessed from Recovery. Note that it only works with the paired Recovery system, the one you normally use; Apple silicon fallback Recovery doesn’t have this ability.

If you need to run kernel extensions or other software that can’t be loaded in Full Security, use Startup Security Utility to set the Mac to Reduced Security, and enable kexts. Avoid doing this if at all possible.

Settings are different for Intel Macs with T2 chips, where there are three levels of boot security, and the most common reason for reduction from Full Security is to enable that Mac to boot from external drives, something that Apple silicon Macs can do in Full Security.

System Integrity Protection (SIP)

Since El Capitan, macOS has protected all its system files, even down to bundled apps, using System Integrity Protection. This should make it impossible for malware or other software to change those protected files. SIP is also required for a wide range of other security protection, and should be fully enabled unless you have a compelling reason for disabling it partially or completely. In Apple silicon Macs, its status is reported in System Information’s Controller item, but Intel Macs instead give it in the Software section. It’s also checked by SilentKnight and Skint.

You can turn SIP off, something very occasionally needed to perform certain essential tasks. Doing so requires you to start up in Recovery mode, enter a command in Terminal there, and restart; Apple silicon Macs also need to have their boot security reduced in Startup Security Utility before SIP can be disabled.

To enable SIP, start up in Recovery mode, open Terminal, and type the following command:
csrutil enable; reboot
Once that’s done your Mac will restart in normal mode, and you should confirm that SIP is reported as enabled.

If you ever do need to disable SIP, do yourself a favour and put a sticky note on your Mac’s display to remind you to turn it back on.

Gatekeeper/XProtect

Gatekeeper runs checks on apps when they’re opened, and those can include scans for known malicious software using XProtect. As part of your Mac’s frontline protection against malware, you should leave those enabled unless there’s a compelling reason to temporarily disable them. However, I don’t know of anywhere in the macOS GUI that informs you whether these checks are being performed, although they are reported by SilentKnight and Skint.

If it has been disabled, you may be able to enable it using the command
spctl --enable
but chances are that you will instead need to invoke
sudo spctl --global-enable
requiring you to authenticate using your admin password. Be careful with those commands: the hyphens before enable and global-enable aren’t long dashes, but two separate hyphens.

Signed System Volume (SSV)

When you install Big Sur or later, the vast majority of its system files are saved in its System volume. For your Mac to boot from this, it has to be turned into a snapshot, sealed using a tree of cryptographic hashes, and the master seal ‘signed’ by a hash, which is compared against that set by Apple. This signed system volume is extremely secure and thoroughly reliable. On Intel Macs, this is only reported in Disk Utility, but Apple silicon Macs list it in System Information as well. It’s also reported by SilentKnight and Skint.

The SSV should always be enabled. If it isn’t, you’ll need to re-install macOS.

FileVault

Intel Macs with T2 chips and Apple silicon Macs encrypt the whole of the Data volume on their internal SSD. By default, that uses an internally-generated key that’s used automatically when any user logs in. Although it provides good security in most situations, you’re far better off enabling FileVault, as that protects the encryption key with your password as well. This imposes no overhead on accessing encrypted data, and provides valuable protection for your data at no cost.

Check whether FileVault is enabled in Privacy & Security settings, where you can enable it if it’s not already turned on. SilentKnight checks it as well.

macOS and firmware

To ensure your Mac and its apps are best protected from malware, keep its firmware and macOS up to date. As those are updated together, Macs with T2 or Apple silicon chips that are running the most recent release of their major version of macOS will also be running the current firmware, which no longer needs to be checked separately. Check the version of macOS in the About This Mac command at the top of the Apple menu.

Apple lists current supported versions of macOS on its Security Releases page. Those, and versions of security data software, are also listed and detailed here on this page.

If your Mac is running an older release of macOS and its firmware, update them together using Software Update in General settings.

XProtect Remediator scans

This anti-malware scanner performs automatic background scans to detect and remove a wide range of malicious software. It’s normally scheduled to run at least once a day, when your Mac is awake but not busy, and supplied with mains power. You’re wise to check that its scans are being run correctly, and will probably want to know if it has detected and remediated any malware. SilentKnight and Skint run a quick check of its activity over the previous 36 hours, and XProCheck provides detailed reporting and analysis.

Over the last year or so, XProtect Remediator has been using a timer during its scans, and automatically cancelling them if a scan takes longer than allowed. On many Macs, most scans are terminated early, and that results in warnings from SilentKnight and Skint. If you’re concerned, check the reports in XProCheck, where you’ll see that plugin was cancelled with a status_code of 30, as is typical with the timer.

Check:

• the Mac boots in Full Security, if possible,
• SIP is enabled,
• Gatekeeper/XProtect is enabled,
• it has booted from an SSV,
• FileVault is enabled,
• it’s up to date with macOS,
• XProtect Remediator scans are taking place daily.

SilentKnight does all of those and more.

Each of the main security services in macOS such as XProtect relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.

Currently, those most frequently updated are XProtect and XProtect Remediator, the former being updated most weeks. However, Sequoia changed the way that XProtect’s data is updated, and it’s now intended to occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.

This article details each of the main security data files found in macOS 26 Tahoe, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, left frozen in time, or removed completely. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.

Main Security Data

XProtectPayloads, alias XProtect.app and XProtect Remediator
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app in the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every month or so using Software Update or a substitute.

XProtectPlistConfigData
These are whitelists and blacklists used by XProtect. Since Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle in the Data volume; the secondary is also in the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and can used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Tahoe is also intended to update the primary bundle via a CloudKit connection to iCloud. This is routinely updated every week, at the same time as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, if a more recent version is available.

Bastion
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. This doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb, and reports them to Apple as security intelligence. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated irregularly.

AppleKextExcludeList
Latest version: 21.0.0, 9 September 2025 (26.0 release).
This is a huge list of kernel extensions that are to be treated as exceptions to Tahoe’s security rules, and is stored in the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist. At one time, this was a blacklist of kexts to block, but in Mojave 10.14.5 that changed, and it has since been a list of over 18,000 kexts that are given exceptional treatment, as explained here. However, this doesn’t appear to apply to Apple silicon Macs, as they have their own separate rules about which kexts to allow and which to block, that are far more stringent. Accordingly, this list should go away in macOS 27.

Others

IncompatibleAppsList
Latest version: 260.200 (26.0 release).
This is a bundle in the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.

Vestigial Data

MRTConfigData
Last version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored in the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but is installed later as a security data update.

Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database in the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db and may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database isn’t currently used.

Gatekeeper E Configuration Data (GKE), alias Gatekeeper Compatibility Data
Latest version: 1.0 dated 2 October 2019.
This was an SQLite database in the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since. Although this is still downloaded and installed, it’s nowhere to be found in Tahoe, and appears to be a historical remnant.

Last updated: 19 September 2025.

It’s now almost a year since macOS Sequoia changed security updates, and I’m still being asked how these work. I also suspect a few are wondering whether there will be any changes coming in Tahoe. This article summarises how these work at the moment, and are expected to continue.

Three XProtects

All reasonably recent versions of macOS have three different security features known as XProtect:

• The oldest XProtect scans code just before it’s run. This uses one or two XProtect.bundle items containing Yara rules that determine the known malware it can detect. Currently, those are updated once a week.
• The newer XProtect.app in /Library/Apple/System/Library/CoreServices is only used in Catalina and later. This runs daily scans to look for malware using its scanning modules, and is also known as XProtect Remediator as it removes malware. Currently, this is updated once a month.
• The newest and hidden Behavioural XProtect watches constantly for suspicious behaviour such as apps accessing folders used by Safari and other browsers, according to its Bastion rules. Those rules are contained inside XProtect.app and are updated with it.

So for the time being, you should expect your Mac to update XProtect’s bundle every week or so, and the XProtect app (XProtect Remediator, and Bastion rules) every month.

XProtect Remediator

Roughly once a month, your Mac should download and install a file named something like XProtectPayloads_10_15-155, where the last three digits are its new version number. This is delivered and installed automatically through Software Update, if you have it set to Install Security Responses and system files. You can also download and install it manually using the softwareupdate command, or, easiest of all, using my free SilentKnight.

Legacy XProtect

All fairly recent versions of macOS have a copy of XProtect.bundle in /Library/Apple/System/Library/CoreServices. This is also downloaded and installed using Software Update, softwareupdate or SilentKnight, and the file name is something like XProtectPlistConfigData_10_15-5314. In versions of macOS before Sequoia, this is the only copy of that bundle, and once that has been installed, XProtect is up to date.

iCloud XProtect

Almost a year ago, Apple changed XProtect in Sequoia, and since then Tahoe has followed suit. They not only have legacy XProtect with its XProtect.bundle in /Library/Apple/System/Library/CoreServices, but they have a separate copy of the same bundle in /private/var/protected/xprotect. If you compare those carefully, you’ll see differences, as the legacy copy is signed, but the other isn’t.

When XProtect is updated, Sequoia and Tahoe therefore download and install those two copies separately. The legacy copy is updated exactly the same as in older macOS, through Software Update, softwareupdate or SilentKnight.

The new copy of XProtect.bundle in /private/var/protected/xprotect can’t be updated by softwareupdate or SilentKnight, though. Updating the legacy copy doesn’t alter or update that, which is instead performed over a connection to iCloud. To check and update that copy, you can use the xprotect command in Terminal. The command
xprotect version
returns the version of XProtect installed in the new (iCloud-based) location, which can be different from the legacy copy. You can check whether an iCloud update is available using the Terminal command
sudo xprotect check
and entering your admin password when prompted to do so. If that version number is higher than that currently installed in the new location, then the command
sudo xprotect update
will download and install XProtect from iCloud into its new location.

Can the two XProtects interact?

In Sequoia and Tahoe, both versions of XProtect.bundle will eventually be downloaded and installed automatically. Sometimes, when you’re installing one, the other is also updated. That doesn’t occur because one updater can also update the other copy, but simply because the automatic update process has run. In the early days of Sequoia, the xprotect update command could update the iCloud version from the legacy version, but that stopped working many months ago.

Another behaviour that can appear confusing is when legacy XProtect updates but the iCloud version doesn’t. That often occurs soon after a new version is released, as it almost invariably is made available via Software Update first, so resulting in the legacy version being updated quickly. Sometimes the iCloud update isn’t made available for several hours later, and that may give the impression that updating the legacy version is somehow blocking the iCloud update. That’s easy to check using the xprotect check command: until that reports the new version is available, the xprotect update command won’t work.

How do I know when these updates are available?

I am sometimes asked where I look to check when XProtect and other updates are available, as if Apple publishes this information somewhere. It doesn’t. I use the same tools that you can use, SilentKnight to check for updates via softwareupdate, and the xprotect command tool for those delivered from iCloud. As soon as I find a new update, I install it here, update the databases on Github used by SilentKnight and Skint, analyse the contents of the update, post the announcement here, post that on X/Twitter, then update this blog’s System Updates page.

Do different Macs update differently?

All the code for these updates is contained in the copy of macOS installed in the SSV, the signed snapshot of the System volume that runs your Mac. For any given version of macOS, all Macs, both Intel and Apple silicon, have identical SSVs, although there are differences in their cryptexes and Data volumes. Thus, XProtect updates work exactly the same on all Macs running Sequoia 15.6.1 from my ancient iMac Pro to my latest Mac mini M4 Pro, and I check those with every update as well.

I hope you find these helpful.

Security utilities that detect known malicious software do so using sets of detection rules. Since their introduction by Victor Alvarez of VirusTotal 12 years ago, the most common method of expressing these rules is in a text file with the extension .yara. Apparently YARA stands for either YARA: Another Recursive Acronym, or Yet Another Ridiculous Acronym.

Yara rules are used extensively in macOS by both the original XProtect and its sibling XProtect Remediator. Those of XProtect are found in the XProtect.yara file in XProtect.bundle, in /Library/Apple/System/Library/CoreServices and its additional location in /private/var/protected/xprotect in Sequoia and later. Further Yara rules are also encrypted and embedded in XProtect Remediator’s scanning modules, as detailed by Koh M. Nakagawa in the FFRI Security GitHub.

As used by Apple, each rule can consist of up to three sections:

• meta, containing the rule’s metadata including a description and in more recent cases a UUID for the rule.
• strings, specifying some of the content of the file, typically in the form of hexadecimal strings such as { A0 6B }.
• condition, a logical expression that, when satisfied, meets the requirements of that rule, so identifying it as malicious.

I’ll exemplify these using Yara rules used in XProtect version 5310.

Private rules

At the start of the Yara file are any private rules. These are a bit like macros, in that they define properties that are then used in multiple rules later. Laid out in compact form, an example reads:

private rule Shebang
{ meta:
description = "private rule to match shell scripts by shebang (!#)"
condition:
uint16(0) == 0x2123
}

This starts with description metadata for this private rule, then states the condition for satisfying this rule, that the first 16-bit unsigned integer in the file contains the hex 0x2123, the UTF-8 characters 0x21 or ! and 0x23 or #. In the reverse order of #! they’re known as the shebang, and the opening characters of many shell scripts, but in this rule they are given the other way around because of the byte order used in the 16-bit integer.

This defines what’s required of a Shebang, and can be included in the conditions of other Yara rules. Instead of having to redefine the same feature in every rule, they can simply include that Shebang rule in their condition.

Regular rules

After 3-5 private rules, the XProtect Yara file goes on to enumerate 372 normal rules, including this one:

rule XProtect_MACOS_SOMA_JLEN
{meta:
description = "MACOS.SOMA.JLEN"
uuid = "4215C9D4-57D5-4D30-82E1-96477493E8D5"
strings:
$a0 = { 4c 8d 3d ?? 74 0b 00 4c 8d 25 ?? ?? 0b 00 4c 8d 2d ?? ?? 0b 00 48 8d 5d c0 }
$a1 = { 73 62 06 91 d4 03 00 f0 94 42 21 91 }
condition:
Macho and ( ( $a0 ) or ( $a1 ) ) and filesize < 5MB
}

This rule has its internal code name as its description, and has been assigned the UUID shown. It then defines two binary strings, a0 and a1, the former containing ‘wild’ values expressed using the question mark ?. The condition for satisfying the rule is that the file must:

• be a Mach-O binary, and
• contain either a0 or a1, and
• its size must be less than 5 MB.

Further details about Yara rules are given here.

Implementation

There are standard implementations that can check files against custom sets of Yara rules. Rules are normally compiled into binary form from their text originals before use. Full details are given on VirusTotal.

Apple’s use of Yara files is mysterious, as for some years all the descriptions used arbitrary code names as obfuscation. When the source of all the rules is given in plain text, it’s hard to see what purpose that served, and it meant that users were told that MACOS.0e32a32 had been detected in an XProtect scan, for instance. Thankfully, Apple has more recently replaced most of those with more meaningful names.

I’m grateful to Duncan for asking me to explain this, and hope I have been successful. I’m also grateful to isometry and an anonymous commenter for straightening out the confusion over the Shebang.

Six years ago, in July 2019, Macs came closer to disaster than at any time before or since. Millions of Mac users around the world had, at some time or other, installed Zoom conferencing software, and in doing so had unknowingly put their Macs at risk. For their convenience, the old Zoom installers of that time also installed a hidden web server that was left running. That was capable of reinstalling the Zoom client, and had been discovered to contain an easily exploitable vulnerability that exposed all those Macs to remote attacks.

The only solution was for Apple to harness its old Malware Removal Tool, MRT, to remove that web server from all Macs before they came under attack. Although MRT had been widely criticised for what others considered to be weakness, on this occasion it proved its value. MRT version 1.45 was released by Apple on 10 July 2019, and averted that potential catastrophe.

Three years later, in the summer of 2022, Apple replaced MRT with its successor, XProtect Remediator or XPR, which has been vastly improved, and still contains the remnants of MRT in its MRTv3 scanning module. As Apple documents almost nothing about XPR, it has been up to others to dive deep inside it, among them Koh M Nakagawa, @tsunek0h, of FFRI Security. While others have merely scratched the surface, he has just presented a superb and deep account of XPR at Black Hat USA. You can download the slides for his presentation from here.

Status_code 30 PlugInCanceled

If you check XPR scans using SilentKnight or XProCheck, you’ll be aware that for many months some of them are terminated prematurely with a status_code of 30 and the message PlugInCanceled. This most commonly affects Adload scans, and still occurs in beta-releases of macOS 26 Tahoe. According to Koh’s research, the Adload scanning module alone contains over 1,000 Yara detection rules, accounting for the long time it takes whenever XPR runs a set of scans.

Before XPR started terminating its scans as it does now, a full set could take an hour or more, so XPR has started using a timer. If the scan exceeds the time allowed, then it will be abruptly terminated, resulting in this status_code and message. There’s nothing the user can do to avoid it, and we’re surprised that XPR continues to exhibit this behaviour.

Laptop Macs

The other significant limitation in XPR affects those using MacBook Pro, MacBook Air and MacBook models. Because XPR scans take a substantial amount of energy, even when run almost entirely on the E cores of Apple silicon Macs, daily full scans will only be run when those laptops are using mains power, and won’t be run at all on battery.

As XPR scans are also normally run when a Mac is awake but only under a light load, it’s possible for a laptop to go several days without running an XPR scan. The only solution is to leave it connected to mains power, awake and doing little else for an hour or so, when it should seize the opportunity to catch up with that and other important background tasks with similar requirements.

Unfortunately, XPR won’t warn you that it hasn’t run any scans for several days, but SilentKnight and XProCheck will.

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5309, and to XProtect Remediator for all macOS from Catalina onwards, to version 153. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect add a single new detection rule for MACOS.SOMA.JUENB, part of the Soma/Amos family.

XProtect Remediator doesn’t change the list of scanner modules.

There are extensive changes to the Bastion rules, which add a new definition for common system binaries, extend Rule 1 coverage to include support folders for more browsers, tweak Rules 3 and 14-17, and add new Rules 18-24.

You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-153 and XProtectPlistConfigData_10_15-5309.

Sequoia and Tahoe systems only

The XProtect update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5304 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update