Don’t be put off by its title: Apple Platform Security Guide is mandatory reading for all advanced Mac Users, and the only way we get to learn about important details of macOS, iCloud, and much else.

Its annual revision was published late last week, inappropriately on Friday 13th. While I still have a great deal more to read, my attention was drawn to an important change in M1 recoveryOS with external boot disks. What I read horrified me, as not only has it not been explained in user documentation, but what’s written in this Guide is incorrect.

Although Secure Boot on M1 series Macs has similarities with that on T2 Macs, how the two architectures handle booting from external disks is quite different. From the outset T2 Macs don’t really want to do that, and you have to enable it using Startup Security Utility in Recovery Mode. M1 series Macs are more accommodating, and have an elaborate system of LocalPolicy to enable them to boot from external disks without that hassle. One good reason for wanting to do that is when you sometimes need to run your M1 Mac at reduced security so it can load third-party kernel extensions (kexts), something a T2 has few qualms about. To do that on your M1 Mac, you’ll need to boot it in recoveryOS and use its Startup Security Utility to reduce security and to enable the loading of third-party kexts.

This has changed from Big Sur to Monterey, as reflected in new instructions included in this latest edition of the Guide.

This comes about because M1 Recovery has changed too. In Big Sur, whenever you boot into primary recoveryOS, that uses a dedicated container on the internal SSD. In Monterey, primary recoveryOS is now a paired volume in the current boot volume group, much as it is in all Intel Macs. I documented this change here, and so far it not only works better, but it ensures that Recovery Mode is that intended for the system your Mac is booted from, a big step forward.

This is explained clearly in this updated Guide, but there’s an important addition which could explain why some users have had problems with external boot disks in Monterey. Let me quote the exact words:
“To boot into a paired recoveryOS for any macOS installation, that installation needs to be selected as the default, which is done using Startup Disk in System Preferences or by starting any recoveryOS and holding Option while selecting a volume.”
I have added emphasis to the key words here, which refer to making a boot volume group “the default”.

What’s most troubling is that neither of the procedures mentioned explicitly do that, as far as the user is concerned, and the latter is in complete contrast to the way that Intel Macs work.

First, the Startup Disk pane on M1 series Macs is identical in appearance and function to that on Intel Macs. Once you’ve authenticated, select the disk (boot volume group) you want your Mac to start up from, and click its Restart… button. Nowhere is there any mention of making that boot disk “the default”.

If that isn’t confusing enough, try it in Recovery. If you follow the procedure given in the Guide, all you’ll see is a Continue button, not the button labelled Always Use, which presumably makes that boot volume group “the default”. In order to see that displayed, the procedure required is subtly different: you have to select the boot disk icon first, then hold the Option key until the button below it changes to Always Use.

That procedure has puzzled some of us since it first appeared in Big Sur, as we couldn’t understand the difference between always using a boot volume group, and restarting using it. As far as the user is concerned, the effect is identical, and the same as when used on an Intel Mac. This mystery deepens, as that isn’t the only place that M1 Recovery Mode lets you change the boot volume group, although it is the only one which employs the words “Always Use”.

If, instead of making your choice of boot disk in the first Recovery screen, you select Options to show the main Recovery menu, you’ll see another option in the Apple menu there, the command Startup Disk…, which displays a dialog not unlike that in the Startup Disk pane in regular macOS, which has a different button labelled simply Restart…. Are you confused yet?

The importance of this is that, according to this latest edition of the Guide, if you don’t boot correctly from the paired recoveryOS for the boot volume group whose boot security you want to change, any changes made in Startup Security Utility may not take properly. Indeed, several of us have experienced problems trying to get a downgraded copy of macOS on an external disk to load third-party kexts. Could this be the result of our not setting that boot volume group as “the default”?

Look in any of Apple’s user documentation such as its guide to M1 Recovery Mode and you won’t see any of this mentioned, let alone explained. The only other place that I’ve found any reference to this is, as you’d expect, in man bputil, where it states:
“Every installation of macOS 12 is paired to a recoveryOS stored on the corresponding APFS volume group. If a macOS 12 installation is selected to boot by default, then its paired recoveryOS will be booted by holding down the power key at boot time. The paired recoveryOS can downgrade security settings for the paired macOS installation, but not any other macOS installation.”
Strangely, that man page is dated 1 September 2020, although that change wasn’t introduced until a year later with Monterey.

What the Guide says currently is incorrect at the least. If M1 Recovery Mode really does have two different ways of selecting the boot volume group to be used next, their differences need to be explained properly and not left to inference and guesswork. Users, who are hardly likely to pore over the Guide or study bputil’s man page, need clear explanation of how they should start their M1 Macs from an external boot disk, how its local Recovery system is paired to it, and how to use Startup Security Utility effectively.

Finally, macOS Monterey 12.0.1 was released on 25 October 2021. This new version of the Guide was published on 13 May 2022, over six months later.

I’m very grateful to @mikeymikey for drawing my attention to this.