UEFI Setup Passwords Explained: Supervisor, Power-On and Fleet Lockdown

A UEFI setup password, usually called the supervisor or administrator password, stops anyone without it from changing firmware settings such as boot order, external boot, Secure Boot keys and TPM state. A power-on password must be typed before the machine boots at all. On a fleet, give each device a unique supervisor password or use signed, certificate based settings, keep every credential in a vault, and record each device's recovery path before it goes back for repair.

This post goes one level below our posts on SPI flash write protection, enrolling your own Secure Boot keys and securing an IP-KVM's remote BIOS access. Those cover how the flash chip is locked, how keys are enrolled and how remote consoles reach the setup screen. Here we stay on the credentials that guard the setup screen itself, and on how organizations manage those credentials across hundreds or thousands of laptops and desktops.

Key takeaways

• There are four common families of firmware credential: the supervisor (admin) password, the power-on (user or system) password, a delegated system management password on some platforms, and drive passwords that lock the storage device itself.
• The supervisor password protects configuration, not code. It gates Secure Boot mode and keys, boot order and external boot, TPM controls, virtualization and DMA protection settings, and the other password types.
• It does not stop someone who reprograms the flash chip directly, a platform with missing SPI write protection, or an attacker who simply boots another operating system because external boot was left on.
• On current business laptops the password is not something a coin cell removal clears. One major PC maker's current user guide says plainly that for a forgotten supervisor password "there is no service procedure", and the fix is a system board replacement at the owner's cost.
• Intel-based Macs use a firmware password; Macs with Apple silicon do not need or support one, because the platform security guide says critical changes are already gated behind recoveryOS and user authentication.
• At scale you have three options: a scripted password managed through each maker's WMI or command line tool, certificate based authentication where the firmware verifies signed setting payloads, or Microsoft's Device Firmware Configuration Interface (DFCI) through Intune, which uses public key cryptography and does not depend on a local password.
• NIST SP 800-147 already asked organizations in 2011 to put "organization policies for password policy and device boot order" into a configuration baseline, and to delete passwords from firmware before disposal. NIST SP 800-193 frames firmware and its configuration data in terms of protection, detection and recovery.

Timeline: the documents behind firmware setup credentials

What kinds of firmware passwords exist

Firmware menus use different names for similar things, so it helps to sort them by what they gate rather than what they are called.

Supervisor or administrator password

This is the setup password. When it is set, entering the firmware menu either requires it, or lets you in read only. One major PC maker's user guide describes it this way: the supervisor password "protects the system information stored in UEFI BIOS", and if you skip the prompt you can look but "cannot change most of the system configuration options". The Linux kernel's documentation for the firmware-attributes class uses the role name bios-admin and describes it as "used for preventing modification to the BIOS settings". It also notes that on the laptops of the three makers it covers, once the admin password is set "all BIOS attributes require password validation", so even scripted changes from the running operating system need it.

The supervisor password usually also controls the other passwords. In the same user guide, if both supervisor and power-on passwords are set, the supervisor password overrides the power-on password, and a forgotten power-on password can be cleared by someone who knows the supervisor password.

Power-on, user or system password

This password is asked for at boot, before any operating system starts. The kernel documentation calls the role power-on and describes a "System" password as one that "is required to boot a machine". It is a weak substitute for disk encryption: it stops casual use of the device, but it protects nothing once the storage is removed, and the same user guide notes that you are not prompted for any firmware password when the computer resumes from sleep. Most fleets with full disk encryption leave it unset and rely on encryption with a pre-boot or TPM based unlock instead, which our post on TPM only versus TPM with PIN discusses.

System management password

Some platforms add a third, delegated password. One maker's guide describes a system management password that "can also protect the system information stored in UEFI BIOS like a supervisor password, but it has lower authority by default", and that an administrator can raise its authority for security related features through an access control policy in the firmware menu. The kernel exposes this as the system-mgmt role. The use case is separation of duties: the help desk gets a credential that can change boot order for reimaging, while only a smaller group holds the supervisor password that controls Secure Boot and the passwords themselves.

