For the last ten months or so, M1 Macs have led a simple life. They’ve run just one major version of macOS, Big Sur, and being low-end models few have been doing adventurous things like booting from external disks or running in reduced security modes. In the next few weeks this will all change, when Monterey is released, with new models aimed at higher-end use, and the more complex setups those can require. This article takes a first look at how this is going to be reflected in changes in Recovery, and in tools such as Startup Security Utility. This is based on recently revised documentation for the command tool bputil.

Before trying to explain the new architecture of Recovery in Monterey, I need to explain some terms, the first of which we might already think we understand, but has now become clearer.

The first is One True Recovery (1TR), Apple’s term for the system invoked when you start an Apple Silicon Mac up with its Power button held. This isn’t a specific recoveryOS or Recovery mode, but is used to describe the special boot to Recovery which occurs when a user holds the Power button at startup. It’s distinctive because it’s the only way to gain access to Startup Security Utility to change security settings, and can only ever be invoked by a physical user. As you’ll read below, depending on the version of macOS which has been running prior to 1TR, this may run different versions of recoveryOS.

Next is the new concept of a paired recoveryOS, which is a specific Recovery System associated with a bootable macOS system. In Big Sur, this is simply the recoveryOS installed in the Recovery container on the internal SSD, which is booted with 1TR and known as system recoveryOS. In Monterey, this gets more complex so that it can support a wider range of versions of macOS and LocalPolicy controls over different installed systems. This follows the scheme already used on Intel Macs, with a Recovery volume installed with each boot Volume Group rather than the system recoveryOS. That’s the paired recoveryOS for that boot Volume Group.

This may appear complex, but for the great majority of use cases is completely transparent, and really does just work.

In the simplest and most common of cases, an Apple Silicon Mac boots from the single bootable macOS on its internal SSD. If that’s Big Sur, then booting it into Recovery using the Power button (1TR) uses the system recoveryOS installed in its separate container on the internal SSD. That will normally be the correct recoveryOS for that version of Big Sur, and the user won’t notice anything different. If the user wants to change the security settings for that copy of Big Sur, then Startup Security Utility will do that.

Consider that same M1 Mac which is set to start up from an external disk containing Monterey, instead of its internal SSD. During the early part of its boot process with the Power button held for 1TR, the Mac detects that it’s set to boot from that external disk, and starts up from the paired recoveryOS installed with that copy of Monterey. That contains recoveryOS specific to that version of macOS, and its Startup Security Utility can change the security settings for that boot disk, but not the bootable copy of Big Sur on its internal SSD, because that isn’t paired with the current boot OS.

There are more subtle details given in the documentation for bputil. For example, because Big Sur is always paired with the system recoveryOS on the internal SSD, that Recovery controls security settings of any macOS 11 installations, and none of those can have a local paired recoveryOS, as they don’t exist for macOS 11. bputil can also increase security settings without a pairing requirement, but options such as enabling kernel extensions and disabling the Sealed System Volume are only available in 1TR with its paired recoveryOS.

I also remind you that, no matter how technically competent you consider yourself, bputil is an extremely dangerous tool if you stray from using its -d or -e options to display LocalPolicy. As Apple warns “This tool is not to be used in production environments. It is possible to render your system unbootable with this tool.”

The big question, of course, is how well does this work in practice? It’s been in both developer and public beta-releases of Monterey for a good while now, and few testers even seem to have noticed yet. From the few comments that I have seen, it appears robust and reliable, and should cope well with the increasingly demanding setups coming to Apple Silicon Macs.