Can SIP be disabled from a normal macOS session or through MDM?

No. SIP settings can only be changed from recoveryOS with csrutil, which requires physical presence and, on Apple silicon, administrator authentication. MDM can report on SIP status but cannot turn it off.

Is it ever acceptable to disable SIP on a production Mac?

Treat it as not acceptable. Disabling SIP removes protections that malware, TCC and security tooling rely on. If a vendor requires it, push back and look for a system extension or supported alternative.

Do I still need kernel extensions on Apple silicon?

Rarely. Most use cases, including endpoint security agents, network filters and many drivers, are now served by system extensions and DriverKit, which run outside the kernel and do not require lowering the boot policy.

System Integrity Protection and the Signed System Volume

System Integrity Protection (SIP) and the Signed System Volume (SSV) are the reason a compromised admin account on a modern Mac is not automatically a compromised operating system. Together with the secure boot chain on Apple silicon, they make the OS itself read-only and verifiable, and they force most third-party low-level code out of the kernel. This guide covers what each layer protects, how to verify it on macOS 15 Sequoia and macOS 26 Tahoe, and why the right production setting is always "on".

What SIP protects

SIP is a kernel-enforced policy that restricts what even the root user can do. It was introduced in OS X El Capitan and has expanded since. Broadly, it covers three things:

File system protection. Root cannot modify protected locations such as /System, /usr (with the exception of /usr/local), /bin and /sbin, or the apps Apple preinstalls in /Applications. Only Apple-signed processes with specific entitlements, such as the installer used for OS updates, can write there.
Runtime protection. Processes that are protected by SIP cannot have code injected into them or be attached to by debuggers, even by root. This also protects security-critical daemons and databases, including the system TCC database described in the TCC and privacy permissions guide.
Kernel and boot protections. SIP restricts loading unsigned kernel extensions and limits changes to certain NVRAM variables and boot arguments.

The point is to separate "administrator of this Mac" from "able to modify the operating system". Malware that tricks a user into entering an admin password still cannot persist inside the OS or tamper with protected processes.

Changing SIP

SIP configuration can only be changed from recoveryOS using csrutil. On Apple silicon you start into recoveryOS by holding the power button until startup options appear, then choosing Options. The setting is stored as part of the boot policy for that specific macOS installation, and changing it requires administrator authentication.

This design is intentional: there is no command in a running macOS session, and no MDM payload, that turns SIP off. If you see a vendor guide that asks you to disable SIP to install a product, treat it as a red flag rather than a deployment step.

Signed System Volume

Starting with macOS Big Sur, the system is installed on a separate, read-only APFS volume that is cryptographically sealed. Every file on it is covered by a hash tree whose root hash is signed by Apple. The Mac does not boot the live system volume directly; it boots an APFS snapshot of it, and the seal is verified as data is read.

If a single byte on the system volume is modified, the seal no longer matches and the Mac refuses to boot that snapshot (or, depending on configuration, falls back and requires reinstalling macOS). This makes offline tampering, which SIP alone does not prevent, detectable at boot.

SSV verification is tied to a separate setting, authenticated root, which can also only be changed from recoveryOS and which should remain enabled.

Layer	Protects against	Enforced by	Changeable from
SIP	Runtime modification of OS files and protected processes, even by root	Kernel policy	recoveryOS only
Signed System Volume	Offline or online tampering with the system volume	Cryptographic seal verified at boot and on read	recoveryOS only (authenticated root)
Secure boot chain	Booting unsigned or unauthorized OS components	Boot ROM, LLB/iBoot, Secure Enclave-signed LocalPolicy	Startup Security Utility in recoveryOS

The secure boot chain on Apple silicon

On Apple silicon, the chain of trust starts in the immutable Boot ROM, which verifies the next-stage bootloader, which in turn verifies iBoot, which verifies the kernel and its kernel collection. Each stage only runs code signed by Apple.

What makes Apple silicon different from traditional PCs is the LocalPolicy: a per-OS boot policy signed by the Secure Enclave that records the security mode (Full, Reduced or Permissive), whether third-party kernel extensions are allowed, and SIP configuration. Because it is signed by the Secure Enclave and changes require authentication in recoveryOS, malware running in macOS cannot quietly downgrade it.