Drive passwords

Drive passwords are set by firmware but enforced by the storage device. On SATA devices this is the ATA security feature set; on NVMe drives makers expose a comparable lock. The kernel documentation lists HDD and NVMe roles with a level of user or master, and explains that "if a master password is set a user password is required". One maker's guide describes a single password mode, and a dual mode in which an administrator holds an admin drive password and assigns a user drive password per computer.

The critical difference is recovery. The same guide states that if you forget the drive password (or both passwords in dual mode), the maker "cannot reset your passwords or recover data from the storage drive", and the drive has to be replaced. The guide also notes that the drive password option is not available when a self encrypting drive is managed by a TCG Opal management program, so the two schemes do not stack on the same device.

Where firmware passwords are stored, and why the battery trick is mostly gone

On older desktops, firmware settings lived in a small block of battery backed CMOS RAM next to the real time clock, and some boards had a jumper to clear passwords. On current business laptops, credentials are kept in non-volatile storage that the firmware protects, so removing the coin cell resets the clock and perhaps some settings, but not the supervisor password.

The clearest evidence is what makers tell their own customers. One major PC maker's current user guides say that for a forgotten supervisor password "there is no service procedure to remove the password" and that an authorized provider has to replace the system board, for a fee. The same guides warn that repairs caused by forgotten passwords are not covered under warranty. The Mac platform security guide describes a similar position for Intel-based Macs whose owners choose to disable the reset capability: they must accept "the cost of the logic board replacement" if they forget it.

Behavior varies by maker, product line and generation. Consumer boards and some desktops still offer a clear jumper or a service reset. Check your model's service manual before you rely on either assumption, and treat "the battery will clear it" as false until the manual says otherwise.

What a setup password protects

A setup password is only as useful as the settings it guards. These are the ones that matter for security, and why an attacker with brief physical access would want to change them.

Secure Boot keys and mode

UEFI defines a small set of global variables that describe Secure Boot state. The EDK2 reference implementation's GlobalVariable.h defines SetupMode, SecureBoot and PK alongside the key databases. When the platform key is removed, the platform drops into Setup Mode and accepts new keys without the old owner's signature. Firmware menus offer exactly that option, usually labeled "reset to setup mode", "clear keys" or "restore factory keys". Our Secure Boot with your own keys post walks through enrolling PK, KEK and db deliberately. The supervisor password is what stops someone else from undoing it.

Some makers also restrict changes from the running operating system. One maker's WMI deployment guide lists Secure Boot and secure rollback prevention among the settings that "cannot be changed from Enable to Disable" through WMI, so even a script with the correct password cannot weaken them remotely.

Boot order and external boot

Most security controls you configure live on the installed operating system's disk: group policy, endpoint agents, local accounts. The Project Mu documentation for DFCI makes the point directly. It says this configuration "can be bypassed by the PCs default ability to boot other operating system instances via external media (e.g. USB), network (e.g. PXE), & alternate disk". Locking the boot order and turning off external and network boot is the single most useful thing a setup password does on a typical laptop. Our PXE and UEFI HTTP boot post covers when network boot is genuinely needed and how to secure it.

TPM state

Firmware menus can enable, disable or clear the TPM. Clearing it destroys the keys sealed to it, which will force a disk encryption recovery prompt and can break device identity used for management enrollment. Our TPM PCR explainer shows which measurements change when firmware settings change.

Virtualization, DMA protection and Thunderbolt

Windows Kernel DMA Protection uses the IOMMU to block external PCIe tunneling peripherals that lack DMA remapping capable drivers until a user signs in. Microsoft's documentation says enabling virtualization in firmware (the IOMMU) "is required to enable Kernel DMA Protection". It also answers the obvious follow up: Kernel DMA Protection "only protects against drive-by DMA attacks after the OS is loaded", and "it's the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt 3 ports during boot". Both the IOMMU switch and the pre-boot DMA settings live in the firmware menu, so an open menu lets someone quietly turn the protection off. Our USB and Thunderbolt DMA attacks post covers the history.

