What Is System Integrity Protection on Mac?

The short answer. System Integrity Protection is a policy enforced by the kernel that stops anything — including a process running as root — from modifying the parts of macOS that Apple ships. It was introduced in OS X 10.11 El Capitan in 2015, after a decade of malware that installed itself into the system and survived every attempt to remove it, and it is the reason that “just reinstall the app” now works as a removal instruction.

This guide covers what it protects, what it restricts, how the sealed system volume changed the rules in macOS 11, and the narrow set of situations where turning it off is the right answer.

The problem it was invented for

Before SIP, the security model was Unix’s: root can do anything. That is a coherent model for a server, where the administrator is the person who installed the operating system. It is a poor model for a laptop, where the administrator is also the person who double-clicks installers downloaded from the web.

The result, through the early 2010s, was a category of Mac malware that behaved like a system component. It ran an installer that asked for an administrator password — a request users had been trained to grant — and then wrote itself into /System/Library, installed a launch daemon, and hooked into the system so that deleting the application did nothing. Adware was the common case; WireLurker and iWorm were the ones that made the news. Removing them required disabling the protection that did not yet exist and editing system files by hand, which is not a thing a normal user can be asked to do.

SIP’s insight was that the operating system has a legitimate interest in its own integrity that is independent of who is asking. Root can install software, change settings and read your files. Root cannot replace the kernel, because nothing legitimate needs to.

How the policy is actually enforced

SIP is not a background process and not a daemon you can kill. It is a set of flags held in NVRAM and read by the kernel at boot, plus a policy table inside the kernel that decides, for each of a small number of operations, whether the calling process may perform it.

The decision is made in the kernel’s own code paths — the ones that write a file, load a kext, attach a debugger, or call task_for_pid. When a process attempts one of those operations against a protected target, the kernel checks the flags and returns EPERM if the policy forbids it. That is why the failure looks like a permissions error rather than a blocklist: there is no list of banned binaries, only a rule about what kind of change is being attempted and where.

Two consequences follow from the design. First, SIP cannot be bypassed by running as root, because root is not what it is checking. Second, it cannot be updated from a running system, because a running system should not be able to lower its own protection — which is why every change happens in Recovery.

The flags themselves are visible in csrutil status, and on current macOS the output names them:

csrutil enable sets them all. csrutil enable --without kext sets all but one, which is the narrow setting a driver developer actually needs — and the reason the blanket “disable it” advice is lazy: the specific flag exists and is usually the one required.

A short history of what changed

The feature has been extended twice in ways that matter to anyone following old instructions.

2015, OS X 10.11. SIP ships with the protections above. The immediate effect is that the “repair permissions” ritual, which had been standard advice for fifteen years, stops doing anything useful to the system volume — and eventually stops being offered at all.

2020, macOS 11 Big Sur. The sealed system volume arrives. The system volume becomes a signed APFS snapshot, verified at boot, and modifying it requires breaking the seal as well as disabling SIP. This is the change that broke most of the internet’s instructions for patching system files, and it is why a sudo command that worked in 2019 now returns “operation not permitted” on a machine where SIP is nominally off.

Later versions tightened the boot chain on Apple Silicon, made the seal part of the update process, and moved kernel extension approval into the boot security policy. The direction has been consistent: more of the system is verified, and fewer operations are available to an administrator who is not Apple.

The pattern is worth internalising because it predicts the answer to most questions in this area. If a technique depends on modifying something Apple ships, it has either been closed or now requires breaking the seal — and the workarounds that persist are the ones that modify something outside the protected set, such as /usr/local or a user-level configuration.

What to do when an app insists

The request appears in three shapes, and each has a different answer.

“This app requires System Integrity Protection to be disabled.” The app modifies system files. Ask what it modifies, and check whether a version exists that does not — several categories have moved on: audio routing, window management and system theming all have approaches that work within the rules. Suspicious Package will show you the installer’s payload if you want to know before deciding.

“This app requires a kernel extension.” That needs Reduced Security on Apple Silicon, not SIP disabled. It is a different setting in a different place, and granting it does not require weakening SIP.

“This app requires full disk access.” That is a privacy permission, not a SIP matter, and it is granted per app in System Settings → Privacy & Security. It does not require disabling anything.

The third case is the most common and the most often confused with the first, because both produce a dialog that mentions security and neither explains the difference. A TCC permission is a grant from you to an app; SIP is a limit on what any app can do. Only one of them should ever be lowered for convenience.

What it protects

The protected paths, as Apple documents them:

