Firmware, software that’s intimately involved with hardware at a low level, has changed radically with each of the different processor architectures used in Macs.

Classic Macs based on Motorola 68K processors come with their own Macintosh ROM. That changed after the first PowerPC models of 1994, and the Power Macintosh 9500 from 1995 supports Apple’s version of Open Firmware. That had originated as OpenBoot in Sun Microsystems’ SPARC-based computers, and is based on the language Forth. Macs with Open Firmware can be booted into an interactive interface that makes it relatively straightforward to support and bring up new hardware. It’s also a security nightmare.

Firmware version numbering was elaborate, with a ROM revision, here $77D.45F6, a Boot ROM version of $0004.25f1, and a Mac OS ROM file version of 8.4, for this Power Mac G4 running Mac OS 9.2.1 in 2002. Apple supplied separate Mac OS ROM file updates as needed.

EFI

In 1998, Intel started work on the original Extensible Firmware Interface (EFI) as its intended replacement for the BIOS in PCs. By the time Apple was beginning its transition from PowerPCs in 2006, EFI was changing into Unified EFI (UEFI), and has since progressed as far as version 2.10 in 2022.

Once an Intel Mac has cleared its initial self-test routines (POST), and key custom chips like the SMC are running, EFI firmware is loaded next. The purpose of the EFI phase and the boot loader boot.efi is to augment the basic facilities provided by BootROM to the point where the macOS kernel can be loaded with its extensions. Key to this is providing access to the Mac’s hardware through the device tree, IODeviceTree, listing and relating all the devices in that Mac. This is built by boot.efi and passed to the kernel when it loads, and forms the basis for IOKit within macOS.

Model-specific boot.efi software also provides ongoing and additional support for boot services, including memory management, basic functions for timers and events, and for hardware access. It supports basic console protocols for input and output, and access to storage systems. Runtime services extend these to give access to variables stored in the NVRAM, and to GUIDs/UUIDs used for key variables in the EFI phase and later. Most importantly, boot.efi looks for startup key commands, originally named snag keys by Apple, such as Command-R to run in Recovery mode, Command-S and -V for Single User and Verbose modes, and Shift for Safe mode.

When Apple introduced Boot Camp in 2006, it made changes to boot.efi to support booting from operating systems other than macOS. This essentially provides a suite of drivers supporting Mac hardware in terms of a Windows hardware platform, engaged when the Mac is to be booted in that operating system rather than macOS.

Firmware security

In March 2015, two security researchers from LegbaCore, Xeno Kovah and Corey Kallenberg, demonstrated proof-of-concept attacks on the BIOS of several computers including Dell, HP, and other PCs that could have been used to implant malicious code. Later that year, Kovah and Trammell Hudson turned their attention to Macs, demonstrating a firmware worm named Thunderstrike 2.

For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X. That year, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates. Although older separate firmware updates are still available, those were the last.

Then in 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware. Their concern was less about potential bugs and other problems, and more about the security risk posed. Apple had already been busy, hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August. They developed a new tool eficheck, released in High Sierra on 25 September 2017. Each week until it was dropped from Sonoma, eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Back in late 2017, this iMac17,1 was reported as running Boot ROM version IM171.0105.B26.

T2 firmware

In 2016, the year before Smith and Bruienne’s report, Apple introduced first the T1 chip, then hot on its heels the T2 the following year. With two separate CPUs in each T2 Mac, there are two separate sets of firmware, one EFI and the other known as iBridge or BridgeOS. Following the established pattern, both are only updated by macOS installers and updaters.

After standard power-on self-test and SMC initialisation, the T2 sub-system establishes the level of Secure Boot in force, and, if that’s Full or Medium Security, boot.efi is checked before being loaded, providing security throughout the boot process.

Apple silicon Macs

The introduction of Macs using the M1 family of chips in 2020 brought complete change in firmware to support Secure Boot, and moves away from UEFI completely. The aim of boot security in Apple silicon Macs is to provide a verified chain of trust through each step in the boot process to the loading of macOS, that can’t be exploited by malicious components. This consists of four main stages:

• The Boot ROM in the hardware.
• The Low-Level Bootloader, LLB, or first stage.
• iBoot, or second stage.
• The macOS kernel, which loads all its required kernel extensions.

One of many changes made from UEFI is that startup key combinations have been replaced by the Power button to engage Recovery and other special startup modes, which has both improved security of Recovery mode and made its features more accessible. Instead of the user having to memorise a list of different key combinations required to access different features, all are now integrated within a single environment.

Apple silicon Macs are the first Macs whose firmware can be both upgraded and downgraded by restoring them from IPSW image files when the Mac has been put into DFU mode. For the time being, at least, all Apple silicon Macs run a unified firmware version tied not to the chip or model, but to the macOS version, and only delivered in IPSW files and macOS updates.

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

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)