Security modes and their relationship to FileVault and Activation Lock are covered in the FileVault guide. The short version for this guide:

Full Security is the default and the right production setting.
Reduced Security is required to load third-party kernel extensions.
Permissive Security results from disabling SIP and should only appear on dedicated development or research machines.

Kernel extensions vs system extensions and DriverKit

Historically, security agents, VPN clients, file system filters and hardware drivers ran as kernel extensions (kexts). A bug in a kext can panic the Mac, and a malicious kext has full control. Apple has been moving this code out of the kernel:

Mechanism	Runs in	Typical use	Approval
Kernel extension (kext)	Kernel	Legacy drivers and agents	Reduced Security on Apple silicon, user or MDM approval, restart
System extension: Endpoint Security	User space	EDR, antivirus, binary authorization	User or MDM approval, plus Full Disk Access
System extension: Network Extension	User space	Content filters, VPN, DNS proxies	User or MDM approval
DriverKit extension	User space	USB, HID, PCI and other drivers	User or MDM approval

For a hardened fleet the goal is simple: no third-party kexts. Ask vendors for system extension or DriverKit versions of their products. Most mainstream security and networking tools have made the transition.

Where a kext is unavoidable, it can be approved via MDM with the com.apple.syspolicy.kernel-extension-policy payload (keyed on team identifiers or bundle IDs), and the Mac must still be set to Reduced Security with user-managed or remote-managed kernel extensions allowed. System extensions are pre-approved with the com.apple.system-extension-policy payload, which accepts allowed team identifiers, specific extensions and extension types. Be as specific as possible; allowing a whole team identifier approves every extension that developer ships.

<dict>
    <key>PayloadType</key>
    <string>com.apple.system-extension-policy</string>
    <key>AllowedSystemExtensions</key>
    <dict>
        <key>TEAMID1234</key>
        <array>
            <string>com.example.security.extension</string>
        </array>
    </dict>
</dict>

Replace the placeholder team identifier and bundle ID with the values published by your vendor. Endpoint Security clients additionally need Full Disk Access, granted through a PPPC profile; see unified logging and Endpoint Security.

Verify it

Check SIP:

csrutil status

System Integrity Protection status: enabled.

Check authenticated root (SSV enforcement):

csrutil authenticated-root status

Authenticated Root status: enabled

Confirm the root file system is a sealed, read-only snapshot:

mount | grep " on / "

On a healthy system the options for / include sealed and read-only. diskutil apfs list also reports the sealed status of the system volume and its booted snapshot.

On Apple silicon, display the boot policy for the current OS, including the security mode and whether kernel extensions are permitted:

sudo bputil -d

List loaded kernel extensions and installed system extensions:

kmutil showloaded
systemextensionsctl list

kmutil replaces the deprecated kextstat and kextload tools. When reviewing kmutil showloaded output, filter out Apple's own com.apple.* entries and investigate anything left. In systemextensionsctl list, confirm every entry is [activated enabled] and belongs to a vendor you expect.

For fleet-wide assurance, collect these values through your MDM's inventory or a compliance script, and alert on any Mac reporting SIP disabled, authenticated root disabled, or anything other than Full Security. The mSCP and CIS benchmarks guide shows how these checks fit into a compliance baseline.

Common pitfalls

Disabling SIP "temporarily" for troubleshooting and never re-enabling it. Always re-check csrutil status after any recoveryOS session.
Installing third-party kexts on Apple silicon, which forces Reduced Security for that OS and widens the attack surface.
Over-broad system extension approvals that allow an entire team identifier instead of specific extensions.
Assuming SIP protects everything. User data, /Applications for third-party apps, /Library and /usr/local are not SIP-protected. Persistence via LaunchAgents and LaunchDaemons is still possible and needs monitoring.
Using custom boot arguments on production Macs. Anything beyond defaults should be justified and documented.

Checklist

SIP enabled on every Mac, verified by inventory
Authenticated root enabled; root file system mounted sealed and read-only
Full Security boot policy on Apple silicon
Zero third-party kexts; vendors on system extensions or DriverKit
System extensions approved by specific bundle ID via MDM
Alerting on any drift in SIP, authenticated root or boot policy

With the OS itself locked down, the next layer is controlling which applications are allowed to run: continue with Gatekeeper, XProtect and notarization.