Note the exception: /usr/local is deliberately not protected, which is why Homebrew installs there on Intel Macs and why the same pattern works elsewhere. The rule is not “the filesystem is read-only”, it is “the parts Apple ships are not yours to change”.

Alongside the paths, SIP restricts a set of capabilities that are used to modify the system in less obvious ways:

• Loading kernel extensions. A kext runs in the kernel, so an unsigned one is a complete compromise. SIP requires them to be signed and, on Apple Silicon, requires the machine to be in a reduced-security boot mode.
• Attaching a debugger to Apple’s processes. Without this, any process running as root could read another process’s memory and extract credentials or inject code.
• task_for_pid on system processes, which is the API behind most code injection.
• dtrace on system processes, which would otherwise let a root process observe everything the kernel does.
• Modifying NVRAM in the ways that change boot behaviour.

Those restrictions are why SIP is more than a file permission: they close the routes by which a root process could achieve the same result without writing to a protected path.

The sealed system volume, and why old instructions stopped working

macOS 11 Big Sur added a second lock, and it is the one that confuses people following older guides.

The system volume is now a cryptographically sealed APFS snapshot. Every file on it is hashed into a tree, the root of that tree is signed, and the signature is verified at boot. Modifying a single byte breaks the seal and the machine refuses to boot from that snapshot. The practical consequence is that the system volume is not merely protected from writes — it is verified, and a modification that somehow got through would be detected rather than trusted.

This is why “disable SIP and edit the file” no longer works on its own. The setting that governs the seal is separate:

csrutil authenticated-root status
csrutil authenticated-root disable

Both have to be off before the system volume can be written to, and both are set from Recovery. The pairing explains the most common failure: someone disables SIP, tries to modify a system file, gets a permission error, and concludes SIP did not disable. It did; the seal is the second lock.

How to check the current state

In Terminal, with no special privileges:

csrutil status

The answer is one line: System Integrity Protection status: enabled, or disabled. Newer versions also print the individual flags — filesystem protection, debugging restrictions, kext signing, NVRAM protection — which is useful when you are trying to work out which part is off.

For the seal:

csrutil authenticated-root status

A machine with SIP enabled and the seal intact is the normal, fully protected state. Anything else is a machine that has been modified for a purpose, and it is worth knowing which.

Turning it off, and back on

Both operations happen in Recovery, because that is the only environment where the policy can be changed — by design, since a running system should not be able to lower its own protection.

On Apple Silicon: shut down, hold the power button until Loading startup options appears, choose Options, and continue to Recovery. Utilities → Terminal.

On Intel: restart holding Command-R (or Option-Command-R for the latest compatible macOS). Utilities → Terminal.

Then:

csrutil disable        # turn off
csrutil enable         # turn back on

and restart. The seal is a separate command with the same pattern.

Two things to know before you do it. Disabling SIP does not require reinstalling anything, and re-enabling it does not undo whatever you changed — a system file modified with SIP off stays modified, and the seal stays broken until the system volume is reinstalled. That asymmetry is the reason the setting is worth treating as a one-way door for the machine’s lifetime: once broken, the honest state of that Mac is “modified system”, and a clean reinstall is the only way back.

Boot security on Apple Silicon is a different setting

There is a second, lower layer that people conflate with SIP, and the confusion causes real problems.

On Apple Silicon, the boot security policy — set in Recovery under Startup Security Utility — decides what the machine will boot at all: Full Security, Reduced Security, or Permissive Security. Full Security requires a signed, sealed system and does not permit unsigned kernel extensions. Reduced Security permits them, with an administrator’s authorisation. Permissive Security is what it sounds like.

SIP sits above that. You can have Full Security and SIP enabled, which is the default and the strongest state. You can have Reduced Security with SIP enabled, which is what a machine running a third-party kernel extension needs. You can have SIP disabled on a machine in Full Security mode, which is unusual and only useful for debugging userspace.

The practical rule: an app that needs a kernel extension requires Reduced Security, not SIP disabled. The two requests sound similar and are not, and granting the second when the first was needed weakens the machine for no reason.

What breaks when it is off

Disabling SIP has consequences that are not obvious until they bite:

• System updates can fail. The updater verifies the seal; a modified system volume can make an update refuse to install or leave the machine unable to boot.
• Some Apple features degrade. Apple Pay, iCloud Keychain prompts and some continuity features rely on the system being unmodified, and a modified machine is treated as untrusted.
• Security tools lose their guarantees. A firewall that relies on the system’s own integrity cannot vouch for a system that has been modified — which is why LuLu, Little Snitch and the rest still work but with a caveat.
• You cannot tell what else changed. Once the seal is broken, there is no mechanism left that would detect a modification you did not make.

