This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 26.0 Tahoe.
Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. Intel models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs just give an iBoot version.
Macs still running older versions of macOS are covered by information at:
The current EFI version is 2092.0.0.0.0 and iBridge is 23.16.10350.0.0,0.
Apple Studio Display
The current version remains 17.0 (build 21A329).
How to check your Mac’s firmware version
The simplest way is to run my free tool SilentKnight, available from its 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 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.
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 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.
Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.
One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.
Emergencies
The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.
Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.
In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).
Reverting macOS
The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.
I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.
On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.
Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.
Checklist
Check you’re prepared to use your disaster plan if needed.
Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
Make a full backup immediately before starting the upgrade.
Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
Revert an Intel Mac using a bootable external installer.
Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.
Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.
Inside every Intel Mac with a T2 chip, and every Apple silicon Mac, is a secure enclave, originally referred to as its security enclave. The subject of a flurry of Apple’s patents from 2012 onwards, this was introduced in the A7 chip inside the iPhone 5s and iPad mini 3, 12 years ago in September 2013, where it brought biometric authentication in Touch ID.
iPhone 5s
Protecting the most important secrets in a computer is a great challenge. No matter how secure you try to make the main processor and memory, as they’re exposed to direct attack, isolation can only be relative and temporary. An alternative approach is to move the most secure data and its processing into a secure enclave and its processor, and that’s the architectural solution chosen by Apple in what it patented as a security enclave, filed in September 2012, a year before its release in the iPhone 5s. Engineers credited for that patent are Manu Gulati, Michael J Smith and Shu-Yi Yu.
Successive iPhone chips steadily improved their secure enclaves, and by the time the iPhone 7 was introduced in September 2016, with its A10 Fusion chip, its secure enclave was handling encryption and authentication but not replay prevention. It also had EEPROM secure storage, and an AES engine with DPA protection and lockable seed bits. When the first Intel Mac with a T1 chip was released a couple of months later, that was based not on the A10 but the S2 used in the Apple Watch Series 2. The T1 thus doesn’t really have a secure enclave as such, although it supports Touch ID.
An early and thorough account of these secure enclaves was presented by Tarjei Mandt, Mathew Soling and David Wang at Black Hat USA in 2016. This appears to be the only such account apart from the section in Apple’s Platform Security Guide, most recently updated in December 2024. Apple’s engineers continued to gain new patents, covering trust zone support (filed in 2012), key management (filed in 2014), and most relevant to Macs, Pierre Olivier Martel, Arthur Mesh and Wade Benson’s patent for multi-user storage volume encryption, filed in 2020.
T2 chip
The first Macs with a true secure enclave are those with a T2 chip, starting with the iMac Pro in December 2017. Those are based on the same A10 Fusion chip from the previous year, and were already lagging the iPhone 8 in this respect.
The T2 secure enclave is another co-processor system, run by a Secure Enclave Processor (SEP), a 32-bit ARM CPU running its own operating system, sepOS, based on a specialised L4 microkernel completely different from those used by Macs and Apple’s devices. It has its own secure storage (EEPROM), and a Public Key Accelerator for signing and encryption/decryption using RSA and ECC methods. Outside the enclave is a dedicated AES256 encryption/decryption engine built into the data transfer path between the internal SSD and main system memory.
M-series chips
The big leap forward for Macs was the release of the first models featuring M1 chips, which caught up with the features of late versions (after autumn 2020) of the A12 and A13, with Apple’s second generation Secure Storage Component.
Perhaps the most significant of its improvements are measures to prevent replay attacks. Those are best illustrated with FileVault. Let’s say that you didn’t enable FileVault at first, but left your Apple silicon Mac to handle the encryption of its internal Data volume without the added protection of your password. That would mean that its volume encryption key (VEK) was generated internally by the Secure Enclave, and stored there. If you then turned FileVault on, the VEK would be encrypted using your password and the hardware key. In the T2 chip, it might be possible to use the old VEK to decrypt the volume. In the secure enclave of an M-series chip, that type of replay attack is prevented by the revocation of all previous events and records.
Other improvements include the use of second generation secure storage incorporating counter lockboxes to enforce limits on the number of passcode attempts allowed, instead of an EEPROM, and a better Public Key Accelerator.
Currently, the secure enclave is known to protect the following:
encryption keys for Touch ID, FileVault, and the Data Protection (iCloud) keychain (but not file-based keychains);
that Mac’s Unique ID (UID) and Group ID (GID);
Touch ID control, and (on older devices not Macs) Face ID using a secure neural engine; in recent devices and M-series chips, that’s implemented as a secure mode in the main neural engine (ANE);
Apple Pay handling;
Activation Lock, through the Owner and User Identity Keys;
signing and verification of LocalPolicy for boot environments (Apple silicon).
Communication between the CPU and SEP is performed using a dedicated mailbox whose function is detailed in Apple’s patents. Further information is also provided in the Platform Security Guide.
FileVault encryption
It has been stated widely (even here) that the secure enclave in T2 and Apple silicon chips contains a hardware encryption/decryption unit and acts as the internal SSD’s storage controller. In fact, as shown in the original patent of Martel and others, and now in the Platform Security Guide, the AES engine responsible is located outside the secure enclave, together with the Flash controller, and has a secure link to the enclave.
During SEP boot, it generates an ephemeral key to wrap keys to be used by the AES engine for encryption and decryption. That key is sent from the secure enclave to the AES engine over the dedicated connection between them, then used to protect keys transferred from the enclave to the AES engine. That ensures an unprotected key is never exposed outside the enclave and AES engine.
The Apple silicon secure enclave is by no means unique. ARM TrustZone, other Trusted Execution Environments, and Trusted Platform Modules offer similar features and facilities. However, the secure enclave is unusual because it has been integrated into all Macs with T2 or Apple silicon chips, and all Apple’s recent devices, and can’t be disabled or bypassed.
References
Manu Gulati, Michael J Smith and Shu-Yi Yu, US Patent 8,832,465 B2, Security enclave processor for a system on a chip, filed 25 September 2012, granted 9 September 2014.
R Stephen Polzin, James B Keller, Gerard R Williams, US Patent 8,775,757 B2, Trust zone support in system on a chip having security enclave processor, filed 25 September 2012, granted 8 July 2014.
R Stephen Polzin, Fabrice L Gautier, Mitchell D Adler, Conrad Sauerwald and Michael LH Brouwer, US Patent 9,419,794 B2, Key management using security enclave processor, filed 23 September 2014, granted 16 August 2016.
Pierre Olivier Martel, Arthur Mesh and Wade Benson, US Patent 11,455,432 B1, Multi-user storage volume encryption via secure processor, filed 8 June 2020, granted 27 September 2022.
Tarjei Mandt, Mathew Soling and David Wang (2016), Demystifying the Secure Enclave Processor, Black Hat USA 16 (PDF)
Apple, Platform Security Guide
Wikipedia’s overview of Apple silicon chips.
In the last few months I have had reports from several whose Macs have experienced a “SEP Panic” rather than a regular kernel panic. Although the immediate effects are the same, and my previous advice on how to deal with a kernel panic still applies, this article looks in more detail at what should be exceedingly rare events.
Essentials
If your Mac restarts or shuts down spontaneously, or ‘freezes’ for you to force it to shut down, chances are that was a kernel panic. When it starts up again, look out for the dialog inviting you to send a report to Apple. Expand that so you can see the panic log, copy and paste that into a text document, and save it. That’s the only record you have of that report, and that provides valuable clues as to what went wrong and how you might go about fixing it.
Apple will not contact you in response to sending the panic log. If you want advice or assistance about your Mac, contact Apple Support, and ensure you have your copy of the panic log ready, as they’ll need to see it.
Secure enclave
No matter how secure you try to make an operating system, if its most precious secrets are being processed by the main CPU cores, an attacker will find a way to access them. The proven solution to this is to build in a separate part of the chip with its own processor, and isolate that from everything else – a secure enclave, with its own secure enclave processor, SEP, as patented by Apple 13 years ago.
Two Mac architectures have secure enclaves and SEPs: Intel Macs with T2 (and T1) chips, where the SEP is in the T2/T1, and Apple silicon Macs, where the SEP is an integral part of the chip. These handle several different security features, including biometrics in Touch ID, management of secure encryption keys including those for FileVault, and performing encryption and decryption for the internal SSD.
The SEP runs its own operating system, sepOS, thought to be a derivative of L4, and communicates with the rest of the chip using mailboxes. When the CPU needs something from the SEP, it posts a message in the SEP mailbox, then retrieves the response when the SEP has processed that request.
What could possibly go wrong?
Like all processors, the SEP can hit problems that it can only manage by a reset, and those will result in it panicking, which in turn provokes the kernel running on the CPU to panic. Those problems can result from anything from a hardware fault to a bug in sepOS.
The SEP in a T2 chip is also known to be vulnerable to some exploits including blackbird, which can be used to ‘jailbreak’ a device using checkra1n or with malicious intent.
Reading the SEP panic log
When a kernel panic is the result of a SEP panic, the panic log is different from normal, and contains considerable detail about the SEP and what went wrong with it. As usual, though, much of that information is cryptic to say the least.
The first line in the panic log confirms that the panic originated in the SEP panic(cpu 1 caller 0xfffffe001f55e344): SEP Panic: […]
You’re then given the version of sepOS Root task vers: AppleSEPOS-2772.140.4
Unfortunately, further down it disclaims knowledge of that Firmware type: UNKNOWN SEPOS
The status of the SEP’s mailboxes are given Mailbox status:
IDLE_STATUS: 0x00000008
INBOX0_CTRL: 0x00105601
OUTBOX0_CTRL: 0x00023301
and Mailbox entries:
Unavailable
Mailbox queue pointers: […]
This is confirmed as a panic Debugger message: panic
The version of macOS is given by build number, with details of the kernel running on the CPU OS version: 24G90
Kernel version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
For a T2 chip, the kernel version given should be for a T8010 root:xnu-11417.140.69~1/RELEASE_ARM64_T8010
Apple silicon Macs should then confirm their iBoot versions, first the LLB (Stage 1) then iBoot Stage 2, and whether Secure Boot was used iBoot version: iBoot-11881.140.96
iBoot Stage 2 version: iBoot-11881.140.96
secure boot?: YES
T2 SEPs don’t normally give an iBoot Stage 2 version, but provide information about the Intel (x86) host iBoot Stage 2 version:
secure boot?: YES
roots installed: 0
x86 EFI Boot State: 0xe
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0x5
x86 Previous Power Transitions: 0x20002000200
PCIeUp link state: 0x94721611
Information is provided about the task running on the CPU, which should normally be the kernel Panicked task 0xfffffe1fb0037248: 0 pages, 654 threads: pid 0: kernel_task
Towards the end of the panic log are details about kernel extensions. In SEP panics, that includes the SEP Manager Kernel Extensions in backtrace:
com.apple.driver.AppleSEPManager(1.0.1)[UUID]@0xfffffe001f5366e0->0xfffffe001f566a63
and last started kext at 242997189818: com.apple.iokit.SCSITaskUserClient 500.120.2 (addr 0xfffffe001ce0f6a0, size 2206)
loaded kexts:
In the list of loaded kernel extensions that follows, ensure there are no third-party entries, unless your Mac is expected to load them.
Actions
Although you should take a SEP panic seriously, there’s no need to panic yourself. This doesn’t mean that your Mac’s SEP has died, has been attacked by malware, or has released all the secrets it protects. A single panic in isolation could well just be chance, and not indicative of anything serious.
Provided that your Mac starts up correctly and then runs normally, your only essential task is to ensure that you capture and keep a copy of the panic log. If you wish, you can run hardware Diagnostics, but I doubt whether that performs any specific test intended to detect problems in the SEP. If you have potentially problematic peripherals, or any third-party kernel extensions, then you should take the hint and try to eliminate them.
If your Mac suffers any further kernel panics, capture their panic logs, and contact Apple Support with those to hand. Alternatively, book your Mac into an Apple store or authorised service provider for them to check it out for you.
Summary
SEP panics are exceedingly rare, but are readily identified from the first line of the panic log.
Ensure you copy and save a copy of the panic log.
Much of the panic log will appear meaningless, but there is some information about version numbers and kernel extensions that may be helpful.
Follow the normal recommendations, considering hardware diagnostics, and updating/removing potentially troublesome peripherals and third-party kernel extensions.
If there are any further panics, capture those and obtain support from Apple.
Login
