Protecting M1 with no more EFI security available

You can’t. File feedback with Apple.

Is your concern about students breaking the machine? You should have ASM with automated device enrollment so if a student does mess up their computer, they don’t need IT to touch the Mac to restore it to working order. There should be a clear procedure in place to help a student (re)gain access to their student files and accounts.

Also, you need to have a discussion with school / district administration about clear policies and guidelines around student behavioral expectations with technology. If they mess up their Mac in a way that requires IT intervention, there need to be consequences.

Definitely file a ticket with your Apple Rep. if you have one. I've brought this up to ours as a huge concern for our company. If you don't have an Apple Rep., then definitely find a feedback channel.

I understand the thinking about allowing ASM and Jamf to set everything back up but the bigger issue is that there is no block to access Recovery and a student can reset all user passwords, including our admin account, from Recovery.

It was very frustrating to see this functionality removed. I've been in nearly constant communication with our Apple SE and this is what I have heard back

"There is a critical feature request created and the use case is understood. No timeline given. The best way to triangulate would be to keep engaged in the AppleSeed program. This would allow you to provide additional feedback as well as monitor changes as OS updates come out."

Here's to hoping it will be sooner than later (hah).

Have any updates on this issue? We are in the exact same boat, I just want to 100% prevent students from running any startup options other than boot to Macintosh HD. Really disliking the M1 and Big Sur changes, wish Apple would just get to the punch and turn Macs into iPads with keyboard and give them all the same MDM controls.

Not a 'fix' but some suggestions to mitigate maybe...
We're using ABM (biz vs. school, but the same thing basically) and Prestage enrollment. On enrollment the management account is created, and you can have an additional account created automatically. We set a local support admin account. Then prestage enrollment is setup to prompt for the details for an additional new user (you can require that this new user is a standard account). If you're not the intended user for the machine (i.e. the student) or if it's going to be a spare or something else not assigned to a specific student you can either create a generic account or quit (cmd-Q) at this screen it'll take you to the log in screen and you can log in with the support account you created to do whatever else you want/need.

You can make a policy that runs at whatever frequency you want that'll reset the support account's password. So if a student changed it it'll get reset. I've even got a script that runs at login (via Outset) that'll create our support account and our generic non-admin user account if they don't exist already. Great if a nosey user deleted them.

I hope they return the EFI password though. It's an additional layer of security that's relatively easy to add and manage, and not very intrusive for support or users.

I would argue that the EFI password isn't necessary for an item that shouldn't be supporting dual boot anyway. If you have someone hacking linux onto a mac, you have larger issues to solve. Additionally, asking for a feature to password protect or lock someone out of DFU mode will lead to permanently bricked devices. It's time to start thinking of the Mac more like an iPad.

It's time to start thinking of the Mac more like an iPad

iPads have Lost Mode and you cannot bypass DEP/ADE during setup. On M1 Macs there's nothing stopping someone from wiping it and reinstalling macOS, then using it free and clear from there on, completely unmanaged. I'd be happy to think of it more like an iPad if Apple ported over these iPad security features (though I'm sure making setup strictly require internet access on Macs like it does on iPads would be controversial).

Intel Macs have one solution to this problem, and iPads have another. I'm not married to one particular solution, but right now we have no solution at all on M1 Macs and that's not okay.

If you enable FileVault on your devices (which, in my humble opinion, you should be doing), this essentially becomes a moot point. User will be prompted for the recovery key as soon as the device boots into Recovery Mode.

User will be prompted for the recovery key as soon as the device boots into Recovery Mode

You only need to enter a key/password if you want to mount the disk. If you simply want to erase the Mac and reinstall macOS, you only need to go to the "Recovery Assistant" menu and select "Erase Mac", which does not require a key/password since it does not unlock the disk. This is true both on Intel and Apple Silicon Macs.

You could also use DFU mode to erase it with the help of a second Mac running Apple Configurator. Again, no password or recovery key is required because it simply nukes everything.

And that's a good thing, IMHO, because that's really not what FileVault is for. FileVault is for data security, not theft deterrence or hardware lockdown.

If you simply want to erase the Mac and reinstall macOS, you only need to go to the "Recovery Assistant" menu and select "Erase Mac", which does not require a key/password since it does not unlock the disk. This is true both on Intel and Apple Silicon Macs.

At that point you can hold an employee or student accountable for doing that. But it's true, having an EFI password set eliminates that possibility.

Intel Macs have one solution to this problem, and iPads have another. I'm not married to one particular solution, but right now we have no solution at all on M1 Macs and that's not okay.

Exactly my point - we have deployed millions in hardware to high school students over the past several years (previous FF MBA) and the only issue I ever dealt with was physical breakage and theft (and I could track that). Now we are looking at deploying M1 MBA to thousands of students who will be able to reset their device, potentially creating legal issues like no filtering (CIPA)!

Got some feedback from Apple that they should be releasing a patch before macOS 12 drops which will resolve this issue! No specifics yet, but it will prevent standard users from accessing recovery, although DFU would still be possible.

As @cwaldrip said if the device is scoped properly to a prestage a student can't reset it and just use it free of management. If they wipe the device, it boots right back to the remote management screen during OS setup and the whole process starts over. I wouldn't count on EFI ever coming back.

Except you can just pick go nog connect to WiFi at the setup assistant and now you’re management free.

The SE's I've spoken with said this is a huge piece of feed back and think some good news maybe coming soon. The best way to give the feedback to Apple these days is to become part of the Apple Seed program. It's available to anyone with a ASM or ABM login. Once in, the feedback from the seed program is apparently streamlined to go directly to the developer group responsible for what item you are writing about.

The best way to get Apple's attention on a feedback item is to realistically say that because of issue "X", we may be unable to purchase "Y". If the issue impacts companies or schools spending money with Apple, they will prioritize it a bit more from what I understand.

Gabe Shackney
Princeton Public Schools

@boberito, except for the persistent notification you'll get about approving the MDM profile because the machine is trying to get managed. I'm sure some folks can overlook it though.

I'm going to guess this won't be available until macOS 12, and we'll all be testing the hell out of it in July. I don't expect it until beta 4-6, which is when they start adding the new management features.

As of macOS 11.5 Apple have introduced Recovery Lock via MDM on Apple Silicon devices: https://developer.apple.com/documentation/devicemanagement/set_recovery_lock_command

As of JSS 10.32 Jamf have implemented this in the form of a PreStage Enrollment option - however they are currently recommending not to use it due to the possibility of it being enabled before the first user account is created:

PI-010133: It is not recommended to set a Recovery Lock Password using a PreStage Enrollment at this time.

Jamf has become aware of an issue where if a Recovery Lock Password is set before the first computer user account is created (such as when configured within a PreStage Enrollment), macOS will not give any users the cryptographic privileges needed as a “volume owner” for computers with Apple silicon.

Volume owner privileges are required for users to perform a number of security-sensitive actions on computers with Apple silicon, including the ability to install software updates.

At this time, the only known resolution to affected computers with no volume owner users is to erase and reinstall macOS.

An option to use this feature now could be to use a script to send the MDM command via API call...