Same macOS, Different Firmware: Apple Quietly Changed the Sequoia and Sonoma Updates
Two Macs on Sequoia 15.7.9 can now have different mBoot firmware depending on when they updated. Apple changed the update without changing the build number. Here is how to check yours.
Take two Macs. Both run macOS Sequoia 15.7.9. Both show the same build number in About This Mac. One of them updated on 7 August 2026, the other on 28 August. Open System Information on each and look at "System Firmware Version": the first says 18000.161.9, the second says 18000.161.10.
Nothing in Apple's release notes explains this. The 15.7.9 update did not get a new build number. The security notes for it were not amended. Apple simply started shipping different firmware inside the same-named update at some point after 17 August, and the only reason anyone knows is that Howard Oakley keeps virtual machines for exactly this kind of comparison and noticed the numbers had moved.
This article explains what firmware version your Mac should have, how to read it, why the number has stopped tracking the macOS version, and what — if anything — you should do about it.
Key Takeaways
- Apple silicon Macs on Sequoia 15.7.9 or Sonoma 14.8.9 can have either mBoot
18000.161.9or18000.161.10, depending on whether they installed the update before or after 17 August 2026. The macOS build number is identical either way. 18000.161.10is the firmware that shipped only with Tahoe 26.6.2 on 17 August. Apple later started including it in the unchanged Sequoia and Sonoma updates without saying so.- Since macOS 26.4, Apple silicon firmware calls itself "mBoot", not iBoot, and jumped from the
13822.xseries to18000.x. We verified the label on our own Mac: the boot firmware literally reports itself asmBoot-18000.121.3. - There is no longer a reliable mapping from macOS version to firmware version. For six years there was. That assumption is now wrong, and tools and compliance checks built on it will produce false alarms.
- This is not evidence of compromise. But Apple has published nothing about what changed, so a Mac with a firmware number you cannot explain is an audit problem even when it is not a security problem.
What Changed, in One Table
The whole story is in the firmware column. Every version below is for Apple silicon Macs; Intel Macs with T2 chips use a different numbering and are covered separately further down.
| Date | Tahoe | Sequoia | Sonoma | Apple silicon firmware |
|---|---|---|---|---|
| 12 Dec 2025 | 26.2 | 15.7.3 | 14.8.3 | iBoot 13822.61.10 — all three in sync |
| 24 Mar 2026 | 26.4 (25E246) | 15.7.5 | 14.8.5 | mBoot 18000.101.7 — new name, new numbering; sync still holding |
| 11 May 2026 | 26.5 (25F71) | 15.7.7 | 14.8.7 | mBoot 18000.120.36 — in sync |
| 29 Jun 2026 | 26.5.2 (25F84) | — | — | mBoot 18000.121.3 — Sequoia and Sonoma left behind |
| 27 Jul 2026 | 26.6 (25G72) | 15.7.8 | 14.8.8 | mBoot 18000.161.9 — back in sync |
| 6 Aug 2026 | 26.6.1 (25G76) | 15.7.9 | 14.8.9 | mBoot 18000.161.9 — unchanged |
| 17 Aug 2026 | 26.6.2 (25G83) | — | — | mBoot 18000.161.10 — Tahoe only |
| after 17 Aug | — | 15.7.9 (same build) | 14.8.9 (same build) | mBoot 18000.161.10 — silently changed |
Oakley states the three systems stayed in sync until early summer, which is why the March row is shown as matching. The figures come from his release-day posts for each update (26.4, 26.5, 26.6, 26.6.1, 26.6.2), plus one row we can confirm directly: the Mac this article was written on runs 26.5.2 and reports 18000.121.3.
The last row is the one that matters. Same version, same build, different firmware, no announcement.
How to Read Your Own Mac's Firmware Version
There are three ways, and the third one tells you something the first two do not.
System Information
Apple menu > About This Mac > More Info > System Report, then Hardware at the top of the sidebar. Two lines matter:
System Firmware Version: 18000.121.3
OS Loader Version: 18000.121.3On a healthy Mac these two match. They are the two stages of the boot firmware, and Apple updates them together.
Terminal, the quick way
system_profiler SPHardwareDataType | grep -E "Firmware|Loader"Same two lines, scriptable. This is what most inventory tools collect.
Terminal, the way that shows the label
The version string macOS displays is a trimmed version of what the firmware reports about itself. To see the untrimmed version, read the device tree:
ioreg -p IODeviceTree -n chosen -r | grep -E "firmware-version|iboot-stage"On our 26.5.2 Mac that returns:
"iboot-stage-two-tag" = <"mBoot-18000.121.3">
"iboot-stage-one-tag" = <"mBoot-18000.121.3">
"system-firmware-version" = <"mBoot-18000.121.3">Two things are worth noticing. The firmware calls itself mBoot. The property names still say iboot. That is the whole rename in one line: Apple changed the string the firmware reports, and left the plumbing that reads it alone.
What "mBoot" Actually Is
Apple's own Platform Security guide describes the Apple silicon boot chain in four steps: the Boot ROM in silicon starts the chain of trust; the Low-Level Bootloader (LLB) verifies signatures and fetches the LocalPolicy from the Secure Enclave; iBoot loads the remaining firmware, verifies the kernel collections and the root hash of the signed system volume; then the kernel takes over. The document does not contain the word "mBoot" anywhere. As far as Apple's published documentation is concerned, the component is still called iBoot.
What happened in macOS 26.4 is that the version string changed. Oakley's SilentKnight release note from March records the transition as first appearing in the 26.4 beta 2, from iBoot 13822.101.6 to mBoot 18000.101.6, and surviving through to the final 18000.101.7. His reading is that Apple wanted "to bring Mac and device firmware into the same numbering system." That is an inference; Apple has said nothing. What we can confirm is the observable half: on any Mac running 26.4 or later, the two boot stages identify themselves as mBoot-<version>, and the numbering starts at 18000.
For practical purposes: mBoot is iBoot with a new name tag. It does the same job, it sits in the same place in the chain, and it is updated by the same mechanism — a macOS update or install that happens to contain a newer version.
Why the Firmware Used to Track macOS Exactly
To understand why the August change is a break, you need to know how tidy the situation was before.
On Intel Macs without a T2 chip, firmware was per-model. Each macOS installer carried a library of EFI updates, one for every model it could install on, so the "correct" firmware for a given Mac depended on both the macOS version and the machine. Oakley compiled those tables by hand for years.
T2 Macs simplified this: one common EFI and one common iBridge version per macOS release, regardless of model.
Apple silicon simplified it further. From 2020 until the middle of this year, every Apple silicon Mac on a given macOS version had the same firmware, and — the part that mattered for security — the three supported macOS versions updated their firmware in lockstep. When Tahoe 26.2 moved firmware to 13822.61.10 in December 2025, the same-day security updates to Sequoia 15.7.3 and Sonoma 14.8.3 did the same. A Mac's firmware version told you exactly which security release it had, whichever of the three systems it ran.
Oakley says he found this link so robust he considered dropping firmware checks from SilentKnight altogether.
How the Sync Broke in Summer 2026
The break came in two steps.
The first was a gap in the update schedule. Between 11 May and 27 July, Sequoia and Sonoma received no security updates. Tahoe received two: 26.5.1, an enterprise fix for M5 Macs shutting down under certain content-filtering network extensions, and 26.5.2, a security release. The second of those carried a firmware update, to 18000.121.3. For roughly six weeks, a Tahoe Mac and a Sequoia Mac that were both fully patched ran different firmware. Oakley flagged this at the end of June as "the first time in the last six years that large numbers of Macs will have firmware that is out of sync."
The 26.6 wave on 27 July repaired it: Tahoe 26.6, Sequoia 15.7.8 and Sonoma 14.8.8 all moved to 18000.161.9, and the 6 August updates (26.6.1, 15.7.9, 14.8.9) left the firmware alone. Everything matched again.
Then on 17 August Apple shipped Tahoe 26.6.2 — the out-of-band release that backported fixes from the macOS 27 beta — with firmware 18000.161.10. There was no corresponding Sequoia or Sonoma update. Those systems stayed at .9. Out of sync again, and this time with a security release in between.
The Silent Part
Everything so far is untidy but documented — each of those firmware versions was reported on the day. What was not documented is what happened next.
Oakley had updated his Sequoia and Sonoma virtual machines to 15.7.9 and 14.8.9 on 7 August, and they have stayed at 18000.161.9 since, because no further update has been offered to them. But when he created fresh Sequoia and Sonoma VMs on 28 August and updated them to the same 15.7.9 and 14.8.9, they came up with 18000.161.10 — the firmware that had only ever shipped with Tahoe 26.6.2.
It appears that those Macs that were updated to 15.7.9 or 14.8.9 prior to the release of 26.6.2 on 17 August had their firmware updated to 18000.161.9, while those updated since 17 August have been provided with 18000.161.10 instead, without any change in macOS version or build number. There has been no mention of any such change in Apple's security release notes.
We checked the other half of that claim. Apple's security content page for 26.6.2 contains no mention of firmware, mBoot, or iBoot at all. Neither do the 15.7.9 and 14.8.9 pages. As far as Apple's public record goes, nothing changed.
A note on the evidence. Oakley's comparison uses virtual machines rather than physical Macs. That is a strength rather than a weakness for this particular question: on Apple silicon, a macOS VM's boot firmware is supplied by the guest's own installer and updater, so a fresh VM reporting .10 after installing "15.7.9" means the 15.7.9 update payload now carries .10. It does not tell us how a physical Mac already at .9 will be treated, and we have not been able to test that ourselves.
Which Number Should You Have?
Given the table above, this is what to expect.
| You are running | Updated before 17 Aug | Updated after 17 Aug |
|---|---|---|
| Tahoe 26.6.2 | (not possible) | 18000.161.10 |
| Tahoe 26.6.1 | 18000.161.9 | — update to 26.6.2 |
| Tahoe 26.5.2 | 18000.121.3 | — update to 26.6.2 |
| Sequoia 15.7.9 | 18000.161.9 | 18000.161.10 |
| Sonoma 14.8.9 | 18000.161.9 | 18000.161.10 |
| Sequoia 15.7.8 / Sonoma 14.8.8 | 18000.161.9 | 18000.161.9 |
If your Sequoia or Sonoma Mac shows 18000.161.10, you are on the newer firmware and there is nothing to do. If it shows 18000.161.9, you are on the firmware that was correct on the day you updated, and there is currently no update that will move you — Apple has not re-offered 15.7.9 or 14.8.9 to Macs that already have them.
Anything else — a 13822.x number on a Mac that claims to be on 26.4 or later, or a 18000.x number that is not in this table — is worth understanding before you dismiss it. The most common innocent explanation is that the Mac has more than one macOS installed and you are reading the loader for a different volume; see Troubleshooting below.
Does It Actually Matter?
Honestly: probably not much, for most people, right now. But the reasons it matters at all are worth stating precisely, because they are different from the reasons people assume.
It is not "your Mac is insecure"
Nobody outside Apple knows what changed between 18000.161.9 and 18000.161.10. It arrived with a security release, which suggests it is security-relevant, but firmware point releases also fix hardware compatibility, power management and boot-time bugs. Apple's 26.6.2 notes credit 28 CVEs and none of them is described as a firmware fix. If you are on .9, you are on firmware Apple considered current three weeks ago.
It is "your inventory is wrong"
For six years, "firmware version" was a derived attribute: know the macOS version and you knew the firmware. Anything built on that — a compliance rule, an MDM smart group, a spreadsheet, a script that flags outliers — will now see two populations of identical Macs and cannot tell you which is right. SilentKnight, the most widely used consumer tool for this, changed its behaviour in version 3.01 to report the firmware version as "found" rather than judging it current or outdated, precisely because the judgement is no longer possible.
It is "Apple changed a shipped update without a paper trail"
This is the part that should concern you more than the version number. Apple silicon updates are applied by what Oakley calls the Update Brain, a per-update component that macOS downloads to run that specific update. Apple evidently changed what one of those updates installs, kept the version and build identical, and published nothing. His conclusion is blunt:
In the absence of any information from Apple, some could reasonably suspect this was the result of a sophisticated attack.
He does not think it was. Neither do we. But "we cannot distinguish this from an attack using Apple's published information" is not where a security update process is supposed to sit.
If You Are on Sequoia or Sonoma and Want the Newer Firmware
You have three options and only the first is recommended.
Wait
Oakley expects Sequoia 15.8 to ship alongside macOS 27 in the second half of September. That update will almost certainly carry whatever firmware is current, which by then may be newer than .10 anyway — he expects the Golden Gate firmware to jump to roughly 20457.1.29. Sonoma is a different story: its final release may well be 14.8.9, in which case a Sonoma Mac updated before 17 August stays on .9 permanently. Which is fine, because so did every Sonoma Mac that updated on time.
Reinstall macOS from Recovery
A "Reinstall macOS" from recoveryOS downloads a fresh copy of the installed version and can update firmware if the installer contains a newer one. Given that fresh 15.7.9 installs now carry .10, this may work. We have not tested it, it takes an hour, and it is a disproportionate response to a version-string discrepancy. Do not do this to chase a number.
DFU revive
Apple's revive and restore procedure for Apple silicon Macs reloads the firmware from a second Mac over a USB-C cable. Apple says revive "doesn't erase your Mac" and to try it before a restore, which does. It needs a host Mac on macOS 14 or later and a USB-C cable that supports data and charging — Apple specifically says not to use a Thunderbolt 3 cable. This is the right tool for a Mac that will not boot. It is the wrong tool for a Mac that boots fine and has a firmware number you dislike. Mentioned only so you know it exists.
If You Are on Tahoe
If you are on 26.6.2, you already have .10 and nothing here applies. If you are on 26.6.1 or earlier, the fix is the update you should be installing anyway.
The next firmware change you see will be the big one. Golden Gate's firmware, on Oakley's reading of the betas, moves to a 20457.x series. The new Mac mini and Mac Studio ship on 22 September with a pre-release build of macOS 27 and will want an immediate update to 27.0.1 — expect their firmware to move at the same time.
For Fleet Administrators
Three concrete adjustments.
Stop treating firmware version as derivable from macOS version. Any rule of the form "15.7.9 implies 18000.161.9" is now wrong for a subset of your fleet, and the subset is defined by update timing you probably did not record.
Do not alert on .9 versus .10 alone. Both are legitimate outputs of the same Apple update. If you want a single value per macOS version to compare against, use the newer one as the target and treat .9 as "correct as of install date, will converge at next update."
Record the firmware version at enrollment and at each update, so that you can distinguish "this Mac was updated early" from "this Mac's firmware changed without a macOS update," which is the case that actually warrants a look. On Apple silicon, firmware only changes during a macOS install or update, so a firmware change without a corresponding macOS change is the anomaly to watch for — not a mismatch between two Macs.
What Apple Should Do
This is a small ask. Apple's security content pages already list every component and CVE in an update. Adding a line — "This update includes mBoot 18000.161.10" — would cost nothing and would have made the August change visible on the day. If the change was deliberate and benign, which is the overwhelmingly likely case, there is no reason to leave people to discover it by comparing virtual machines.
Intel Macs
Intel Macs with T2 chips report two firmware components: the EFI-style system firmware and the T2's iBridge (bridgeOS). Oakley's 26.6.2 post gives them as 2103.160.2.0.0 and iBridge 23.16.16068.0.0,0, unchanged from 26.6.1. The mBoot story does not apply to Intel hardware at all; the numbering never changed and the three-version sync was never broken there. Intel Macs on Tahoe are on their last macOS release regardless, so this is the final firmware lineage they will see.
Troubleshooting Common Issues
System Information shows two different numbers
"System Firmware Version" and "OS Loader Version" normally match. The most common reason they differ is that the Mac has more than one macOS volume installed — for example a Golden Gate beta on a separate volume — and the loader reported is the one paired with a different system. Boot into the other volume and compare. If they differ with a single macOS installed, that is unusual and worth reporting to Apple.
SilentKnight says "found" instead of "current"
That is the tool working as designed since version 3.01. It can no longer tell you whether your firmware is the latest, because Apple no longer guarantees a single answer per macOS version. Compare against the table above instead.
A virtual machine shows a firmware version that does not match the host
Expected. On Apple silicon, a macOS VM's firmware comes from the guest's installer, not from the host Mac. This is exactly why Oakley's VMs could reveal the change.
ioreg returns nothing for the chosen node
You are probably on an Intel Mac, where the device tree is laid out differently and there is no iboot-stage-one-tag. Use system_profiler SPHardwareDataType instead, which reports "Boot ROM Version" and, on T2 Macs, the iBridge version under Controller.
My Sequoia Mac shows 18000.161.10 but I updated on 7 August
Then something updated the firmware after that date. The candidates are a macOS reinstall, a revive, or an update you did not notice. Check Software > Installations in System Information for anything dated after 17 August. If nothing is there, note it — a firmware change with no corresponding install is the one pattern in this article that deserves a second look.
FAQ
Is 18000.161.10 a security fix?
Unknown. It shipped with a security release and Apple has not described its contents. Treat it as "newer," not as "patches a known hole."
Should I do anything if my Mac is on 18000.161.9?
No. It was the correct firmware on the day you updated, and the next macOS update you install will bring the current one. There is no exposed vulnerability that Apple has associated with .9.
Why does the firmware call itself mBoot when Apple's documents say iBoot?
Apple renamed the version string in macOS 26.4 and has not updated its security documentation to match. On our Mac the firmware reports mBoot-18000.121.3 while the device-tree keys that store it are still named iboot-stage-one-tag and iboot-stage-two-tag. Functionally, it is the same component.
Can firmware change without a macOS update?
On Apple silicon, no — firmware is only written during a macOS install, update, revive or restore. That is why a firmware change with no matching install record is the genuinely anomalous case.
Will macOS 27 fix the sync?
It will reset it. Golden Gate, Tahoe 26.7 and Sequoia 15.8 are expected together in September and should share firmware on day one. Whether Apple keeps them in sync afterwards, or repeats this summer's pattern, is the open question.
Conclusion
For six years, the firmware version on an Apple silicon Mac was a function of one thing: the macOS version. That made it useful — a single number that told you which security release a Mac had, regardless of whether it ran the current macOS or one of the two older ones. This summer that stopped being true, first because Tahoe's mid-cycle updates carried firmware the older systems did not get, and then, more seriously, because Apple changed what the Sequoia and Sonoma updates install without changing anything visible about them.
None of this makes your Mac less safe. It does make the firmware number harder to interpret, it makes tools that relied on it less useful, and it establishes that Apple will revise a shipped update in silence. If you administer Macs, adjust your expectations now, before the September release wave adds a fourth macOS version to the picture. If you do not, the practical takeaway is smaller: .9 and .10 are both fine, and the number to worry about is the one that changes when nothing else did.
Related reading: macOS Tahoe 26.6.2 and who found its 28 CVEs, the 26.6.1 Screen Sharing fix, how background security updates work on Tahoe, and what to do when a macOS update leaves a Mac unbootable.