Firmware engineering must be among the least glamorous of the specialities, but it’s literally among the most fundamental. As regular users seldom need to come into contact with firmware and its versions, how those are numbered is kept as a dark secret. This article reveals what I have gathered.

Although you will come across different usage elsewhere, I here draw the distinction between:

• True ROM, including Macintosh ROM (Classic Macs) and Apple silicon Boot ROM, is set in the factory and normally can’t be changed;
• Firmware that can be updated in place includes Mac OS ROM (PowerPC), EFI Boot ROM or bootloader, and LLB/iBoot (Apple silicon);
• The operating system including any kernel, in Mac OS, Mac OS X, OS X and macOS, which are usually updated repeatedly.

PowerPC: Open Firmware

Classic Macs using Motorola 68K processors have their own Macintosh ROM with opaque hexadecimal versions. After the introduction of PowerPC models in 1994, that changed with the Power Macintosh 9500 of 1995 to support Apple’s version of Open Firmware.

Their ROM and firmware version numbering is elaborate, with a ROM revision, here shown as $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. Of those, Mac OS ROM file updates were provided as needed, and appear to have followed a plain major and minor numbering system.

Intel: EFI

When Apple transitioned from PowerPC to the Intel architecture in 2006, Open Firmware was replaced by the Extensible Firmware Interface (EFI), already on its way to become Unified as UEFI. Each Intel model thus has an EFI version number, from 1.0 upwards, and a firmware version number such as IM41.0055.B08, that of the early 2006 iMac.

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

This consists of the following elements:

1. A model type given as 2-3 letters, such as IM for iMac, MM for Mac mini, MBP for MacBook Pro, or XS for Xserve.
2. An individual model within that type given as 2-3 decimal digits, here 41 for the two iMac variants introduced in early 2006, while the mid-2006 iMac is 42, and the late-2006 iMac is 51 or 52. Those are commonly combined in a more accessible model identifier, such as iMac4,1 or iMac17,1.
3. A major version number given as four hexadecimal digits.
4. A minor version number given as three hexadecimal digits. With High Sierra, Apple ceased using the minor version number, leaving it set to either B00 or 00B.

Just for fun, many models also have a completely different SMC firmware version that was updated separately.

These were replaced in October 2018, in Macs that have been updated to macOS 10.14.1, High Sierra Security Update 2018-002, or Sierra 2018-005. Those updated EFI firmware to use a different version numbering system, with five decimal numbers separated by dots, such as 1037.140.50.0.0. Those differ between individual model types, making conversion from firmware version to model identifier impossible. The only way to determine whether any given firmware version is the most recent for a given model is thus to use a lookup table.

Intel: T2

Apple introduced the first MacBook Pro models with T1 chips in 2016-2017, but it wasn’t until the T2 models at the end of 2017 that there was any change in the format of firmware version numbers. Therefore MacBook Pro models with T1 chips continue to report just a plain EFI firmware version.

Intel Macs with T2 chips report two complete firmware versions, that for their Intel side as an EFI firmware version, and an iBridge or BridgeOS version for the firmware installed in the T2 chip. For example, 1037.147.1.0.0 (iBridge: 17.16.16065.0.0,0) gives 1037.147.1.0.0 as its new-style EFI firmware, and 17.16.16065.0.0,0 as that for the T2. However, in return for that added complexity, all Intel Macs with T2 chips give the same firmware versions when running the same version of macOS, so there’s no need for a model-based lookup table.

At this stage, Intel Macs can have one of three firmware versions:

• old-style EFI firmware, such as IM171.0105.B26, when they haven’t had a firmware update from October 2018 or later;
• new-style EFI firmware, such as 1037.140.50.0.0, when their firmware dates from October 2018 or later, and they don’t have a T2 chip;
• T2 models with EFI and iBridge firmware, such as 1037.147.1.0.0 (iBridge: 17.16.16065.0.0,0).

Apple silicon

Strictly speaking, Apple silicon Macs have two distinct firmware version numbers, one for the Low-Level Bootloader (LLB, stage one) and the other for iBoot (stage two), but I can’t recall ever seeing the two differ in any release version of macOS. Both bring the sanity of a standard numbering system consisting of three numbers [major].[minor].[patch], and so far all models have remained in synchrony with the same numbers for each release of macOS since Big Sur 11.

Version numbers are composed of:

