Secure Boot and Apple Silicon Security

Overview

The Mac boot chain is the sequence of firmware and software components that execute from the moment you press the power button to when macOS loads. Each stage cryptographically verifies the next, creating a chain of trust that prevents unauthorized code from running during startup. With Apple Silicon, this security architecture has been fundamentally redesigned around the Secure Enclave, making it the most secure boot process available on any personal computer. For Mac admins, understanding the boot chain is essential for managing Secure Boot policies, troubleshooting boot failures, and understanding the security guarantees your fleet provides.

The Boot Chain

Apple Silicon Boot Sequence

1. Boot ROM – Immutable code burned into the silicon at manufacture. This is the hardware root of trust. It verifies the next stage before executing it.
2. Low-Level Bootloader (LLB) – Loaded from the Secure Enclave’s storage. Verified by Boot ROM. Initializes the Secure Enclave and prepares to load iBoot.
3. iBoot – Apple’s second-stage bootloader. Verifies and loads the macOS kernel. iBoot also evaluates the LocalPolicy to determine what security level is in effect.
4. macOS Kernel – The XNU kernel loads, initializes the operating system, and hands off to launchd.

Each stage is signed by Apple and cryptographically verified by the preceding stage. If any verification fails, the boot process halts.

Intel T2 Boot Sequence

On Intel Macs with the T2 security chip, the boot process is similar in principle but architecturally different:

1. T2 Boot ROM – The T2 chip has its own boot ROM that initializes first
2. T2 bridgeOS – The T2 chip runs its own operating system (bridgeOS) that manages Secure Boot
3. UEFI Firmware – The Intel UEFI firmware loads, with the T2 chip verifying the boot process
4. boot.efi – The macOS bootloader, verified by the T2 chip
5. macOS Kernel – Loads after verification

Note: Intel Macs without a T2 chip have no Secure Boot capability. The boot chain is unverified, and firmware-level attacks are possible.

Secure Boot Modes

Apple Silicon: Three Security Levels

Apple Silicon Macs support three Secure Boot security levels, configured per operating system installation:

# Check the current security policy (Apple Silicon)
bputil -d

Intel T2: Two Security Levels

T2 Secure Boot settings are configured through the Startup Security Utility in macOS Recovery.

LocalPolicy and the Secure Enclave

On Apple Silicon, each operating system installation has a LocalPolicy – a signed configuration document stored in the Secure Enclave that defines the security policy for that installation. The LocalPolicy contains:

• The Secure Boot security level
• Whether kernel extensions are allowed
• Whether the system can boot in a degraded security state
• MDM-managed policy overrides

The LocalPolicy is signed by a key derived from the device’s unique Secure Enclave identity. This means a LocalPolicy from one Mac cannot be transferred to another – it is cryptographically bound to the specific hardware.

Why LocalPolicy Matters for Admins

When you change Secure Boot settings, approve kernel extensions, or allow Reduced Security, you are modifying the LocalPolicy. These changes require:

1. Authentication by a local admin (volume owner)
2. Signing by the Secure Enclave
3. In some cases, contact with Apple’s signing server

This is why Secure Boot changes cannot be scripted remotely and typically require physical access or specific MDM capabilities.

The bputil Utility

bputil (Boot Policy Utility) is the command-line tool for inspecting and modifying boot policy on Apple Silicon Macs:

# Display current boot policy details
bputil -d

# Display boot policy for all installed OSes
bputil -l

Warning: bputil can modify boot security settings and should be used with extreme caution. Incorrect use can render a Mac unbootable. In most cases, use the Startup Security Utility GUI in Recovery instead.

Startup Security Utility

The Startup Security Utility provides a graphical interface for managing boot security. Access it by:

Apple Silicon:

1. Shut down the Mac
2. Press and hold the power button until “Loading startup options” appears
3. Click Options to enter Recovery
4. From the menu bar, select Utilities > Startup Security Utility

Intel T2:

1. Restart and hold Command+R to enter Recovery
2. From the menu bar, select Utilities > Startup Security Utility

The utility allows you to:

• Set the Secure Boot security level
• Configure allowed boot media (internal disk only, or allow external/network boot)
• On Apple Silicon, manage per-OS security policies

DFU Restore and Revive

When an Apple Silicon or T2 Mac has a firmware issue that prevents it from booting, two recovery options exist:

Revive

Reinstalls the firmware and recoveryOS without erasing user data. This is the first step to try when a Mac is unresponsive.

Restore

Completely erases the Mac and reinstalls firmware, recoveryOS, and macOS. This is the nuclear option when a revive fails.

Both operations require:

• A second Mac running Apple Configurator 2
• A USB-C cable connecting the two Macs
• The target Mac to be in DFU (Device Firmware Update) mode

# On Apple Silicon, enter DFU mode:
# 1. Shut down the Mac
# 2. Press and hold power button
# 3. While holding power, press and release specific key combinations
#    (varies by Mac model -- consult Apple documentation)

Tip: DFU restore and revive are essential tools for Mac admins managing large fleets. Familiarize yourself with the process before you need it in a crisis. Keep Apple Configurator 2 installed on at least one admin Mac.

Kernel Extensions on Apple Silicon

Apple Silicon has fundamentally changed how kernel extensions (kexts) work:

1. Full Security – No third-party kernel extensions are allowed
2. Reduced Security – Kernel extensions from identified developers can load, but require:
   • User approval via System Settings
   • A restart to load into the auxiliary kernel collection
   • MDM can pre-approve kexts by Team ID

Apple has deprecated kexts in favor of System Extensions, which run in user space and do not require Reduced Security. Admins should actively migrate any remaining kext-dependent tools to System Extension alternatives.

# List loaded kernel extensions
kextstat | grep -v com.apple

# Check if any third-party kexts are present
kmutil showloaded --list-only | grep -v com.apple

Enterprise Implications

What Changes for Mac Admins on Apple Silicon

MDM Capabilities

MDM platforms can manage certain boot security aspects on supervised devices:

• Bootstrap token escrow – Required for MDM to manage FileVault and Secure Boot on Apple Silicon
• Kernel extension allow lists – Pre-approve kexts by Team ID
• Software update management – Control when macOS (and firmware) updates are applied
• Recovery lock – Set a firmware password equivalent that prevents unauthorized Recovery access

Checking Boot Security Status

Use these commands to audit boot security across your fleet:

# Apple Silicon: Full boot policy details
bputil -d

# Check Secure Boot status (works on both Intel T2 and Apple Silicon)
/usr/libexec/mdmclient QuerySecurityInfo 2>/dev/null

# Check if the system booted from a sealed system volume
csrutil authenticated-root status

# Verify SIP status (related to boot chain integrity)
csrutil status

For fleet-wide auditing, collect this data through your MDM’s inventory or custom scripts and flag any devices running in Reduced or Permissive Security mode that should not be.

Key Takeaways

The boot chain is the foundation of macOS security – if it is compromised, every layer above it is untrustworthy. Apple Silicon Macs provide the strongest boot security Apple has ever shipped, with hardware-rooted trust, per-OS LocalPolicy, and Secure Enclave enforcement. For Mac admins, the priorities are: keep fleets on Full Security, migrate away from kernel extensions, ensure bootstrap tokens are escrowed to MDM, and maintain familiarity with DFU restore procedures for when things go wrong.