Earlier this week, I explained how the Signed System Volume (SSV), Data volume and cryptexes are integrated into the boot volume group, to support a secure boot process. This article outlines how modern Macs tackle the problem of booting securely.

The aim of a secure boot process is to ensure that all steps from the Boot ROM to the operating system are verified against any unauthorised change, and the code loaded and run is as intended. A simple operating system might achieve that by running only code contained in a boot ROM, but that’s woefully inadequate for any modern general-purpose operating system such as macOS, which also needs to be updated and upgraded during a Mac’s lifetime. Thus the great bulk of macOS has to be loaded and run from mutable storage, now SSDs. Those and a great deal else require specialised cores, with their own firmware, and features like the Secure Enclave. This is achieved in a cascade, where each step provides access to more of the Mac’s hardware, until many of Sequoia’s 670 kernel extensions are loaded and ready.

Intel Mac without T2 chip

Older models of Macs without a T2 chip follow a classic and insecure process when booting. Their Boot ROM loads UEFI firmware, and that in turn loads boot.efi, the macOS booter, without performing any verification. The macOS booter then loads the prelinked kernel from disk, again without verifying it. When the kernel opens the SSV, any checks on that can only be cursory, as Recovery for these Macs doesn’t offer controls in the form of a Startup Security Utility.

In High Sierra (2017), Apple introduced eficheck to periodically run checks on the version and integrity of UEFI firmware, although that doesn’t take place during the boot process, and was discontinued in macOS 14 Sonoma.

Intel Mac with T2 chip

These are the first Macs to support Secure Boot, thanks to their T2 chip, which is based on a variant of Apple’s A10 chip, dating back to 2016; the first model featuring a T2 chip was released at the end of 2017. As shown in the diagram at the end of this section, these Macs start their boot process with their Boot ROM verifying the iBoot ‘firmware’ for the T2 chip. That in turn verifies the kernel and its extensions for the T2, and that verifies the UEFI for the Intel side of the Mac.

Booting the Intel chipset proceeds similarly to older Intel Macs, but each step verifies the code to be run by the next, until its immutable kernel is loaded and boots the rest of macOS. Early in that stage, the kernel verifies the SSV before proceeding any further. Failure in any of the verifications halts the boot process, if you’re lucky in Recovery or T2 DFU mode.

This diagram compares boot processes in the three modern Mac architectures.

Apple silicon Mac

In the absence of any Intel chipset, Apple decided to implement its own Secure Boot, although there are options that could have allowed it to remain with UEFI. M-series chips tackle this in four steps:

1. Boot ROM, which verifies the Low Level Bootloader (LLB).
2. LLB, sometimes described as the first stage, concerned with loading and booting some auxiliary cores, security policy, and verifying the second stage, iBoot.
3. iBoot, which continues validations and verifications, including signatures and root hash of the SSV, before handing over to the kernel.
4. The kernel, which boots macOS.

Apple silicon chips contain many specialist cores responsible for implementing hardware features such as Thunderbolt. Firmware for each of those has to be verified and loaded to boot those cores, a task performed by LLB and iBoot.

Security policy for each boot volume group is set in its LocalPolicy, and has to be loaded and validated by LLB. The SSV is verified by iBoot prior to handing over to the kernel, to ensure the file system has been checked before it’s mounted.

When running in Full Security, the only kernel extensions to be loaded are those supplied in macOS, forming the standard Boot Kernel Collection. If the user has set that boot volume group to Reduced Security and opted for it to load third-party kernel extensions, those are contained in the Auxiliary Kernel Collection, and validated by iBoot. Once the kernel and extensions collection have been loaded, the latter is locked in memory with SCIP (System Coprocessor Integrity Protection) prior to iBoot handing over to the kernel to boot.

As with T2 Macs, any failure of verification during Secure Boot should leave that Mac either in Recovery mode, or in DFU mode ready to be connected to another Mac for its firmware to be refreshed, or restored from scratch.

External boot disks

T2 Secure Boot doesn’t support booting from an external disk, which is only allowed by reducing the security setting in Startup Security Utility. When designing its M-series Macs, Apple wanted them to benefit from Secure Boot when starting up from an external disk, and incorporated this into its design.

