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.

When Mac OS X 10.0 was released in March 2001, privileges, permissions and security adopted a conventional model based on BSD and Unix. Those sufficed for 15 years until the release of OS X 10.11 El Capitan in September 2015, when System Integrity Protection, SIP, was introduced. This article outlines its history over the last decade.

2015 Introduction

The first public account of SIP was presented by Pierre-Olivier Martel at WWDC 2015 in June, and documented in Apple’s System Integrity Protection Guide that September, which hasn’t been revised since. These changes were justified as adding a further layer of security protection to prevent attackers from gaining full control by escalating privileges to root.

Three types of protection were promised:

• file system protections, so that system files could only be modified by processes signed by Apple;
• prevention of runtime attachment, code injection, or modification of system binaries, with modifications only permitted by Apple’s installers and updaters;
• kernel extensions (kexts) had to be signed using special certificates granted by Apple.

Each Mac’s SIP configuration was stored in NVRAM, and controlled by the csrutil command used in Recovery mode.

When released, the csrutil command provided some degree of separate control over six groups of features: file system protections, debugging protection, DTrace protection, kext signing requirement, NVRAM and ‘Apple internal’ protection. One immediate beneficial side-effect was that SIP prevented permissions being changed for system files, and that made the practice of repairing permissions on them unnecessary, allowing removal of support for that procedure from Disk Utility.

2015 Conflicts

Press reviews of the SIP feature were divided, with some claiming it was a sign that OS X was being closed down and moved to the iOS security model, while others considered that few users would notice much difference.

Problems resulting from SIP were reported soon after El Capitan’s release. For example, some older Mac models intentionally prevented their use with Apple USB SuperDrives. One workaround to address that had been to modify one of the files now protected by SIP, which consequently required the user to disable SIP to make that change.

As kernel extensions hadn’t previously been required to be signed at all, other early casualties were all older unsigned kexts, making some apps unusable unless a new version was provided with a correctly signed kext.

2016 Error

Late in 2016, it became clear that Apple had shipped a substantial batch of new MacBook Pro systems with SIP disabled. At that time, System Information was unable to report SIP status, and the only way to enable protection was to start that Mac up in Recovery mode and use the csrutil command in the Terminal app there. That applied to macOS Sierra 10.12 to 10.12.1.

To make this easier, Apple changed csrutil so that it could enable SIP when invoked in normal running mode, provided it was run with elevated privileges obtained using sudo. Despite that, some of those affected MacBook Pro models didn’t have SIP enabled correctly for several months.

2017-18 Problems

Over the following years, SIP continued to cause irritations that infuriated some users.

Bundled apps in the main Applications folder were protected by SIP, and that prevented the user from modifying them. As the handling of kexts changed, it was discovered that SIP made it awkward to remove old kexts the user had installed. That was because the folder /Library/StagedExtensions was put under the protection of SIP by attaching a com.apple.rootless extended attribute to it.

One reading of that extended attribute is that only Apple’s KernelExtensionManagement service can give permission for changes to be made within that folder, and the folders within it.

2020 Extended attributes

Apple later used SIP to lock down individual extended attributes (xattrs) attached to regular unprotected files. The first example of this was the undocumented com.apple.macl xattr that macOS started to attach widely to all user documents. Presence of that xattr was implicated in some problems in which those documents became locked down and unable to save changes, despite permissions and other visible attributes showing that the user had full ownership of the file. The only workaround for this has been to copy the file to another volume, where the xattr no longer has the protection of SIP, and can be stripped.

When Apple later introduced another undocumented xattr com.apple.provenance, that too was sometimes but not always protected by SIP, although that hasn’t been implicated in problems visible to the user.

2022 Launch constraints

Launch constraints were introduced in macOS 13 Ventura and iOS 16 in 2022. Every executable binary in the system now has a set of rules determining the requirements for that binary to be launched. These include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch. Together these form that code’s launch constraints. To make those constraints simpler, they come in different categories, ranging from 0, in which there are no constraints at all, to combinations that prevent launch by processes that aren’t themselves part of the system and require the code itself to be on the System volume.

Although Apple has documented these for developers, they can cause unexpected behaviour for users, who haven’t been given any explanation. Testing has demonstrated that launch constraints are dependent on SIP, so must be assumed to have been added to its list of protections.

2024 Malware scans

Many users have reported slowing app launch times in recent versions of macOS. In February 2024, Jeff Johnson investigated these, and concluded that the cause was the macOS security system repeatedly performed malware scans against a growing set of Yara rules. These stopped when SIP was disabled, implying that this is yet another protection that has been added to those controlled by SIP.

2024 Current protections

Current user documentation for SIP explains only its file system protection, csrutil‘s man page refers to its usage information, but from that and XNU it’s possible to separate out its controls to include the following, at least:

• Filesystem Protections, disabled by CSR_ALLOW_UNRESTRICTED_FS, abbreviated to fs
• Debugging Restrictions, disabled by CSR_ALLOW_KERNEL_DEBUGGER and CSR_ALLOW_TASK_FOR_PID, abbreviated to debug
• DTrace Restrictions, disabled by CSR_ALLOW_UNRESTRICTED_DTRACE, abbreviated to dtrace
• Kext Signing, disabled by CSR_ALLOW_UNAPPROVED_KEXTS, abbreviated in csrutil to kext
• NVRAM Protections, disabled by CSR_ALLOW_UNRESTRICTED_NVRAM, abbreviated to nvram
• Apple Internal, disabled in XNU by CSR_ALLOW_APPLE_INTERNAL, and only disabled when SIP is fully disabled
• BaseSystem Verification, abbreviated to basesystem
• Boot-arg Restrictions, disabled with nvram
• Kernel Integrity Protections, disabled with kext
• Authenticated Root Requirement, disabled by CSR_ALLOW_UNAUTHENTICATED_ROOT, managed separately using csrutil authenticated-root disable and enable
• Additional configuration flags available in XNU that don’t appear to be directly supported by csrutil include: CSR_ALLOW_TASK_FOR_PID, CSR_ALLOW_DEVICE_CONFIGURATION, CSR_ALLOW_ANY_RECOVERY_OS and CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE. Those should be disabled when SIP is fully disabled.

2015-2025 Vulnerabilities

Over the last decade, many vulnerabilities have been discovered in SIP that have allowed parts of its protections to be bypassed. Among the most recent is CVE-2024-44243 discovered by Jonathan Bar Or (@yo_yo_yo_jbo) of Microsoft Threat Intelligence and Mickey Jin (@patch1t), and fixed in the update to macOS 15.2 Sequoia. However, this wasn’t fixed in Sonoma until the following round of updates (14.7.3), and appears to remain unpatched in Ventura 13.7.8.

Microsoft’s report explains how bypassing just one of SIP’s many protections can give access to bypasses of more or all of SIP’s other protections. Note also how Apple’s description of the vulnerability in its security release notes refers to StorageKit but doesn’t reveal that this affected SIP.

Over the last decade, SIP has grown like Topsy from three protections that seemed worthwhile and simple, into a protean collection of many parts that remain largely undocumented and pervade much of modern macOS security.

References

Wikipedia’s account, still largely based on SIP in 2015
This blog on csrutil controls