What a setup password does not protect against

A setup password is a lock on a menu. It is not a lock on the firmware chip, and it does not make a weak configuration strong.

Reprogramming the flash chip directly

Firmware and its settings live in SPI flash on the board. Anyone who opens the case can, in principle, attach a programmer to that chip. Whether that defeats the password depends on how the platform stores and verifies its settings, and on whether a hardware root of trust such as Boot Guard or Platform Secure Boot verifies the firmware image before it runs. Our hardware verified boot post explains those roots of trust. NIST SP 800-193 is the right lens here: it asks platforms for protection, detection and recovery of firmware "code and critical data", which includes configuration. A password helps protection of configuration through the menu. It does nothing for detection or recovery.

Missing SPI write protection

If the platform leaves its flash writable from the running operating system, a privileged process can change firmware or settings without ever seeing the password prompt. That is a firmware engineering problem, not a password problem. Our SPI flash write protection post shows how to check it. On Linux, fwupdmgr security reports the host security attributes fwupd checks, which on supported platforms include firmware protection settings.

Evil maid with external boot left on

The classic "evil maid" scenario is an attacker with a few minutes alone with a device. If external boot is still enabled, they do not need the setup password at all. They boot their own image from USB, and anything not protected by disk encryption is exposed. The password only helps if it guards a configuration that is already locked down.

Firmware vulnerabilities

A vulnerability in a firmware driver or in System Management Mode can bypass the menu entirely, so keeping firmware updated with rollback prevention enabled matters more than the password's strength. Our fwupd and LVFS post covers capsule updates on Linux.

How Macs differ

Macs split into two families with different answers.

Intel-based Macs: firmware password

The Mac platform security guide says that on Intel-based Macs the firmware password is designed to prevent "selecting alternate boot modes such as booting into recoveryOS or Single User Mode, booting from an unauthorized volume, or booting into target disk mode". It is set from the Firmware Password Utility in recoveryOS on Macs without a T2 chip, and from Startup Security Utility on Macs with a T2 chip. Advanced options, including a prompt at every boot, come from the firmwarepasswd command line tool.

The guide explains why this matters most on Intel Macs without a T2 chip: the password stops an attacker from booting recoveryOS, where they could otherwise turn off System Integrity Protection, and it stops them from running code from another operating system to attack peripheral firmware.

Recovery is designed in. The guide describes a reset path where the user gets a model specific string to give to the maker's support organization, which returns a signed resource that the firmware verifies before removing the password. Since macOS 10.15, firmwarepasswd has a -disable-reset-capability option for owners who want no one but themselves to be able to remove the password by software means. The guide is blunt about the cost: if that password is forgotten, the owner pays for a logic board replacement.

On T2 Macs, Startup Security Utility also sets the secure boot policy (Full, Medium or No Security) and, separately, whether the Mac may boot from external media at all. Changing these requires booting into recoveryOS and authenticating with an administrator credential backed by the Secure Enclave.

Macs with Apple silicon: no firmware password

On Apple silicon, the guide states that the firmware password "isn't required", because the functionality it restricted "has been moved into the recoveryOS" and, when FileVault is on, recoveryOS requires user authentication first. The Startup Disk security policy page adds that changes which would "significantly degrade security" require entering recoveryOS by holding the power button, "so that malware can't initiate the signal, only a human with physical access can", and that an Apple silicon Mac "won't require (or support) a firmware password".

Security policy is also per installed operating system rather than per machine. Full Security is the default and uses a signature personalized to that specific chip. Reduced Security can be chosen in Startup Security Utility, and Permissive Security is reachable only from command line tools. For fleets, the practical control is FileVault plus device management rather than a firmware credential. Our FileVault and BitLocker escrow post covers recovery key handling at scale.

How fleets manage firmware settings at scale