This is implemented by the Mac always starting the boot process internally, with the LLB and iBoot being run from internal storage. Bootable external disks must have an ‘owner’ to associate them with a LocalPolicy loaded by LLB. That enables iBoot to validate the Boot Kernel Collection, SSV and other components in the external boot volume group, then to hand over to its kernel to boot macOS from that disk, instead of the internal SSD.

It took a few versions of Big Sur before this worked reliably, but this should now be robust, provided that it’s set up correctly by the user. However, it’s often incorrectly claimed that Apple silicon Macs can only start up from external disks by reducing security.

Further reading

Apple’s Platform Security Guide:
Boot process for an Intel-based Mac
Boot process for a Mac with Apple silicon
Signed system volume security

This blog:
Booting an M1 Mac from hardware to kexts: 1 Hardware
Booting an M1 Mac from hardware to kexts: 2 LLB and iBoot
Booting an M1 Mac from hardware to kexts: 3 XNU, the kernel
Make a Ventura bootable external disk for an Apple silicon Mac
Booting macOS on Apple silicon: LocalPolicy
Ownership of Apple silicon Macs matters: how it can stop external bootable disks
Booting macOS on Apple silicon: Multiple boot disks

Encrypting all your data didn’t become a thing until well after the first release of Mac OS X. Even then, the system provided little support, and most of us who wanted to secure private data relied on third-party products like PGP (Pretty Good Privacy).

FileVault 1

Apple released the first version of FileVault, now normally referred to as FileVault 1 or Legacy FileVault, in Mac OS X 10.3 Panther in 2003. Initially, that only encrypted a user’s Home folder into a sparse disk image, then in 10.5 Leopard it started using sparse bundles instead. These caused problems with Time Machine backup when it too arrived in Leopard, and proved so easy to crack that in 2006 Jacob Appelbaum and Ralf-Philipp Weinmann released a tool, VileFault, to decrypt FileVault disk images.

FileVault 1 was controlled in the Security pane of System Preferences, shown here in 2004.

Each new user added in the Accounts pane could have their Home folder stored in an encrypted disk image. Encryption keys were based on the user’s password, with a master password set for all accounts on the same Mac.

FileVault 2

FileVault 2 was introduced in Mac OS X 10.7 Lion in 2011, and at last provided whole-volume encryption based on the user password. Encryption was performed using the XTS-AES mode of AES with a 256-bit key, by the CPU. At that time, more recent Intel processors had instructions to make this easier and quicker, but all data written to an encrypted volume had to be encrypted before it was written to disk, and all data read from it had to be decrypted before it could be used. This imposed significant overhead of around 3%, which was more noticeable on slower storage such as hard disks, and with slower Macs.

Apple didn’t implement this by modifying the HFS+ file system to add support for encryption, but by adding encryption support to CoreStorage, the logical volume manager. In theory this would have enabled it to encrypt other file systems, but I don’t think that was ever done.

Turning FileVault on and off was quite a pain, as the whole volume had to be encrypted or decrypted in the background, a process that could take many hours or even days. Most users tried to avoid doing this too often as a result so, while FileVault 2 was secure and effective, it wasn’t as widely used as it should have been.

These screenshots step through the process of enabling FileVault in 2017.

Control was in the FileVault tab in System Preferences.

iCloud Recovery was added as an alternative to the original recovery key.

Encryption began following a restart, and then proceeded in the background for however long it took. Shrewd users enabled FileVault when a minimum had been installed to the startup volume, to minimise time taken for encryption.

With a minimal install, it was possible to complete initial encryption in less than an hour. With full systems, it could take days if you were unlucky.

Although FileVault has had a few security glitches, it has done its job well. Perhaps its greatest threat came in the early days of macOS Sierra, when Ulf Frisk developed a simple method for retrieving the FileVault password for any Mac with a Thunderbolt port. An attacker could connect a special Thunderbolt device to a sleeping or locked Mac, force a restart, then read the password off within 30 seconds. This exploited a vulnerability in the handling of DMA, and was addressed by enabling VT-d in EFI, in Sierra 10.12.2 and 10.12.4.

