Bombich Software recently updated Carbon Copy Cloner to version 6, and its founder, Mike Bombich, posted a blog entry explaining some of the intricacies involved with updating cloning software for Big Sur and M1-based Macs. One heading may have surprised those who haven’t read all the technical details about M1 changes: “An Apple Silicon Mac won’t boot if the internal storage has failed.”

That might seem bizarre. A core aspect of dealing with system failures on Macs is that you could maintain an external bootable drive, perhaps a bootable duplicate of your startup volume, that lets you use your Mac even if an internal drive was corrupted or failed entirely.

In “The Role of Bootable Duplicates in a Modern Backup Strategy” (23 February 2021), Adam Engst presciently explained why bootable clones might be a thing of the past. Now Mike Bombich has confirmed with Apple that external bootable drives won’t always work!

It’s true, but it’s not as terrible as it sounds. Let me first explain why you should be aware of it but not worry, and then explain the more technical details for those interested in the innards of macOS.

You’re Unlikely To Have a Dead Internal SSD and a Live Mac

The fresh information here is that an M1-based Mac relies on its internal SSD to allow external drives to boot. If the internal SSD has failed or been entirely erased—it contains several hidden volumes—you can no longer boot from an otherwise valid volume on an external drive. Why would Apple do this? To increase security. And, maybe, to reduce its tech support costs.

Relying on details stored only on the internal SSD to control startup from external drives is a way to make it harder for nefarious parties to hijack a Mac’s data. This approach is a shift from Intel-based Macs, which relied instead on firmware (software stored in programmable memory chips that can be updated). However, firmware updates can sometimes fail, causing temporary problems with a Mac or even “bricking” it. There may also be attack vectors related to firmware-based startup control that Apple hasn’t disclosed.

On an Intel-based Mac, you can set a firmware password that prevents booting from anything but a “designated startup disk.” Apple didn’t include that feature with M1-based Macs because the company changed the startup and recovery processes to require knowing a password associated with the selected startup volume. An Apple support document notes: “a Mac with Apple silicon also won’t require (or support) a firmware password—all critical changes are already gated by user authorization.” If you don’t have a valid account and password, you can’t change the startup volume or perform most other recovery features.

We don’t know to what degree problems with firmware updates or undocumented attack vectors contributed to Apple’s switch. Perhaps it was just a simple architecture change, given the reliability of SSDs and the ease of updating them to shift aspects of security from programmable memory chips to SSD storage? You might intuit that Apple could have had high ongoing costs of technical support related to firmware update failures and knew of exploits that compromise data on a Mac’s internal drive by starting up from an external drive. Maybe the cost of diagnosis and repair for Macs disabled or bricked due to firmware failures was high enough to be a consideration, too. But we don’t know.

However, here are the reasons we’re not too concerned about this change:

  • A large majority of people don’t possess a bootable external drive compatible with  M1-based Macs and would never create a bootable backup. (We cognoscenti may love booting from external drives, but it’s not a mainstream thing to do.)
  • Modern SSDs are extremely reliable. The vast majority of people with Apple silicon Macs will never experience a failure of their internal SSD. Thus, they will never encounter a situation where they can’t boot from an external drive due to an internal drive failure. Look no further than iPhones and iPads for evidence of this fact.
  • Should the internal boot volume become corrupted, or the firmware in the Secure Enclave develop issues, Apple provides a range of recovery options, including recoveryOS with macOS Recovery (a separate bootable partition), fallback recoveryOS (another partition), and revive/restore via Apple Configurator via another Mac, as I explain in the next section.

Put another way, the only time you would encounter this problem is if you had set up a bootable external drive and your M1 Mac’s internal drive became so damaged (at a hardware level, likely) that you would need an entire motherboard replacement.

What’s going on at a relatively low level of macOS that makes this possible—even necessary? The nitty-gritty follows.

Apple Silicon Puts Security Policies on the SSD

I learned about this limitation while researching my book Take Control of Your M-Series Mac, during which I dug into the Apple Platform Security guide, which was published in February 2021 (and updated this month). Plus, I had read Howard Oakley’s article “M1 Macs radically change boot and recovery,” which interpreted some of the obscure aspects of new boot policy for M1-based Macs. Howard and I apparently alerted Mike Bombich to this in a Twitter thread—it’s such a new idea, even he took some convincing!

As Howard notes in his article, Apple introduced the notion of the 1 True Recovery (1TR) partition with M1-based Macs. This additional partition, separate from a Big Sur startup volume group, holds the code and data that controls boot-time behavior. On Intel-based Macs, firmware serves this role.

One way 1TR differs from the firmware on Intel-based Macs is that the 1TR partition stores your decisions about startup security policies, the directives you set in the Startup Security Utility available in recoveryOS. You can set a separate policy for each external volume you allow to boot your Mac, but that policy is stored only on the internal drive in the 1TR partition. This technique prevents manipulation and trickery if you opt to vary from the highest level of security available, which is the default mode.

This reliance on 1TR is also why setting up an external bootable volume on an M1-based Mac sends you through a two-step process the first time you boot from it. After you select a volume on the external drive in the Startup Disk preference pane or through the recoveryOS startup process, your Mac restarts and makes you authenticate again. From then on, you can restart directly from that external volume. Because it only happens the first time, people often think it’s an error rather than an intentional process. Here’s what’s happening.

The first step in recoveryOS invokes user authentication to validate the new security policy that will allow that volume to start up the Mac, which it then writes to the 1TR partition. But because the policy hasn’t yet been read from the 1TR partition (which is necessary to know that it’s valid), a second restart happens so that 1TR can read that policy during the boot process and validate that the external volume can be used as the system startup volume.

You can encounter trouble if you erase the internal SSD. If you erase all the partitions, including 1TR, you won’t be able to boot from an external drive. However, if you haven’t erased all the partitions, you can reinstall macOS in one of two ways:

  • Use recoveryOS: Shut down your Mac. Then press the power button for 10 seconds and release it only after the startup options window appears. Click Options, authenticate, and reinstall macOS. If that fails…
  • Use fallback recoveryOS: Apple added a second recovery partition to macOS for M1-based Macs in case something happens to the main recoveryOS partition. Fallback recoveryOS should start up automatically when the main recoveryOS fails. But you can also trigger it manually: Shut down your Mac. Instead of pressing and holding the power button, press the power button twice in succession, holding it down the second time for 10 seconds until the startup options window appears. With fallback recoveryOS, volume policies aren’t loaded. However, it does let you reinstall macOS, and it silently repairs the main recoveryOS. After reinstalling macOS, you can restart and get back to normal. (In fact, if the main recoveryOS has failed, Apple promotes the fallback recoveryOS to become the main recoveryOS and installs a new fallback recoveryOS in its place. If your head is spinning, join the club.)

If recoveryOS can’t be used, you have to use the revive or restore firmware processes, which require the free Apple Configurator app, a particular cable depending on which M1-based Mac you have, and a second Mac. Apple describes the process in extreme depth. The firmware involved here is the Secure Enclave Process’s operating system (sepOS), which manages what Apple calls the Secure Boot process, involving elements described above. (You’ve probably never heard of sepOS before, but it’s a thing.)

If the revive or restore process fails, that’s likely an indication of a significant hardware failure. Your Mac will need to be serviced, and Apple might replace either the motherboard or the entire computer.