Nobody sets a supervisor password by hand on a thousand laptops. There are three broad approaches, and most organizations end up running more than one because their fleet has more than one maker.

Maker WMI and command line tools

Every large PC maker ships a management interface for its business lines. On Windows these are WMI providers in the root\wmi namespace and companion command line tools; on Linux, several of them are exposed through the kernel's firmware-attributes class.

One major PC maker's WMI deployment guide lists the capabilities: changing single or all settings, and "BIOS password management, including updating supervisor passwords, power-on passwords, and hard disk drive (HDD) passwords", remotely or locally, unattended. It also lists limits that shape every fleet design:

• "A password cannot be set using this method when one does not already exist. Passwords can only be updated or cleared." The first supervisor password on that maker's machines has to be set some other way, typically at the factory, through a one time physical step, or through a separate provisioning tool.
• Settings cannot be changed in the same boot as power-on or drive passwords.
• Some security settings cannot be weakened through WMI at all, as noted above.
• Every change made while a supervisor password exists must carry that password.

Another major PC maker's configuration utility guide shows a different design choice. Its tool takes the setup password as an encrypted password file generated by a companion utility rather than as plain text on the command line, and a single command can set the new password and apply a configuration file. It also warns that clearing the setup password "will remove all BIOS Users".

The trade off with all of these: they work well, but the password has to travel to the endpoint for every change. It sits in a deployment tool, a script, a task sequence variable or a command line. That is where shared passwords leak.

Certificate based firmware authentication

The better model removes the shared secret from the endpoint. The firmware stores a public key or certificate, and every settings change arrives as a payload signed by the matching private key, which never leaves a signing service. The endpoint only ever sees signatures.

Several makers implement this, under different names:

• The Linux kernel documentation describes one maker's certificate based authentication: "used in conjunction with a signing server as an alternative to password based authentication". The administrator installs a certificate, then each change is authorized by writing a signature obtained from the signing server. It notes that "you cannot enable certificate authentication if a supervisor password has not been set", that clearing the certificate leaves "no bios-admin authentication method" so "anyone" can make changes, and that admin and system certificates are "supported from 2025 systems onward" on that maker's machines.
• Another maker's configuration utility guide describes an enhanced authentication mode in which the firmware "requires an authorization string in order to allow changes to BIOS settings rather than using a BIOS Admin Password". The string carries an anti-replay counter, a one time flag and a target identifier, "as well as a cryptographic signature". The target can be one machine's UUID, or a wildcard value so one signed payload applies across many systems. The kernel documentation exposes this platform's endorsement key and signing key setup as a separate enhanced-bios-auth role.

Note the details that make this safer than a password: a per device target identifier means a captured payload works on one machine only, and an anti-replay counter means it cannot be replayed even there.

DFCI through Microsoft Intune

DFCI goes one step further: the management authority is a cloud service, and the trust chain is anchored in a certificate built into the firmware. Microsoft's Intune documentation says DFCI "enables Windows to pass management commands from Intune to UEFI", that its "trust chain uses public key cryptography, and doesn't depend on local UEFI (BIOS) password security", and that "when the DFCI policy is applied, local users can't change settings configured by DFCI, even if the UEFI (BIOS) menu is password protected."