Hardware encryption

The next big leap forward came at the end of 2017, with the release of the first Macs with T2 chips, as intermediates on the road to Apple silicon. One of Apple’s goals in T2 and Apple Silicon chips was to make encrypted volumes the default. To achieve that, T2 and M-series chips incorporate secure enclaves and perform encryption and decryption in hardware, rather than using CPU cycles.

The Secure Enclave incorporate the storage controller for the internal SSD, so all data transferred between CPU and SSD passes through an encryption stage in the enclave. When FileVault is disabled, data on protected volumes is still encrypted using a volume encryption key (VEK), in turn protected by a hardware key and a xART key used to protect from replay attacks.

When FileVault is enabled, the same VEK is used, but it’s protected by a key encryption key (KEK), and the user password is required to unwrap that KEK, so protecting the VEK used to perform encryption/decryption. This means that the user can change their password without the volume having to be re-encrypted, and allows the use of special recovery keys in case the user password is lost or forgotten. Keys are only handled in the secure enclave.

Securely erasing an encrypted volume, also performed when ‘erasing all content and settings’, results in the secure enclave deleting its VEK and the xART key, rendering the residual volume data inaccessible even to the secure enclave itself. This ensures that there’s no need to delete or overwrite any residual data from an encrypted volume: once the volume’s encryption key has been deleted, its previous contents are immediately unrecoverable.

Coverage of boot volumes by encryption varies according to the version of macOS. Prior to macOS Catalina, where macOS has a single system volume, the whole of that is encrypted; in Catalina, both System and Data volumes are encrypted; in Big Sur and later, the Signed System Volume (SSV) isn’t encrypted, nor are Recovery volumes, but the Data volume is.

External disks

Hardware encryption and FileVault’s ingenious tricks aren’t available for external disks, but APFS was designed to incorporate software encryption from the outset. As with internal SSDs, the key used to encrypt the volume contents isn’t exposed, but accessed via a series of wrappers, enabling the use of recovery keys if the user password is lost or forgotten. This involves a KEK and VEK in a similar manner to FileVault on internal SSDs. As the file system on the volume is also encrypted, after the KEK and VEK have been unwrapped, the next task in accessing an encrypted volume is to decrypt the file system B-tree using the VEK.

Enabling FileVault has been streamlined in recent years, as shown here in System Settings last year, for an external SSD, thus not using hardware encryption.

FileVault control has moved to Privacy & Security in System Settings.

The choice of iCloud Recovery or a recovery key remains.

Because only the Data volume is now encrypted, enabling FileVault before populating the Home folder allows encryption to be almost instantaneous, on an external disk.

Virtual machines

The most recent enhancement to FileVault protection extends support to Sequoia virtual machines running on Sequoia hosts. Apple hasn’t yet explained how that one works, although I suspect the word exclave is likely to appear in the answer.

If your Mac has a T2 or Apple silicon chip and you haven’t enabled FileVault, then you’re missing one of the Mac’s best features.

macOS Sequoia 15.0 and the security updates to Sonoma 14.7 and Ventura 13.7 brought firmware updates to most supported models. Over the weekend I have updated the databases used by SilentKnight, and the relevant articles listing them here, including new information for Macs running Sequoia, published a few minutes ago.

Which Macs get firmware updates?

For many years now, firmware updates have only been supplied in macOS updates and upgrades, and haven’t been offered as separate installations. It therefore follows that the only Macs that can receive firmware updates are those still supported by one of the three supported versions of macOS.

If the most recent version of macOS your Mac can install (without using OCLP) is Monterey, that automatically means that it can’t get any further firmware updates, as the final version of Monterey was 12.7.6, released on 29 July 2024. In practice, though, Apple normally stops revising EFI firmware well before that event, and this year has followed that pattern again.

Macs no longer supported

With the start of the Sequoia cycle, Apple appears to have ceased revising EFI firmware for the following models, all of which were originally released in June 2017:

• iMacs introduced in June 2017 – iMac18,1, iMac18,2, iMac18,3
• MacBook from June 2017 – MacBook10,1
• MacBook Pros from June 2017 with a T1 chip – MacBookPro14,1, MacBookPro14,2, MacBookPro14,3

The last firmware update for those is dated 23 June 2024, and supplied in the Ventura 13.7 security update.

These have occurred slightly earlier than would have been expected, just 7 years after that model’s first release. It was previously more usual to see support extend for 8 or more years after release.

Intel (EFI) model still supported

The only Intel Macs without a T2 chip that are still supported with EFI firmware updates are iMac 2019 models, designated iMac19,1. Not only do they continue to receive firmware updates, but they’re still supported by macOS Sequoia. In theory, that could enable them to continue to receive firmware updates until the summer of 2027, when maintenance of Sequoia is expected to cease. However, I suspect that it’s more likely that firmware support for them will be discontinued in June 2026, 7 years after their release. They’re already the last Intel Mac without a T2 chip to be supported by Sequoia.

Intel Macs with T2 chips

All other Intel Macs still supported by Sequoia have T2 chips, which have a common firmware installer. However, their release dates range from December 2017 (iMac Pro) to August 2020 (iMac Retina 5K 27-inch). Apple has already stopped current macOS support for two T2-equipped MacBook Air models (2018 and 2019), so it’s possible the list of Intel Macs supported by macOS 16 next year will be shorter than that for macOS 15 this year.

In 2026, when support for Sonoma stops, this should mean that, for the first time, some Macs with T2 chips will only be able to run older versions of their firmware, while others will continue to receive updates.

OpenCore Legacy Patcher

Macs that can have OCLP installed so they can run unsupported versions of macOS don’t receive any further firmware updates. They’re stuck with the last version released in their last supported macOS update.

This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 15.0 Sequoia.

Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. That displayed for Intel models uses five decimal numbers separated by dots, e.g 96.0.0.0.0, and is given below. Models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs are different again, and give an iBoot version instead, as they don’t use EFI at all.

Macs still running older versions of macOS are covered by information at:

• this page for Sonoma,
• this page for Ventura,
• this page for Monterey,
• this page for Big Sur,
• this page Catalina,
• this page for High Sierra,
• this page for El Capitan and earlier.

Apple Silicon Macs

The current iBoot version is 11881.1.1.

Intel Macs with T2 chips

The current EFI version is 2069.0.0.0.0 and iBridge is 22.16.10353.0.0,0.

Intel Mac without T2 chip

iMac: iMac19,1 2069.0.0.0.0

Apple Studio Display

The current version remains 17.0 (build 21A329).

T2 chip models:
The iMac Pro, 2019 Mac Pro, iMac 27-inch 2020, 2018 MacBook Pro with Touch Bar (MacBookPro15,1 and 15,2), 2018 Mac mini and 2018 MacBook Air, and their successor models, use a different mechanism for firmware updates, managed by their T2 chips.

How to check your Mac’s firmware version

The simplest way now is to run either of my free tools SilentKnight or LockRattler, available from their product page.

Alternatively, use the About This Mac command at the top of the Apple menu; hold the Option key and click on the System Information command. In the Hardware Overview listing, this is given as the Boot ROM Version or System Firmware Version.

What to do if your Mac’s firmware is different from that shown

If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.

If the installed version of firmware has a version which is lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.

Firmware updaters are now only distributed as part of macOS updates and upgrades: Apple doesn’t provide them separately.

Older versions of macOS provided the command tool eficheck at /usr/libexec/firmwarecheckers/eficheck/eficheck to check firmware version and integrity. That was removed from Sonoma. All T2 and Apple silicon models automatically check the integrity of their firmware in the early part of the boot process anyway. If any errors are found then, the Mac should be put into DFU mode and firmware restored from the current IPSW image file. In Sonoma and later this can be performed in the Finder, and no longer requires Apple Configurator 2. Full instructions are now provided in this article. If you don’t have a second Mac or don’t feel that you can perform this yourself, it should be easy to arrange with an Apple store or authorised service provider.

(Last updated 23 September 2024)