Notes on Activation Lock: Apple Silicon Management Challenges

Apple silicon has made Mac exciting again. Exciting for consumers who can run most everyday tasks at near ludicrous speed. Exciting for IT admins as the rules for managing this new Mac era shift around them. There’s a new normal, and what worked with Intel Macs might not work on Apple silicon. In this post we’ll look at what’s changed with Activation Lock. The good, the bad, and what’s actually true.

Apple Has Altered the Deal

EFI (Extensible Firmware Interface) no longer exists on Apple silicon and along with it has gone EFI passwords. In the past, EFI passwords secured recovery and prevented Macs from using most boot modifiers at startup. A user couldn’t enter recovery, do a PRAM reset, enter target disk mode or perform a whole host of other useful functions without first entering a password. The most commonly used phrase on Apple’s Mac startup key combinations article is “Disabled when using a firmware password.” From an IT admin’s perspective this is exactly the desired behavior, which is why it surprised some when Apple published a note in mid-December to their firmware password support page describing firmware passwords in regard to Apple silicon.

This feature requires a Mac with an Intel processor. For the equivalent level of security on a Mac with Apple silicon, simply turn on FileVault.

This feature, a firmware password, does not exist on Apple silicon, and furthermore, enabling FileVault provides exactly the same level of security as on a T2 chip Intel Mac. Here are a few ways in which that’s not true.

1. Apple silicon Macs can enter safe mode without authentication.
2. Apple silicon Macs can start diagnostics without authentication. Maybe a benefit more than a hindrance.
3. Apple silicon Macs can get to Boot Picker with authentication. Once at Boot Picker any user can enter Recovery Assistant, at which point they can go to Recovery Assistant > Erase Mac… resulting in data loss. This is true even on a Mac encrypted with FileVault.

Minor differences until point number three. To emphasize, anyone with physical access can to erase the disk, with or without FileVault. Sure, they can’t boot to recoveryOS without entering a FileVault user’s password first, but the erase option exists before authentication. A user not following meaningful backup practices could easily find themselves in a situation resulting in data loss. I do see how Apple feels they mostly covered their bases. With FileVault enabled the data is still secure from prying eyes. It’s not necessarily the data I’m worried about though. Since Macs don’t need to be connected to a network to complete Setup Assistant, it’s trivial to ignore MDM enrollment and as a result bypass enterprise policy altogether. Consider this workflow, and please excuse my low quality iPhone picture of a screen.

1. Hold the power button at startup to get to Boot Picker and select Options to load Recovery Assistant.
2. Select Recovery Assistant > Erase Disk…
3. The disk is erased, Mac reboots, and goes through activation.
4. All recoveryOS utilities are now available. Select Reinstall macOS and click through the prompts.
5. At Setup Assistant, before clicking through any screens, disconnect from available networks and restart.
6. Continue through Setup Assistant without ever getting to the Remote Management screen or enrolling in MDM. Click through regular Setup Assistant screens, create a local admin account, and land at the desktop.

Anyone with physical access to an Apple silicon Mac can go from fully managed and enrolled in MDM, to unmanaged with admin access in about 1-2 hours. Many businesses might not find this all that impactful of a statement when they have HR and other operational policies to back them up. And others might hand wave it aside because of course physical access means the system is compromised. And of course disk encryption alone doesn’t protect against data loss. Consider the possibilities though in a tightly controlled environment or school setting. All that painstaking work putting together policy to ensure Macs are configured to meet organizational needs can’t be enforced. EFI passwords can’t save us anymore.

Pray They Don’t Alter It Any Further

What’s a Mac admin to do? Activation Lock. In consumer Apple world Activation Lock is tied to Find My. You’re probably already used to it on iPhone as most personal devices have Find My enabled, and as a result Activation Lock comes along by default.

When an iPhone, iPad, or Apple silicon Mac are erased they must go through activation as part of the setup process. If an Apple ID is tied to the device, during activation an authentication screen like the one above will pop up before continuing. In this way a device is protected against loss or theft. However, in our large iPad deployment we’ve done our best to avoid Activation Lock altogether because it introduces too many challenges in a managed environment. A user would sign in with their Apple ID, enable Find My, and the device would have Activation Lock enabled. When setting the same iPad up for another user the Activation Lock screen would appear, and we were stuck without their Apple ID or password. Only by request through Apple could the lock be removed. More recently Apple has given us a few useful tools in the battle against Activation Lock. It’s now possible to prevent users from enabling Activation Lock and to clear it entirely through MDM. Jamf Pro has the feature right in its prestage (enrollment) settings. MDM can also escrow a 25 character bypass code to be entered in the password field, removing the requirement to know the original Apple ID used.

Avoiding Activation Lock works well on iOS/iPadOS because during Setup Assistant a network connection is required to complete setup. A user can’t bypass the Remote Management screen to avoid MDM enrollment. On Mac though, Apple continues to cater to a small subset of customers who want or need offline setup. The result is a setup workflow where MDM enrollment is easy to get around. That’s why Activation Lock becomes important in securing Apple silicon Macs. Refer back to the erase workflow from earlier. During step three, when activation occurs, an Apple silicon Mac would get to the same Activation Lock screen as an iOS device. To continue on the user is required to enter Apple ID credentials, MDM supplied bypass code, or an admin password. A bad actor wouldn’t be able to continue through Setup Assistant. They’d be stuck at activation. Think of it as security feature taking the place of EFI. In a way it’s moving what would be the EFI password further down along the provisioning workflow, and, right now at least, it’s our only option.