1. A major version number of 4-5 decimal digits set by the current major macOS. These have been 67xx (macOS 11), 74xx (12), 84xx (13), 10151 (14), 11881 (15), and for macOS 26 it’s currently 13822.
2. A minor version number in decimal that increments for each minor version of macOS. Although this varies between major versions, a recent sequence might run: 1 (macOS x.0), 41 (x.1), 61 (x.2), 81 (x.3), 101 (x.4), 121 (x.5) and 141 (x.6, if it precedes the next major version of macOS).
3. A patch version number in decimal that usually varies from 1-10, and has even reached 96.

For example, 13822.81.10 is installed in macOS 26.3, 15.7.4 and 14.8.4, which were released simultaneously.

Most recently, version numbers reported by beta-test releases of 26.4 have been completely different, of the form mBoot-18000.100.10.0.1. It’s not yet known whether this is a bug, or the harbinger of yet another change in firmware version numbering.

What firmware engineers might lack in glamour they seem to compensate for by turning what should be simple and consistent into great complexity.

Further reading

A brief history of Mac firmware
Pre-2018 Intel firmware version numbering

Last week Apple released the second beta of macOS 26.4 to developers, and almost immediately I was receiving reports that SilentKnight crashed on launch in that new beta. Given how unusual that has been in previous versions, I was grateful to hear so quickly, and for so many of you to provide crash reports. As usual they don’t point to anything specific, but led me to wonder whether something might have broken in AppKit in that beta.

But there’s a strange observation reported by SilentKnight’s old predecessor LockRattler, which continues to work normally in 26.4 beta 2: that reports a bizarre iBoot firmware version number from Apple silicon Macs. Instead of a number like 13822.101.2 that I might have expected, LockRattler gives “mBoot-18000.100.10.0.1”, which is random nonsense. Yet it’s listed in a mammoth compilation of iBoot version numbers in the Apple Wiki as an occasional fault.

“mBoot-18000.100.10.0.1” is a problem for SilentKnight, as it tries to make comparisons between firmware version numbers to see whether that installed in your Mac is older or more recent that the version number it expects. If it didn’t do that, every beta-tester would be driven crazy by its persistent reports that their Mac’s firmware is out of date, when in fact it’s that for the next version.

Comparing numbers is of course simple, but I’ve been unable to find anywhere in the API that returns numbers for firmware versions. Wherever they’re available, they’re reported as strings of arbitrary characters, leaving SilentKnight the task of recovering three integers (in the case of iBoot) from what in this case turns out to be rubbish. This is further complicated by the fact that different architectures return strings with different structures: for plain Intel Macs, they should look like “2094.80.5.0.0”, those with T2 chips extend to “2094.80.5.0.0 (23.16.13120.0.0,0)”, and Apple silicon is simpler again with “13822.81.10”. What could have been a simple task is turned into lots of additional code.

It also raises the question of how any beta-release could be put in the hands of external testers when it can’t even report its firmware version correctly. Most of us draw clear distinctions between alpha and beta releases, and this strongly suggests that Apple doesn’t undertake any purposeful alpha testing before release as a beta. Either that or it’s well aware of significant bugs that it doesn’t inform beta-testers about. I fear the answer could be both, and I’m wondering whether trying to make sense of reported firmware versions is too fraught to be reliable.

My main use of SilentKnight here is to check for updates released for the security tools in macOS, primarily XProtect and XProtect Remediator. You may recall that Apple’s last update to XProtect Remediator on 17 February, bringing it to version 157, contained a strange change, which I reported as “the Bastion rules appear to correct a group of typos in the definition for bastion-common-system-binary”.

There were six typos in all, in a definition for bastion-common-system-binary introduced back in version 153 six months ago, on 5 August last year. I shouldn’t need to point out the errors in the original definition:
(define bastion-common-system-binary
(require-all
(process-attribute is-platform-binary)
(require-not
(require-any
(signing-identifier "com.apple.osascript")
(signing-identifier "com.apple.zsh")
(signing-identifier "com.apple.bash")
(signing-identifier "com.apple.sh")
(signing-identifier "com.apple.ksh")
(signing-identifier "com.apple.osacompile")
(signing-identifier "com.apple.python2")
(signing-identifier "python3")
(signing-identifier "ccom.apple.pbcopy")
(signing-identifier "ccom.apple.pbpaste")
(signing-identifier "ccom.apple.cat")
(signing-identifier "ccom.apple.curl")
(signing-identifier "ccom.apple.dd")
(signing-identifier "ccom.apple.cp")
(signing-identifier "com.apple.perl")))))
Instead of “ccom.apple.pbcopy”, it should of course have read “com.apple.pbcopy”, and the same for the other five signing-identifiers below that.

