System Integrity Protection is the layer that stops even root from modifying system files, loading unsigned kernel extensions, or attaching a debugger to Apple’s own processes. Turning it off is a legitimate thing to do for driver development, older kernel extensions, and some low-level debugging — and it is also the first suggestion in a lot of forum threads where it was never the actual obstacle. This page covers how to check what you have, how to change it, what breaks, and how to put it back. The read-only checks below were run from a normal boot; the Recovery steps are the documented order, not something reproduced on this machine, which stayed protected throughout.
Check what you actually have
Start here, because a surprising number of “disable SIP” instructions get followed by people whose problem was something else entirely. From a normal boot:
$ csrutil status
System Integrity Protection status: enabled.That single line is what a stock machine reports. A machine whose protection has been customised rather than fully disabled reports a different, longer state — so if you get one line ending in enabled., nothing has been touched.
Two related settings have their own status queries, and both are worth reading before you change anything:
$ csrutil authenticated-root status
Authenticated Root status: enabled
$ csrutil allow-research-guests status
Allow Research Guests status: disabledAuthenticated Root is the one that matters, and it comes back in a moment.
Why it fails from a normal boot
Running the disable command from a running system does not need a warning label, because it simply refuses:
$ csrutil disable
csrutil: This tool needs to be executed from Recovery OS.
$ echo $?
77No prompt, no partial change, a distinct non-zero exit status. That is by design: if a running system could switch protection off, protection would not be worth much. The same restriction is stated in the tool’s own usage text, which marks disable and enable as “Only available in Recovery OS.”
Worth knowing where the documentation lives, because it is not where you would look. man csrutil is fourteen lines long, dated 2017, and its substantive advice is to run the command without arguments. It mentions Apple silicon, Startup Security Utility, snapshots, and authenticated-root exactly zero times each. The thirty-line usage statement is the real reference.
Turning it off from Recovery
Getting into Recovery differs by architecture, and this is where a lot of older guides send Apple silicon owners down an Intel path that does nothing:
- Apple silicon — shut down fully, then press and hold the power button until “Loading startup options” appears. Choose Options, then Continue.
- Intel — restart and hold Command-R until the Apple logo appears.
On Apple silicon there is an extra step that has nothing to do with csrutil and is the usual reason the command appears to fail in Recovery. Security policy is per-installation and lives in Startup Security Utility, reachable from the Utilities menu once Recovery has loaded. It has to be set to Reduced Security for that system before protection can be lowered; a machine left on Full Security will not accept the change. Intel Macs with a T2 chip have their own variant of this in the same utility.
From the Terminal inside Recovery, under Utilities:
csrutil disable
rebootAfter the restart, csrutil status from your normal login is what confirms it — not the message you saw in Recovery.
The second switch nobody mentions
Here is the part that trips people up, and it is visible in the usage output quoted above. csrutil disable lowers System Integrity Protection. It does not unseal the system volume. Those are two independent settings, and modifying files under /System needs both:
authenticated-root
status
Show the current authenticated root setting.
disable
Allow booting from non-sealed system snapshots. Only available in Recovery OS.
enable
Only allow booting from sealed system snapshots. Only available in Recovery OS.“Allow booting from non-sealed system snapshots” is the sealed system volume being switched off. With protection disabled but Authenticated Root still enabled, / stays mounted read-only and sealed, and writes there keep failing exactly as before — which is why people report that disabling SIP “did not work”. It worked; they changed the wrong switch for the job they had.
This also sets the real cost of the operation. A Mac booting from a non-sealed snapshot has given up the integrity check that runs at every startup, and updates on such a system are a good deal less predictable — the usual way back to a clean state is a reinstall. If your goal is anything short of shipping a kernel extension, it is worth checking whether the thing you want to change lives on the data volume, where none of this applies.
What stops working
Protection covers several distinct categories, which is why partially-disabled machines print a list rather than one line. Switching it off gives up filesystem protection for system locations, restrictions on loading unsigned kernel extensions, the block on attaching debuggers to Apple processes, and the guard on nvram variables that boot arguments live in.
Practical consequences worth expecting: some apps and services check the state at launch and will warn or refuse to run, corporate device management may flag the machine as non-compliant, and a macOS update can quietly restore protection — which is a feature, not a bug, and a good reason to re-check csrutil status after every update rather than assuming your change survived.
Turning it back on
Same route, opposite command. Boot to Recovery, open Terminal, and run whichever you turned off, in reverse order if you changed both:
csrutil authenticated-root enable
csrutil enable
rebootThere is also csrutil clear, described in the usage text as “Clear the existing configuration” — it discards a customised configuration and returns to the default rather than toggling one flag, which is the cleaner option if you have been experimenting and are no longer sure what state the machine is in. On Apple silicon, remember to put the security policy back to Full Security in Startup Security Utility; leaving it on Reduced Security keeps the machine weaker than default even after protection is re-enabled.
Then confirm from a normal boot. System Integrity Protection status: enabled. on one line, and Authenticated Root status: enabled, is what a machine back at defaults looks like.
Quick reference
| Command | Where it runs | What it does |
|---|---|---|
csrutil status | Anywhere | Reports protection state |
csrutil authenticated-root status | Anywhere | Reports whether the system volume is sealed |
csrutil disable | Recovery only | Lowers System Integrity Protection |
csrutil authenticated-root disable | Recovery only | Allows booting an unsealed system volume |
csrutil enable | Recovery only | Restores protection |
csrutil clear | Recovery only | Discards a custom configuration |
The one thing to take away: check csrutil status before you start and after every macOS update, and be clear about which of the two switches your task actually needs. Most tasks that send people to this page need neither.