The last one is the real cost. SIP is not just a lock, it is an alarm: it makes tampering detectable. Turning it off removes the alarm as well as the lock.

When disabling is legitimate

The list is short and specific.

Kernel development and driver work. Writing a kext requires loading unsigned code into the kernel. Developers do this on a dedicated machine, not on their main one.

Security research. Analysing macOS internals, testing whether a piece of malware does what it claims, or verifying a vendor’s claims about what an installer writes. A researcher who cannot inspect the system cannot do the job.

A specific class of hardware utility. Some older audio interfaces, eGPU setups and RAID controllers shipped kexts that were never signed, and there is no way to run them otherwise. This is a reason to check whether the hardware has a supported replacement before buying it.

Debugging a system component you are working on. Temporarily, on a machine you are prepared to reinstall.

That is close to the complete list. “The app told me to” is not on it, and neither is “a tutorial said this would fix my problem” — both are reasons to find a different app or a different fix.

How to tell whether SIP is doing anything for you

A useful test: look at what a piece of software asks for. An installer that wants an administrator password and then writes to /Applications is normal. An installer that wants SIP disabled is asking to modify the operating system, and the question to ask is what it needs to modify and why. Suspicious Package opens a .pkg and shows you exactly which files it will write and which scripts it will run before you install it — which is the single most useful habit in this area.

For the running system rather than the installer, KnockKnock lists what is persistently installed — launch agents, daemons, kernel extensions, browser extensions — with signing information. KextViewer does the same for loaded kernel extensions specifically, and BlockBlock watches for something installing a persistent component and asks you about it at the moment it happens. Santa goes further and enforces an allow-list, which is the enterprise answer to the same question.

None of those replace SIP. They tell you what is there; SIP is what makes “there” a smaller place.

What SIP does not do

The most useful thing to understand about SIP is the boundary of what it covers, because the assumptions people make about it are usually about something else.

It does not scan anything. There are no signatures, no heuristics and no scanning engine. A malicious app that runs as you and reads your documents is entirely outside SIP’s remit; it only becomes SIP’s problem if it tries to modify the system.

It does not stop persistence. This surprises people. /Library/LaunchDaemons and /Library/LaunchAgents are not protected, because that is where legitimate third-party software installs its background components. Malware can write a launch daemon there and survive a reboot without ever touching a protected path. That is why the tools in this category list persistent components rather than relying on SIP to prevent them: KnockKnock enumerates what is installed, BlockBlock asks at the moment something is added, and Santa enforces an allow-list for what may run at all.

It does not protect your files. Documents, photos and mail are yours, not Apple’s. File permissions and, at rest, FileVault are what cover those.

It does not vet the code that is allowed to run. A signed kernel extension from a developer whose certificate was later revoked, or from a developer who turned out to be malicious, loads on a machine with SIP enabled. Signing proves who wrote the code, not that the code is safe.

It is not a backup. A modified system volume, a failed update or a broken seal are all recoverable from a backup and not recoverable from SIP. The two are unrelated protections that people conflate because both are described as “safety”.

Put together, the boundary is clear: SIP protects the operating system’s integrity, and nothing else. A Mac with SIP on still needs Gatekeeper, still needs a backup, still needs you to be careful about what you install — it just cannot be permanently compromised by a root-level installer, which was the specific problem that made the feature necessary.

FAQ

Does SIP protect my documents? No. It protects the operating system, not your data. File-level protection for your own files is FileVault at rest and file permissions while running. SIP is specifically about the system Apple ships.

Why can I still install apps if SIP is on? Because /Applications is only protected for Apple’s own apps, and third-party installers write there normally. SIP restricts modification of what Apple shipped, not installation of what you chose to install.

Does SIP stop a malicious kernel extension? It requires kernel extensions to be signed with a Developer ID and, on Apple Silicon, requires the machine to be in a reduced-security boot mode before any will load. A signed kext from a compromised developer still loads, which is why kext signing is a mitigation rather than a guarantee.

Is SIP the same as the T2 chip or the Secure Enclave? No. SIP is a policy enforced by the kernel at runtime. The Secure Enclave is hardware that holds keys and enforces the boot policy. They defend different things, and a Mac has both.

Can I check whether an app needs SIP disabled before installing it? Open its installer with Suspicious Package, or read its documentation for the phrase “requires SIP to be disabled”. An app that needs it will say so, because otherwise it does not work at all — and that sentence in the documentation is the clearest possible signal about how it is built.