I’m delighted that Arnaud Abbati has explained eloquently the consequences of those typos in a wonderful article in his blog. I won’t steal his thunder here, but agree with his conclusion: “Six months of security updates, and nobody noticed. It missed engineering. It missed testing. It missed code review. It missed QA. It missed whatever metrics pipeline is supposed to validate that the rules actually match real binaries.”

There are times when I wonder what really does go on in Apple. When it releases a beta that can’t even tell what its firmware version is, and its security intelligence tool is broken for six months because of obvious typos, it does make you wonder.

Of all the important features of Macs, firmware must be among the dullest, although it’s also one of the Mac’s major benefits. Because Mac hardware, firmware, and its operating system are all made by Apple, the firmware in our Macs should always remain secure, robust and up to date.

That wasn’t always the case, though. Older Intel Macs could be difficult and sometimes impossible to update their firmware. Some particular configurations were notorious, and most became unreliable if you replaced their internal storage. After a long campaign with tools like eficheck, switching first to T2 then Apple silicon chips has proved decisive. With firmware updates distributed in and installed by macOS updates and upgrades, it’s almost unheard of now for a recent model to be running out of date firmware, unless it’s also running out of date macOS.

This has been important for system stability, where flaws in firmware can turn the most stable Mac into a series of kernel panics and crashes, and essential for security. All the user has to do to secure their Mac’s firmware is to keep macOS up to date. Vulnerabilities in PC firmware are relatively frequent and notoriously hard to address.

Now that support for Intel Macs is waning, and there are only a couple of iMac variants lacking T2 chips that are still fully supported, keeping track of firmware updates is far simpler. Last week’s release of macOS updates brought firmware updates all round, for the iMac19,1 and iMac19,2, as well as T2 and Apple silicon models.

The iMac19,1 and iMac19,2 (4K and 5K 2019) have firmware updates to take them from 2075.100.3.0.3 to 2094.80.5.0.0, the same EFI version found in T2 models. That’s the first update for them since last Spring (March).

Intel models with T2 chips have the same EFI version update to 2094.80.5.0.0, as well as their iBridge firmware, which changes from 23.16.12048.0.0,0 to 23.16.13120.0.0,0.

Currently all Apple silicon Macs from the first base M1 to those with the latest M4 and M5 chips, run common firmware, and that too has been updated from 13822.61.10 to 13822.81.10.

Version numbering of iBoot in Apple silicon Macs seems to have stabilised, with

• A major version number set by the current major macOS. For macOS 14 that was 10151, for macOS 15 it was 11881, and for macOS 26 it’s currently 13822.
• A minor version number that increments for each minor version of macOS. This runs in the sequence 1 (macOS x.0), 41 (x.1), 61 (x.2), 81 (x.3), 101 (x.4), 121 (x.5) and 141 (x.6).
• A patch version number that varies from 1-10, and has once reached 96.

The iBoot update released with security updates to the older two supported versions of macOS should be the same as that for the current version. Thus, the next iBoot update should bring its version number to 13822.101.x, in macOS 26.4, 15.7.5 and 14.8.5. We’ll see how close that gets.

I maintain separate lists of current firmware versions for all three supported versions of macOS:

• macOS 26 Tahoe
• macOS 15 Sequoia
• macOS 14 Sonoma

Secure Boot on an Apple silicon Mac is unlike anything you’ve seen in the past, sequences that start from the Boot ROM, and progress through two levels of ‘firmware’ before even loading the kernel. This article tries to explain its main stages up to the point that OpenDirectory is started, about 10 seconds after pressing the Power button.

The first three stages are essentially the same, whether the Mac is starting up from macOS on its internal SSD, or from a copy installed on external storage:

1. The Boot ROM, which is in the hardware, and can’t be changed. In this context, its most important task is to verify the executable for the next stage, load and run it. If that isn’t possible, then the fallback is to go into DFU mode and await a connection over USB.
2. The Low-Level Bootloader, LLB, to verify and read stored security settings, and locate and verify the software for the next stage, then hand over to it. This is stored in dedicated Flash memory, and relies on LocalPolicy and other files stored in protected areas on the internal SSD.
3. iBoot or iBoot Stage 2, popularly but incorrectly called the ‘firmware’, has to verify a set of hashes used to guarantee the integrity of key information, by comparing a stored copy of the hash against a hash of that hash, termed its signature. Among those is the root hash of the Signed System Volume (SSV), but iBoot doesn’t attempt to access the SSV or its hashes, merely passing on the verified root hash for the kernel to use later. Once it has completed those checks, iBoot verifies, loads and runs the macOS kernel.

