Apple Silicon Security Policy: Full vs Reduced Security Explained
Apple Silicon Macs store security settings in a hardware-signed LocalPolicy file, not NVRAM. Understanding Full Security, Reduced Security, and the two bonus flags helps you make informed decisions about third-party kernel extensions and remote management.
Why this article matters
Most Mac users never need to open Startup Security Utility — until they do. The situations that force the question are surprisingly common in music production and pro audio work: you need to install Soundflower or BlackHole for virtual audio routing; an older plugin requires a legacy kernel extension (kext); your studio's IT team manages your machine through an MDM profile; you want to downgrade to an earlier macOS for plugin compatibility; or you're setting up Asahi Linux as a dual-boot.
When any of these situations arise, macOS either silently refuses or presents a wall of security dialogs that reference terms like Reduced Security, kernel extensions, and One True Recovery. Understanding what each option actually does — and what you permanently give up by enabling it — prevents costly mistakes and wasted hours of troubleshooting.
This article walks through the complete architecture of Apple Silicon's security policy system, from the hardware level up to the UI checkboxes in Startup Security Utility.
What LocalPolicy is
On Intel Macs, system security settings were stored in NVRAM — a region of writable memory that privileged software could overwrite. A piece of malware exploiting a kernel vulnerability could silently lower your security level without any physical interaction.
Apple Silicon changes this entirely, mirroring the architecture of iPhone and iPad. Your security settings are compiled into a binary structure called LocalPolicy, encoded in the Image4 format (ASN.1 DER). This file is then signed directly by the Secure Enclave Processor (SEP) — a dedicated hardware security chip isolated from the main CPU.
The practical result: LocalPolicy cannot be modified by any software running on the machine, regardless of privilege level. Changing it requires physical presence at the machine and a deliberate hardware gesture.
How to access Startup Security Utility
Startup Security Utility runs inside One True Recovery (1TR) — a special environment that loads before macOS and lets the SEP verify you are physically present. There is no way to reach it remotely or through a running OS.
- Shut down your Mac completely — do not just restart.
- Press and hold the power button until you see "Loading startup options…"
- Click Options, then click Continue to enter Recovery.
- From the menu bar, choose menu → Startup Security Utility (the symbol is the Apple logo in the top-left corner of the screen).
- Authenticate with your administrator password when prompted.
- Select the volume you want to configure, then adjust the security policy.
Full Security
Full Security is the default and strictest mode. When selected, the system only boots macOS versions that carry Apple's Personalized Signatures — cryptographic proofs generated by Apple's TSS authentication servers at the moment of installation, tied specifically to your hardware's unique identifier.
At the kernel level, the system completely blocks all third-party kernel extensions. Kernel memory is guaranteed to contain only Apple's original code, making this mode equivalent to iOS in terms of kernel integrity.
This is the mode that enables the full suite of sensitive hardware features:
- Apple Pay — fully operational, backed by Secure Enclave guarantees
- DRM decryption — maximum resolution for Netflix 4K, Apple TV+ HDR, Disney+ 4K, and other protected content
- System Integrity Protection (SIP) at its highest enforcement level
- Advanced biometric authentication with maximum cryptographic assurance
- Lowest possible risk of kernel panic or security bypass from third-party code
Reduced Security without checkboxes
When you select Reduced Security but leave both checkboxes unticked, the system moves to an intermediate state roughly equivalent to Medium Security on Intel T2-chip Macs.
The only change is the OS signature mechanism: instead of Personalized Signatures, the system accepts Global Signatures — any macOS version Apple ever validly signed, even if Apple's servers no longer issue personalized grants for your specific hardware. This lets you downgrade to older macOS versions for plugin compatibility, or set up a multi-boot environment with a properly signed custom OS (for example, providing the foundation for the Asahi Linux bootloader).
Critically, the kernel remains fully locked in this state. No third-party driver or software can enter ring-0 (the innermost kernel layer). The security model for running code is unchanged.
Bonus Flag 1: third-party kernel extensions (AuxKC)
The first checkbox — "Allow user management of kernel extensions from identified developers" — is only available after selecting Reduced Security. Ticking it enables a major privilege with a matching, hardware-enforced cost.
When enabled, macOS can activate the Auxiliary Kernel Collection (AuxKC) mechanism. When you install legacy software that ships a kext — Soundflower, BlackHole (older builds), aging virtualization drivers, classic Cisco VPN — the Kernel Management Daemon (kextd) takes the kext, verifies the developer certificate, folds it into the AuxKC, computes a SHA-384 hash of the approved kext list, and writes that hash directly into LocalPolicy. A restart is required to load the AuxKC alongside the main kernel.
Once AuxKC is loaded, the Secure Enclave detects a state flag called the kext receipt. Because the SEP cannot verify that the third-party kext is not silently capturing screenshots, reading memory, or stealing encryption keys, it immediately takes protective action.
- Apple Pay: hardware-disabled by SEP upon detecting the kext receipt
- DRM streaming: playback resolution capped — 4K and HDR may be unavailable
- Kernel panic risk: higher — stability depends on third-party code quality
- Typical use cases: legacy pro-audio drivers like Soundflower, older virtualization tools, classic enterprise VPN clients
Bonus Flag 2: MDM remote management
The second checkbox — "Allow remote management of kernel extensions and automatic software updates" — is designed for enterprise environments managed by an IT team.
Normally, approving a new kext in Reduced Security requires physically entering 1TR each time — impractical at any scale. With this flag enabled, the system delegates kext approval authority to the organization's MDM (Mobile Device Management) certificate. An IT administrator can remotely push kext approval commands to employee machines without requiring any physical key interaction on those machines.
This flag trades one layer of physical authentication for operational convenience across a managed fleet. It is the correct tool for corporate Mac deployments where the MDM server is the established trust anchor. It is not appropriate for personal machines.
Comparison: three security states
Each row below compares Full Security, Reduced Security with no checkboxes, and Reduced Security with the kext checkbox enabled.
- OS signature mechanism — Full Security: Personalized (real-time TSS) | Reduced (no boxes): Global Signatures | Reduced + Kext: Global Signatures
- macOS downgrade allowed — Full Security: Blocked if Apple stopped signing | Reduced (no boxes): Allowed | Reduced + Kext: Allowed
- Third-party kexts — Full Security: Absolutely forbidden | Reduced (no boxes): Absolutely forbidden | Reduced + Kext: Allowed via
AuxKC - Kernel loaded — Full Security: Base System Kernel only | Reduced (no boxes): Base System Kernel only | Reduced + Kext: Base System Kernel +
AuxKC - Apple Pay — Full Security: ✓ Fully working | Reduced (no boxes): ✓ Fully working | Reduced + Kext: ✗ Hardware-disabled
- DRM (4K/HDR) — Full Security: ✓ Maximum quality | Reduced (no boxes): ✓ Maximum quality | Reduced + Kext: ⚠ Resolution limited
- System crash risk — Full Security: Lowest (Apple code only) | Reduced (no boxes): Lowest (Apple code only) | Reduced + Kext: Higher (third-party code in kernel)
When to use each mode
Practical recommendations based on common music production and pro-audio scenarios:
- Most producers and musicians: stay on Full Security. Modern audio drivers use System Extensions, not kexts — you lose nothing.
- Need to run an older macOS for a legacy plugin or DAW: switch to Reduced Security (no checkboxes). Apple Pay and DRM remain fully intact.
- Need Soundflower or another legacy kext-based driver: switch to Reduced Security and tick the kext checkbox — but accept that Apple Pay will be hardware-disabled while the kext is loaded.
- Check first: BlackHole (the modern Soundflower replacement) ships as a System Extension and does not require enabling the kext checkbox. Prefer it over Soundflower when possible.
- IT-managed studio machines: the MDM checkbox is the right tool — your IT admin controls kext approvals centrally without touching each machine.
- Asahi Linux dual-boot: Reduced Security (no checkboxes) is sufficient to allow the Asahi bootloader. The kext checkbox is not required for the bootloader itself.
Frequently asked questions
I installed Soundflower or BlackHole and macOS is now asking me to approve a kernel extension. What do I do?
Go to System Settings → Privacy & Security, scroll to the Security section, and click Allow next to the kernel extension notice. macOS will prompt you to restart. Before this works, you must have already enabled Reduced Security and ticked the first kext checkbox in Startup Security Utility (hold the power button at shutdown to enter 1TR). Note that once the kext loads, Apple Pay will be hardware-disabled by the Secure Enclave — this is expected. If you need Apple Pay, consider switching to BlackHole instead, which is distributed as a System Extension and does not require any security policy change.
Why does Apple Pay get disabled after I install a kext?
The Secure Enclave (SEP) detects a "kext receipt" flag the moment a third-party kernel extension is loaded via AuxKC. Because the SEP cannot verify that the kext is not intercepting memory, capturing screens, or stealing encryption keys, it disables Apple Pay as a hardware-level protective measure. This behavior is enforced at the chip level and cannot be bypassed or reversed by any software setting — it lifts only when the kext is removed and AuxKC no longer loads at boot.
Is Reduced Security less safe than leaving everything at default?
Reduced Security without any checkboxes is still very safe. The only change is the OS version acceptance policy: the system moves from Personalized Signatures to Global Signatures, which allows older macOS versions to boot. The kernel remains completely locked against third-party code, and Apple Pay plus DRM are unaffected. The meaningful security reduction comes from the kext checkbox — not from Reduced Security itself. If you only need macOS downgrade capability, Reduced Security with no checkboxes is the right choice and involves minimal risk.