How it works, from the Project Mu documentation (Project Mu is Microsoft's open source UEFI firmware code base; the DFCI code is published under the BSD-2-Clause-Patent license):

1. The maker must build DFCI into the firmware, including the single shared "Microsoft Device Management Trust" certificate that acts as the root of trust.
2. The device must be registered in Windows Autopilot by the maker or a Microsoft Cloud Solution Provider partner. Intune's documentation is explicit that DFCI cannot be used with devices "manually registered for Windows Autopilot, such as imported from a csv file", because DFCI needs external attestation of the device's commercial purchase.
3. When the device enrolls in Intune with a matching DFCI profile, the Autopilot service signs per device enrollment packets that enroll the Intune management certificate. Windows writes them to UEFI variables and reboots so the firmware can process them.
4. Day to day, Intune sends device specific signed packets. Project Mu says they include "the SMBIOS manufacturer, model, & serial number, along with an anti-rollback count".

Intune's DFCI settings cover local user access to the menu ("Only not configured settings" or "None"), CPU and IO virtualization, the Windows Platform Binary Table, simultaneous multithreading, cameras, microphones and speakers, radios, boot from external media, boot from network adapters, and individual ports such as USB type A and SD card readers. Availability depends on the maker and model.

DFCI has sharp edges, and Microsoft's own pages call them out:

• "Configuring and assigning DFCI profiles can lock the device beyond repair."
• "Disabling all external boot options or all external ports significantly complicates OS recovery", to the point that "you might have to physically open the device and replace the hardware storage."
• Disabling all radios means "the device requires a wired network connection. Otherwise, the device can be unmanageable."
• "Deleting the DFCI profile, or removing a device from the group assigned to the profile doesn't remove DFCI settings or re-enable the UEFI (BIOS) menus." To retire a device you first change the profile so local users may change "Only not configured settings" and set everything else to Not configured, then wipe, then delete the Autopilot record.
• If you delete the Autopilot record before unlocking the menus, "the menus remain locked" and Intune can no longer reach the device. The documented recovery is the firmware menu's "refresh from network", which unlocks the menus but leaves settings at the last profile's values.
• Category and granular settings for the same hardware can conflict and flip each other on every sync. Configure one or the other.

Project Mu also says recovery must remain possible: a physically present user must be able to supply DFCI packets through the firmware menu, and "this MUST NOT be blocked by a BIOS password or similar". For servers, Project Mu says DFCI "does not presume to be the solution" and points to Redfish as more suitable for the datacenter.

Comparison: which approach fits which fleet

Step by step: unique supervisor passwords, locked boot settings and verification

This walkthrough uses interfaces documented by the operating system and firmware projects, so it works across makers. Where a step needs the maker's own tool, the text says so. Run it first on a test device of each model you own.

Before you start. Changing firmware passwords and boot settings can lock a device. Have the serial number, the maker's service manual and a recovery plan for each model before touching production machines. Never run these steps on the only machine you can recover from.

1. Inventory what the firmware exposes

On Linux, the firmware-attributes class shows each supported driver as a directory. The directory name tells you which maker driver is loaded.

# List firmware-attributes providers on this machine
ls /sys/class/firmware-attributes/

# Show the authentication objects and whether each is enabled
for a in /sys/class/firmware-attributes/*/authentication/*; do
  printf '%s role=%s mechanism=%s enabled=%s\n' \
    "$(basename "$a")" "$(cat "$a/role")" "$(cat "$a/mechanism")" "$(cat "$a/is_enabled")"
done

# Read the allowed password length before generating one
cat /sys/class/firmware-attributes/*/authentication/Admin/min_password_length
cat /sys/class/firmware-attributes/*/authentication/Admin/max_password_length

fwupd offers the same data through a friendlier command when your version supports it:

fwupdmgr get-bios-settings
fwupdmgr security

On Windows, discover the maker's WMI classes rather than hard coding names:

# Find firmware configuration classes exposed by the maker's WMI provider
Get-CimClass -Namespace root\wmi |
  Where-Object CimClassName -match 'Bios|Password|Setting' |
  Select-Object CimClassName

# Secure Boot state and virtualization based security state
Confirm-SecureBootUEFI
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

Record model, firmware version, which authentication roles exist, and whether a supervisor password is already set. That record decides which path each model takes.

2. Generate a unique password per device and store it before you set it

Write the credential to your vault first, keyed by serial number, then set it. If the set step fails you can retry; if you set it first and the vault write fails, you have just created a device nobody can unlock.

Firmware password rules differ from operating system rules. Lengths are short (read the min and max values above), some platforms accept only characters that map to keyboard scan codes, and some interfaces take an encoding and keyboard layout parameter. Use letters and digits only unless you have tested the full character set on every model.

#!/usr/bin/env bash
# Generate a per-device supervisor password and hand it to the vault first.
set -euo pipefail
SERIAL=$(cat /sys/class/dmi/id/product_serial)
MAXLEN=$(cat /sys/class/firmware-attributes/*/authentication/Admin/max_password_length)
LEN=$(( MAXLEN < 20 ? MAXLEN : 20 ))
PW=$(LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c "$LEN")

