Best Practice for Firmware Password

On Intel Mac's there is no solution to this.
Its been a big pain-point made bigger with the new normal of remote working, where a user doesn't often have access to a local IT Service desk to help resurrect.
If you need to protect the security issues that accessing firmware can bring you have to put up with this inconvenience to the users.

With the release of AppleSilicon this decision was taken out of our hands as Apple removed firmware passwords altogether; great for users as they can now enter recovery mode to reset their password or re-install in the event of a issue, but left a gaping security issue that anyone with secure token to unlock FV on the device could also boot in to recovery mode to change security levels for SIP etc..
However with the release of macOS 12 Monterey this will be resolved for AppleSilicon as you can control and manage which accounts on the device can modify security settings.
This will allow the local FV user to go into recovery mode in case of an emergency but not allow them to tamper with the security levels which was the main reason for having a firmware password on devices.

Just raising my hand here to mention that we've had the same issue. I have 3 Macs currently all the way with a team in India where they got locked at a firmware password screen, all for different reasons, but the end result is the same. The Macs are now bricks for them until we figure out a solution. What's astonishing and completely frustrating to me is that it's not possible to get a Mac out of that state, save for actually entering the darn firmware password. I've tried everything I can think of and have researched this and haven't found a solution. Once they machine is directed to boot to Recovery they are stuck in that state until it completes that task. Ridiculous, but that's how it works apparently.

So yes, this is a huge pain. Our security posture requires that we apply the firmware password to prevent someone (not authorized) from booting into Recovery to do anything with the device. We have FV2 enabled too, but the FW password adds an extra layer of security that makes our InfoSec people feel happy.

I wish I had some advice or some expert solution around this, but sadly, this is one of those things that you have to deal with when using a firmware password. We're not on Apple Silicon Macs yet, so for now the future Monterey solution mentioned above won't help us. But someday I suppose it will.

Just my $0.02, but if folks are remote, then they should probably have the ability to wipe and re-install macOS on their device in a worst-case scenario to minimize downtime.  If your devices are configured for automated device enrollment, authenticated enrollment, and policies/profiles all get re-applied when re-enrolled, what's the harm?

When a user screws up their system and has to nuke & pave, especially if they lose data, perhaps that will incentivize them to not screw up their system again in the future.

The harm is that with not having a firmware password to access to recovery mode any user can also change security options in the firmware, it is possible to remote boot to non-authorised volumes to try access data on the SSD or to reduce the level of security (i.e SIP) which could allow the devices data to be compromised even if using FileVault
Theoretically if you have access to firmware, a key logger thats side injected at firmware level would be undetectable by the OS and bypass any security tool; As this is all done at firmware level its well before ADE (DEP) even comes into play.

Unfortunately for many government and financial institutions the firmware password is mandatory requirement to even   to be able for use a macOS device as your end use device.
Our InfoSec team will be happy to shift the firmware password requirement to another solution that serves the same outcome is available, so once macOS 12 Monterey is released and we have the new ability manage recovery mode access via MDM, then we can allow AppleSilicon based devices to be used within the business without the need of a firmware password and solve both of these issues for good.

thanks for your input. Security is important but corona and home office is pain in the ass when users regularly are booting in firmware mode because of shutting down the macbook on login screen or what else they are doing. 😞

what do you think of the idea if you split the macbooks into several smart groups and each smartgroup gets its own firmware password. if someone from a group who is in the home office needs the password, we give it out and then change it for the group. Several passwords have to be documented and we have a little more effort, but users from the home office no longer have to send the devices in or come to the office.

If you haven't tried it yet I had a machine where we forgot the firmware password the departed user set and since we didn't care what was on the machine we were able to use Apple Configurator 2 to reset the machine and reinstall the OS. The options are under the advanced submenu, and it take a little work to get there, but it will work. Or had for us a few times.