Kernel boot (5.3 seconds)

These stages leave little evidence of what takes place, as they don’t write to the log. Instead they leave terse binary data known as breadcrumbs that may be found in NVRAM. The only log entries for them are the initial announcement, and the start of the kernel phase. Throughout this article, I quote these from macOS 26.2 in Full Security mode on a Mac mini M4 Pro, with the Power button being pressed at about 0.0 seconds.
0.24 === system boot: F5BD2102-F86A-4823-8FF9-A4535295F9FA
5.30 kprintf initialized

The kernel takes over from iBoot at about 5.3 seconds, and reports its version, in this case Darwin Kernel Version 25.2.0. The log stream is configured, and the iBoot versions are given. It then starts running up security systems, including CoreCrypto, and loads security policy with Apple Mobile File Integrity (AMFI) and Seatbelt sandbox policy (Sandbox).

Early hardware (5.6 seconds)

Then the kernel enters its main phase for starting hardware and its services. First are AppleT6041ANEHAL and IOAccessoryManager, followed by IOThunderboltFamily. Some of these are still security-related, including AppleCredentialManager and a long series of initialisation for the Secure Enclave, beginning with the detailed
5.696 "AppleSEPKeyStore":pid:0,:327: starting (BUILT: Nov 18 2025 20:56:29) ("normal" variant 🌽 , 2155.60.14)
KernelBluetoothFamily starts at about 5.7 seconds, and AppleT6040PCIeC shortly afterwards.

At 5.71 seconds AppleARMWatchdogTimer is started to keep an eye on processes that become unresponsive, and that’s followed by the traditional copyright notice that has been there since the first Mac OS X:
5.712 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved
a reminder of long-past history.

That’s followed by the start of RTBuddy, AppleSMC and at 5.836 seconds AppleSEPManager. RTBuddy provides communications support to the real-time operating system RTKit that’s run on the co-processors and support cores within the SoC, believed to include the Apple Neural Engine (ANE), Display Coprocessor (DCP), NVMe controller, and System Management Controller (SMC). RTBuddy messages are then frequent throughout the log during the kernel phase.

CPU cores (6.1 seconds)

Up to this point, the kernel has been running on a single CPU core, but by about 6 seconds it’s time to start up all the CPU cores one by one. This occurs by cluster, starting with cluster 0 of E cores, followed by the P cluster(s) in numeric order.

Once those are running, APFS and NFS are loaded and started, the former in an entry giving version details:
6.130 apfs_module_start:3677: load: com.apple.filesystems.apfs, v2632.40.17, apfs-2632.40.17, 2025/11/18
Gatekeeper is enabled, and AppleSystemPolicy started. Despite the implications of its name, the Always-On Processor (AOP) is then readied with its SMC service.

File system (6.3 seconds)

At 6.315 seconds, APFS starts its work accessing the three containers in the SSD, disk0s1, disk0s2 and disk0s3. It then gets the boot device, declares it as BSD root: disk3s1 and starts to mount the SSV. That may seem paradoxical, as by this time the kernel from the SSV has been running for over a second, but that was loaded by iBoot, together with the kernel extensions it requires. Similarly, the NVRAM is prepared for use by deleting nonce seeds, writing breadcrumbs from the previous boot phases, etc.

APFS continues to mount volumes, including Recovery at disk3s3 and the macOS Base System. The OS run by the Secure Enclave Processor, SEP/OS, is declared alive at 6.37 seconds, and the SEP is then preparing.

Userspace boot (6.4 seconds)

This is declared at 6.375 seconds, and the kernel then attempts to load launchd. Additional volumes are mounted from 6.8 seconds, including VM, Preboot, Update, xART, ISCPreboot and Hardware.

With the SEP running, BiometricKit is started at 8.788 seconds. At about 9 seconds, APFS tries to mount the Data volume at disk3s5, but that can only be successful if FileVault isn’t enabled, so that fails, and has to await the loginwindow and the user password entered there. At 9.429 seconds, a long list of boot tasks is given.

At 9.875 seconds, OpenDirectory is started, followed by the first of two wallclock time adjustments
=== system wallclock time adjusted
at which point all log times are adjusted accordingly.

By this stage, 10 seconds after the Power button was pressed, the kernel and other processes that are just about to start up have access to the hidden containers and volumes, and the SSV, but not the Data volume (unless FileVault is disabled). Logs are most probably stored in memory until they can be written to the Data volume, and none of the settings or processes on that can be read. Those all require the user to unlock the Data volume.

There’s a superbly detailed account of security aspects in this article.