# Replace this with your vault's CLI or API. Fail closed if the write fails.
vault_put "firmware/supervisor/${SERIAL}" "$PW" || { echo "vault write failed"; exit 1; }

# Never echo or log $PW. Pass it on to step 3 through a file descriptor or memory only.

3. Set or change the supervisor password

How the very first password gets set depends on the maker. As the WMI guide above shows, some platforms do not allow setting the first supervisor password from the operating system at all. Options include ordering devices with the password preset, a one time step at the firmware menu during imaging, or the maker's provisioning tool. For changes once a password exists, the kernel interface works like this:

# Change the existing supervisor password. Runs as root. Values come from the vault.
ADMIN=/sys/class/firmware-attributes/*/authentication/Admin
printf '%s' "$CURRENT_PW" > $ADMIN/current_password
printf '%s' "$NEW_PW"     > $ADMIN/new_password
# Some platforms only activate the new password on the next boot.
cat /sys/class/firmware-attributes/*/attributes/pending_reboot

The kernel documentation calls password management "session specific": write the password into current_password, make your changes, then clear it. It also notes that on one maker's platforms a changed admin password "is not active until the next boot", so update the vault entry with a pending flag and confirm after reboot.

4. Lock boot order, external boot and Secure Boot

Setting names vary by maker. List them first, then set the values your policy needs inside a single authenticated session:

FA=/sys/class/firmware-attributes/*
ls $FA/attributes/ | grep -iE 'boot|secure|usb|pxe|network|thunderbolt|vt|iommu|dma'

# Inspect allowed values before changing anything
cat $FA/attributes/<SettingName>/possible_values
cat $FA/attributes/<SettingName>/current_value

# Authenticated session: set password, change values, clear password
printf '%s' "$PW" > $FA/authentication/Admin/current_password
echo Disabled > $FA/attributes/<ExternalBootSetting>/current_value
echo Disabled > $FA/attributes/<NetworkBootSetting>/current_value
echo Enabled  > $FA/attributes/<IOMMUSetting>/current_value
printf '' > $FA/authentication/Admin/current_password
cat $FA/attributes/pending_reboot

Replace each <SettingName> with the exact name your platform lists; do not guess. If you use DFCI instead, set "Boot from external media (USB, SD)" and "Boot from network adapters" to Disabled in the profile, and remember Microsoft's guidance never to disable external media while enabling network boot, which makes both settings noncompliant.

Keep a way back in. Before you disable every external boot path, confirm that your recovery process does not need one. Microsoft's DFCI recovery tool documentation, for example, says that to run the stand alone recovery application from a USB shell, booting from USB must be enabled.

5. Verify from the operating system after reboot

Verification is what turns a configuration into evidence. After the reboot:

# Linux: confirm Secure Boot, the admin password, and the settings you changed
mokutil --sb-state
cat /sys/class/firmware-attributes/*/authentication/Admin/is_enabled
for s in <ExternalBootSetting> <NetworkBootSetting> <IOMMUSetting>; do
  printf '%s=%s\n' "$s" "$(cat /sys/class/firmware-attributes/*/attributes/$s/current_value)"
done

# Windows: Secure Boot, Kernel DMA Protection and VBS
Confirm-SecureBootUEFI
# Kernel DMA Protection appears in System Information (msinfo32) as "Kernel DMA Protection: On"
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus

# Intel-based Mac only: check whether a firmware password is set
sudo firmwarepasswd -check
# Any Mac: System Integrity Protection and FileVault status
csrutil status
fdesetup status

