The macOS Boot Process: From Firmware to the Login Window

The transition to Apple Silicon changed macOS’s boot process more fundamentally than any macOS release before it — not just a new CPU architecture, but a boot chain modeled directly on iOS’s, with a dedicated Secure Enclave verifying every stage before handing off to the next. Understanding both the old Intel path and the current Apple Silicon path explains a lot about why the two platforms behave differently around security, recovery, and startup customization.

Intel Macs: EFI and boot.efi

Intel-based Macs follow a path much closer to a standard UEFI PC: Apple’s EFI firmware initializes hardware, then loads boot.efi from the EFI System Partition, which in turn loads the kernel (kernelcache on modern versions) and hands off control.

# From a running Intel Mac
nvram -p | grep boot-args

boot-args, stored in NVRAM, is the closest Intel-Mac equivalent to a kernel command line — used historically for things like verbose boot (-v) or disabling specific kernel protections during development and debugging.

Apple Silicon: a chain rooted in hardware

Apple Silicon Macs boot through a chain modeled on the iPhone’s: the Boot ROM, burned into the chip at manufacture time and immutable, is the very first code that runs, and it verifies the cryptographic signature of the next stage (LLB, the Low-Level Bootloader) before executing it. LLB in turn verifies and loads iBoot, which verifies and loads the kernel — each link in the chain checking the signature of the next before handing off, all the way from silicon-burned trust anchor to a running kernel.

# From a running Apple Silicon Mac
bputil -d          # display the current boot policy

This is a genuine secure boot chain, not just a checksum — each stage’s signature is verified against keys ultimately rooted in the Secure Enclave, and a tampered LLB, iBoot, or kernel image fails verification before it’s ever executed, rather than being caught after the fact.

Boot security policies

Apple Silicon Macs let you choose a security policy per installed macOS volume group, from Full Security (only Apple-notarized OS builds the Secure Enclave currently trusts may boot) down through Reduced Security (allows older signed OS versions and unsigned kernel extensions), configured from Recovery Mode’s Startup Security Utility:

# From Recovery Mode
bputil -m -u <user> -p            # switch to a less restrictive security policy, interactively

This is also why running a kernel extension (rather than a modern system extension) or booting an older macOS version on Apple Silicon requires deliberately stepping down from Full Security first — the secure boot chain won’t permit it under the default, strictest policy.

Recovery: a second, minimal OS

Both platforms boot into a separate Recovery OS for reinstallation, disk repair, and (on Apple Silicon) security policy changes — held either on a local Recovery volume or fetched over the internet (Internet Recovery) when the local copy itself needs repair.

# Reboot into Recovery on Apple Silicon: hold the power button at startup
# On Intel: hold Cmd+R during boot

Kernel and kernel extension loading

Once the kernel itself is running, it loads its built-in kernel extensions and, if permitted by SIP and the boot security policy, any signed third-party kernel extensions — increasingly superseded by system extensions, which run in userspace with a much smaller blast radius, reflecting Apple’s ongoing push to get third-party code entirely out of kernel space.

kextstat | grep -v com.apple
systemextensionsctl list

loginwindow: the handoff to a usable session

Once the kernel and core system daemons (launchd’s earliest jobs) are running, loginwindow starts and presents the login UI — itself just another launchd-managed process, though one with special responsibility for authenticating a user and starting their actual session.

Why the Apple Silicon model is stricter by design

The practical upshot of Apple Silicon’s chained verification is that tampering with any single stage — firmware, bootloader, or kernel — is detected before that stage ever runs, not after the fact by scanning a running system. That’s a meaningfully stronger guarantee than Intel Macs’ EFI-based boot offered, at the cost of deliberately making certain low-level customizations (custom kernel extensions, alternate OS installs) require an explicit, documented step down in security policy rather than being available by default — a trade-off consistent with the same philosophy behind SIP and notarization: security defaults that assume most users should never need to loosen them.