OT: Locking Firmware Repercussions

damienbarrett
Valued Contributor

We're currently trying to decide whether to lock the firmware on our next round of equipment arriving in a few months (2012 MacBook Airs).

In our program, we allow our end-users to be administrators of their Macs, and one of the expectations is that they will keep their OS up to date (but not upgrade to the next major version). Part of this expectation is that they install any firmware updates that come down the pipe from Apple. Of course, this begs the question:

If we firmware lock our 2012 MacBook Airs with a password that only the Tech Dept. knows, and a firmware update is released by Apple, will the firmware password prevent our end-users from updating the firmware?

I've queried our Apple SE but he hasn't gotten a concrete answer yet. I'm hoping someone in this community knows the answer to this.

[The primary reason we want to lock the firmware is to prevent our end-users from booting into the Recovery Partition and resetting our hidden user's password, or granting themselves admin access if they've lost it due to AUP violations. I also like that by locking the firmware, it prevents a thief from easily wiping the machine prior to resale, and it'll keep our branding and contact info on the login window intact].

3 ACCEPTED SOLUTIONS

dmohs
Contributor

Our school uses firmware passwords. It has not hindered any firmware updates.

We have successfully installed firmware updates via both (1) administrators using Software Update and (2) non-admins installing firmware updates via Self Service.

View solution in original post

dbraunschweiger
New Contributor II

I can confirm that standard end users can update their firmware without knowing the firmware password, using self service. Our students do it on their 1-to-1 laptops in our district.

View solution in original post

mm2270
Legendary Contributor III

Same here. I have no idea what those Apple engineers are talking about. I hate to say it, but from my perspective they're wrong. I know for a fact I installed a Firmware update recently on a MacBook Pro test machine I have here. On reboot, the firmware update applied without needing to enter the Firmware password, it then rebooted back into the OS.

There are two FW password modes -"Command" and "Full". Command, which only requires entering the password when trying to use the boot selector, is what I think we''re all referring to and use. Full makes the Mac boot up into a screen where the pw must be entered to continue the boot process. Are the engineers perhaps thinking of the latter?

View solution in original post

8 REPLIES 8

mm2270
Legendary Contributor III

We also have firmware passwords on all managed Macs, for many of the same reasons as you. Our users have local admin rights on their Macs, but we don't want them setting up and using BootCamp partitions, or messing with the OS in Recovery HD. (As an aside, we would love to give users the ability to use a temporary firmware password with very limited rights that they could use to do basic Disk Utility repairs from Recovery HD. So much so that we've been requisitioning Apple to come up with something along those lines. Right now anyone with the FW password can remove it, reset it to something else, run any command line tools from Recovery HD and a ton of other things. Too wide open)
As far as I have been able to determine, installing firmware updates via Software Update/App Store seems to work fine and is not hindered by having that password in place. I believe it only affects the boot options. Since FW updates get installed while booted into the OS, it shouldn't present an issue.

dmohs
Contributor

Our school uses firmware passwords. It has not hindered any firmware updates.

We have successfully installed firmware updates via both (1) administrators using Software Update and (2) non-admins installing firmware updates via Self Service.

damienbarrett
Valued Contributor

I hate to resurrect an old thread that I thought I had an answer to, but I heard back from my Apple SE today and his contacts in Apple Engineering insist that a firmware password must be known in order to apply an firmware update. This is counter to what almost everyone else has been saying.

dmohs, can you confirm again that your end-users are able to update firmware without knowing the firmware passwords? Even on newer 2012 Macs?

dbraunschweiger
New Contributor II

I can confirm that standard end users can update their firmware without knowing the firmware password, using self service. Our students do it on their 1-to-1 laptops in our district.

mm2270
Legendary Contributor III

Same here. I have no idea what those Apple engineers are talking about. I hate to say it, but from my perspective they're wrong. I know for a fact I installed a Firmware update recently on a MacBook Pro test machine I have here. On reboot, the firmware update applied without needing to enter the Firmware password, it then rebooted back into the OS.

There are two FW password modes -"Command" and "Full". Command, which only requires entering the password when trying to use the boot selector, is what I think we''re all referring to and use. Full makes the Mac boot up into a screen where the pw must be entered to continue the boot process. Are the engineers perhaps thinking of the latter?

acdesigntech
Contributor II

i sincerely hope they are. We've been locking our Macs with a firmware password for over 2 years now and have never had an issue doing firmware updates without the password.

franton
Valued Contributor III

deleted post as I hadn't read the replies properly

dmohs
Contributor

I will also again affirm, I use firmware passwords. I have made firmware updates available via Self Service. The process has worked well for me. Using the student's non-admin accounts, we successfully installed the firmware updates on our MacBook Airs (mid 2011) and MacBook Airs (mid 2012). At no point in the process were we prompted for passwords, and we did confirm that indeed the update was installed.

The process went well. Though, I had about a dozen machines that seemed to ignore the update on the first round. However, when we tried a second time, it was successful.