Send these results to your inventory or configuration management database, keyed by serial number, so drift shows up as a diff rather than as a surprise during an incident.

6. Rotate

Rotate supervisor passwords on a schedule and whenever someone with access leaves, a script that handled them is found to have logged them, or a device returns from a third party repair. Rotation is step 3 with the vault as both source and destination: read current, generate new, write new to vault as pending, change on device, confirm after reboot, mark the old value retired. With certificate based authentication, rotation becomes certificate renewal, and the kernel documentation shows the flow: write a signature, then the new signed certificate.

7. Document recovery and RMA before you need it

NIST SP 800-147 asks for disposal steps that reset the configuration "to the manufacturer's default profile", noting that "sensitive settings such as passwords should be deleted from the system and keys should also be removed from the key store". Turn that into a runbook per model:

• How to remove the supervisor password before a device goes back to the maker for repair, and who is allowed to do it.
• For DFCI devices, the retirement order: change the profile to unlock settings, wipe, then delete the Autopilot record. Never the other way round.
• For drive passwords, whether the drive can be returned at all, and how the data is sanitized first.
• For Intel-based Macs, whether the reset capability was disabled, and therefore whether a lost password means a board replacement.
• Who can retrieve a password from the vault, and how that access is logged.

Common mistakes

One supervisor password across the fleet. It is easy, and it means one leak from a help desk ticket, a screenshot or a former employee unlocks every device you own. It also makes rotation a fleet wide project, so it rarely happens.

Passwords in deployment scripts and task sequences. Plain text passwords in imaging scripts, command lines and environment variables end up in logs, crash dumps, repositories and backups. Use encrypted password files where the maker's tool supports them, pull per device values from the vault at run time, and never echo them.

Forgotten drive passwords. Drive passwords are enforced by the storage device. One maker's guide says a forgotten drive password means the maker cannot reset it or recover data, and the drive has to be replaced. Do not enable them without escrow, and do not mix them with self encrypting drive management.

No recovery record, then a bricked return. Devices sent for repair with an unknown supervisor password, or retired from DFCI in the wrong order, come back unusable. Record the recovery path per model before deployment, not after.

Locking every boot path with no way back. Disabling USB boot, network boot and external ports all at once makes reimaging and recovery very hard. Microsoft's DFCI guidance warns that recovery might mean opening the device to replace storage.

Assuming the password protects code. It protects menus. It does not stop direct flash programming on a platform without hardware verified boot, or a firmware vulnerability. Keep firmware updated with rollback prevention, and check SPI write protection.

Setting a password but leaving external boot on. An attacker who can boot their own operating system does not need your setup password. Lock boot order first; the password then protects that decision.

Ignoring NIST SP 800-147 and SP 800-193. SP 800-147 already describes the configuration baseline (including password policy and boot order), the deployment phase and the disposal phase. SP 800-193 adds detection and recovery. Teams that skip them tend to have a password policy and nothing else.

FAQ

What is the difference between a supervisor password and a power-on password?

The supervisor (admin) password protects the firmware settings: without it you cannot change boot order, Secure Boot or other security options. The power-on (user or system) password must be entered before the computer boots at all. If both are set, the supervisor password usually overrides the power-on password.

Does removing the CMOS battery reset a BIOS password?

On most current business laptops, no. Passwords are held in protected non-volatile storage, and one major PC maker's guide says there is no service procedure for a forgotten supervisor password other than replacing the system board. Some desktops and consumer boards still have a clear jumper; check your model's service manual.

Should every laptop have a BIOS password?

Every managed laptop should have its firmware settings locked, either with a unique supervisor password, a certificate based scheme or DFCI. A power-on password is optional and mostly useful for shared or kiosk devices; disk encryption does a better job of protecting data.

Can malware change BIOS settings if a supervisor password is set?

Not through the normal configuration interfaces: the kernel documentation notes that on several makers' laptops all settings changes need the password once it is set, and some settings cannot be weakened from the operating system at all. A firmware vulnerability or missing flash write protection can still bypass the menu, so keep firmware updated.