Enabling Activation Lock on Mac isn’t perfect. In a K12 school environment it opens up other possibilities - bullying, a friend playing a prank, or students being intentionally avoidant. There’s still no safeguard in place for when a student to erases another student’s Mac. Schoolwork or other important personal data could be lost, which in turn can have a significant impact on their ability to participate in school. An erased drive also requires the Mac be provisioned again. With Activation Lock enabled the student wouldn’t be able get past activation as they wouldn’t know an admin password, Apple ID credentials, or bypass code. IT would then need to step in to help. If this occurred outside school hours, or at a distance, it could be a long time before the student had access again to a functional computer.

Apple Silicon Activation Lock Scenarios

I tested a variety of workflows with Activation Lock enabled to see just what to expect.

1. Boot to recoveryOS, erase the disk, and get to activation lock. At the Activation Lock screen continue with activation using either Apple ID credentials, MDM bypass code, or a previously used admin password.
2. Send a MDM lock command. Choose Recovery Assistant > Erase Mac… after reboot. Reboots to the Activate Mac screen. Enter Apple ID credentials, MDM bypass code, or admin password. Afterward I’m able to get to recovery tools and reinstall the OS.
3. Send a MDM erase command. Mac reboots to erase the disk. In my test there was an error “Failed to create activation request.” After another reboot the Mac got to the Activate Mac screen. Enter Apple ID credentials, MDM bypass code, or admin password to continue.
4. Boot the Mac to DFU and restore using an IPSW. Disk is wiped, macOS reinstalled. At first boot the Activation Lock screen comes up. Enter Apple ID credentials, MDM bypass code, or admin password. Mac boots to Setup Assistant.
5. Erase the drive and reinstall Big Sur using using startosinstall with --eraseinstall. Activation lock screen never comes into play. Mac boots back to Setup Sssistant after reinstalling the OS. Activation lock stays enabled as the Mac either didn’t need to go through activation again, or activation was treated differently as a result of using startosinstall.

It turns out startosinstall is the exception to the rule. When using startosinstall the Mac returned directly to Setup Assistant and was able to continue on without prompting for activation. When targeting rapid return to service this is the best option. Since many organizations already build their workflows around startosinstall this is a nice outcome. Hopefully it’s not simply an oversight to be changed later.

MDM Support for macOS Activation Lock

I’ll admit, Maybe I’ve buried the lede. Activation Lock would work well as an enterprise alternative to EFI passwords except for the fact MDM can’t enable it on Mac. There’s been some confusion around what the MDM spec supports. Apple makes no reference to macOS on their developer documentation - Activation Lock a Device.

Find My iPhone Activation Lock is a feature of iCloud that makes it harder for anyone to use or resell a lost or stolen iOS device that has been enrolled in a Device Enrollment Program (DEP).

https://developer.apple.com/documentation/devicemanagement/activation_lock_a_device

When talking through securing Apple silicon Macs with AppleCare enterprise support they recommended enabling Activation Lock, but were not sure it was possible through MDM. Well, if nobody seems to know, the answer is most likely simple. No. Further confirmation in the Mobile Device Management Settings documentation shows MDM can only allow or disallow Activation Lock on macOS. That is, MDM can prevent someone from enabling Activation Lock when they sign in with an Apple ID. MDM can’t enable Activation Lock itself.

The table Apple provides does a good job explaining what’s currently possible, but here’s my take too.

Apple is making a recommendation MDM vendors can’t implement because the MDM spec doesn’t support it. Jamf even updated their macOS Activation Lock feature request with a note saying as much.

Update, January 2021: Please note that Apple’s documentation specifically only describes Activation Lock Enable functionality for mobile devices, and continues only to describe Allow or Prevent for macOS devices. We believe this to be an accurate reflection of Apple’s supported workflows, but we’re monitoring for any changes.

https://www.jamf.com/jamf-nation/feature-requests/8673/macos-10-15-activation-lock-bypass

Editorial

Apple has some work to do. In the end, it sounds like AppleCare enterprise support responded by doing their best to recommend a solution to a problem created by a new implementation not taking into account the needs of many enterprise customers. It wouldn’t be the first time Apple has missed the mark in this way. Whether they will continue recommending Activation Lock or come up with a new solution is yet to be seen. Here are a few ideas I brainstormed while researching the problem.

• Move the Recovery Assistant > Erase Mac… option behind user authentication or FileVault recovery key.
• Allow MDM to set a password or bypass code for the Erase Mac… function on supervised Macs. This would mean consumer Macs continue to have access to the function to ensure they can erase the disk as necessary, but institutionally owned Macs are protected.
• Allow MDM to set a password or bypass code to get to Boot Picker or Recovery Assistant altogether. As in, bring back the EFI password.
• Require Macs to be connected to a network to complete Setup Assistant.

File feedback with the usual Apple channels and let your concerns be known. Through my open cases I’ve already been told there will some sort of response by engineering, but what that is and when is unknown. The open question is always, “When there is a solution, will it meet my organization’s needs?” As it stands today, Apple silicon Macs have significant management challenges in enterprise and education.