macOS 13.2.x and Recovery, A Sad Tale

TL:DR; Apple’s latest updates to macOS Ventura can lead to your FileVault-encrypted Mac booting into Recovery, and, potentially, prompts to enter one or more of:

1. Recovery Lock* password, if enabled, on Apple Silicon, or EFI/firmware password, if enabled, on Intel:

2. User account password (if there’s an admin user on the system)

3. FileVault Personal Recovery Key (if primary user is not an admin)

Once these dialogs are dismissed, the Mac should reboot and properly complete the OS update.

This behavior is occurring primarily on Apple Silicon Macs, but also reportedly affecting Intel Macs as well, all updating from a previous version of macOS 13 Ventura to either 13.2 or 13.2.1. It does not seem to be affecting upgrades to macOS Ventura from previous OSes. And it does require FileVault to be enabled.

This is happening not just to corporately-owned systems in Apple Business Manager, enrolled in an MDM, it’s also happening to home users. It does not seem to depend upon a particular MDM or security software vendor, or prestage enrollment settings.

So what’s going on here, and how can you prevent it from affecting you/your users?

As far as what’s happening, without having intimate knowledge (and logs/bug reports), it’s difficult to say exactly, but it seems to revolve around a failure to perform something like an authenticated restart (i.e. restart and unlock the encrypted boot drive without prompting the user). When this fails, macOS falls back to boot to Recovery for authentication/disk unlock.

(It’s also possible/maybe even likely that there are multiple paths that lead to Macs booting into Recovery during an OS update, but, since the symptoms are consistent, everything gets lumped into one issue).

Apple does not make public statements about bugs/issues. Privately, they’ve indicated that they’re aware of this situation, and have asked for further details (some diagnostic steps below). For now, the recommended workaround is to:

1. Restart your Mac
2. Within 30 minutes of restarting, install the update(s)

Further troubleshooting:
If you have an AppleCare Enterprise service agreement, or access to AppleSeed for IT, and are able to get hands-on to a system experiencing this, along with external media of some kind, please do the following:

1. When booted into Recovery (after entering any Recovery Lock or EFI/firmware password), before entering credentials, press: Shift-Control-Option-Command-<period> — the screen will flash, and a recoverydiagnose process should start — and you should be prompted for where you want to save it. This is where your external media is necessary.
2. After saving the recoverydiagnose, enter credentials, either for an admin user, or the FileVault Personal Recovery Key, and then the Mac should restart and finish the update.
3. After logging back in, run a sudo sysdiagnose and save that alongside the recoverydiagnose
4. Open an AppleCare Enterprise ticket on the issue, and, when provided a link, attach both the recoverydiagnose and sysdiagnose files to the ticket.
5. If you don’t have AppleCare Enterprise, please file feedback using Feedback Assistant (found on every Mac), ensuring that you submit this feedback from an Apple ID associated with your Apple Business Manager or Apple School Manager account.

• * Recovery Lock, much like the EFI/firmware password on an Intel Mac, is an optional enterprise feature (which means consumers should never see this) for Apple Silicon Macs that prevents users from booting into Recovery without entering a device-specific password. This is a 40-character numeric password, typically escrowed in your MDM. For Jamf Pro, it’s located in the Inventory tab, under Security — you should see a button to reveal the Recovery Lock Password, which you can provide to the user.
• At least in the case of Jamf Pro, for devices enrolled with Recovery Lock, and not enabled after enrollment, once the Recovery Lock password is revealed, it is rotated the next time the device communicates with Jamf.
• EFI/firmware passwords on Intel Macs are typically static passwords, which most MDMs do not escrow, and there’s no native mechanism to rotate them upon use.