What is DFCI in Intune?

The Device Firmware Configuration Interface lets Intune send signed firmware settings to supported Windows devices registered in Windows Autopilot by the maker or a Cloud Solution Provider partner. It uses public key cryptography rather than a local password, and local users cannot override settings it manages.

Do Macs have a BIOS password?

Intel-based Macs support a firmware password set from recoveryOS or with firmwarepasswd. Macs with Apple silicon do not need or support one; security policy changes require recoveryOS, physical presence and user authentication instead.

Is a BIOS password enough to stop an evil maid attack?

Only if it protects a locked configuration. If external boot is still allowed, an attacker can boot another operating system without touching the setup menu. Disable external and network boot, keep Secure Boot on and use full disk encryption.

What is certificate based BIOS authentication?

The firmware stores a certificate instead of relying on a shared password, and each settings change must arrive signed by a private key held on a signing server. Payloads can target one device and carry an anti-replay counter, so a captured change cannot be reused elsewhere.

Where Safeguard fits

Safeguard does not set firmware passwords, manage BIOS settings, scan firmware images, generate hardware bills of materials or manage devices. Use your makers' tools, DFCI or your device management platform for those. The fit is with the software around them that your team writes or packages: the scripts and small services that generate per device passwords, talk to the vault, call maker command line tools or the signing service, and report settings drift. Those are ordinary Python, PowerShell, Go or Node projects with open source dependencies. Safeguard scans those repositories, container images and SBOMs (safeguard scan --dir ., --image <name>, --sbom <file>), matches components against vulnerability databases and ranks findings by reachability, so a vulnerable library in the service that handles your fleet's firmware credentials is found and fixed like any other.

Firmware credentials are managed by code: provisioning scripts, signing services and inventory jobs that pull open source packages every time they are rebuilt. A vulnerable dependency in that tooling sits next to the most sensitive secrets your fleet has, so the same supply chain hygiene applies here even though the firmware itself is outside Safeguard's scope.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the repository that holds your firmware provisioning scripts or signing service, the same scan lists the open source packages and versions inside it and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow suits a dependency bump in tooling that touches firmware credentials, where you want a person to see every change before it runs.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. An endpoint team can then ask in plain language which of its internal projects contain a given version of a library before it rebuilds its provisioning tools.

Click through it at your own pace, or open it full screen.

To try it on your own tooling, download Safeguard and read the CLI documentation.

Quick check

Sources

• NIST SP 800-147, BIOS Protection Guidelines (April 2011)
• NIST SP 800-147 full text (PDF)
• NIST SP 800-147B, BIOS Protection Guidelines for Servers (August 2014)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)
• NIST SP 800-193 full text (PDF)
• Microsoft Learn: Use DFCI profiles on Windows devices in Microsoft Intune
• Microsoft Learn: DFCI settings reference for Windows
• Project Mu: DFCI feature introduction
• Project Mu: DFCI scenarios
• Project Mu: DFCI menu and stand alone recovery
• Microsoft Learn: Kernel DMA Protection
• Apple Platform Security: Firmware password protection in an Intel-based Mac
• Apple Platform Security: Startup Security Utility on a Mac with an Apple T2 Security Chip
• Apple Platform Security: Startup Disk security policy control for a Mac with Apple silicon
• Linux kernel ABI: sysfs-class-firmware-attributes
• fwupd: fwupdmgr manual
• TianoCore EDK2: GlobalVariable.h (UEFI global variable names)
• One major PC maker's user guide: UEFI BIOS passwords
• One major PC maker's user guide: forgotten supervisor password
• One major PC maker's BIOS setup using WMI deployment guide (PDF, March 2018)
• Another major PC maker's BIOS configuration utility user guide (PDF, August 2021)

Last reviewed: 25 October 2026. Firmware menus, setting names and recovery procedures differ by maker, model and firmware version; check your model's own documentation before changing passwords or boot settings on production devices.