BIOS and UEFI Settings Management at Fleet Scale

Most fleets enforce hundreds of operating system settings and leave the firmware setup menu, where Secure Boot, boot order, virtualisation and device ports are decided, protected by one shared BIOS password that nobody has rotated since imaging. This guide covers the day-to-day operation of firmware settings across a laptop and desktop estate: how BIOS administrator credentials are set and governed, which management channels exist (OEM tooling, Microsoft DFCI and the Linux firmware-attributes interface), how to define a firmware baseline, detect drift and prove posture with attestation. It does not repeat the boot trust chain or firmware patching, which are covered in the Firmware and Boot Security Guide and the Firmware and BIOS Update Management Guide. It is written for endpoint engineers, desktop platform owners and the security architects who set their baselines. Platforms are listed alphabetically; order is never a ranking.

Key takeaways

The BIOS admin password is a privileged credential. On Dell, HP and Lenovo systems an admin password gates every firmware attribute, so a single shared value across the fleet is a fleet-wide skeleton key and belongs under the same governance as local administrator accounts.
Prefer key-based or per-device authority over shared passwords. Microsoft DFCI uses a public key trust chain instead of a local password, OEMs offer certificate-based authority, and Intune can hold unique per-device BIOS passwords on supported hardware.
Treat firmware settings as a versioned baseline. Define the required values per model family, store them as code, apply them through one channel per device, and record exceptions like any other configuration standard.
Drift is detectable from the operating system. OEM WMI providers and the Linux /sys/class/firmware-attributes class expose current values, so settings can be read and compared on a schedule without touching the device.
Attestation proves outcomes, not settings. Device health attestation reports whether Secure Boot, BitLocker and code integrity held at boot; pair it with settings inventory, because attestation alone will not show an enabled USB boot path or a cleared password.

What firmware settings management covers

Firmware setup menus control behaviour that the operating system cannot override once it has booted. The settings that matter for security fall into a small number of groups, and a baseline should state a required value for each one per model family.

Setting group	Typical secure value	Why it matters
Administrator (setup) password or certificate authority	Set, unique or key based, held in a vault or management service	Without it any user with physical access can change every other setting
Power-on (system) password	Usually off for standard laptops where disk encryption with TPM and PIN is used; on for specific high-risk roles	Adds a pre-boot gate but creates helpdesk load and is often redundant with pre-boot disk authentication
Secure Boot	Enabled, standard mode, default key databases unless you manage your own	Disabling it opens the path for unsigned boot loaders (ATT&CK T1542 Pre-OS Boot)
TPM	Enabled and activated	Needed for measured boot, BitLocker key protection and health attestation
Boot order and external boot	Internal disk first; USB and network boot disabled outside imaging windows	Booting another operating system bypasses OS controls and allows offline tampering
Virtualisation (VT-x, VT-d, IOMMU)	Enabled	Required for virtualisation-based security and DMA protection features
Ports, cameras, radios, microphones	Per role: disabled where policy requires, for example in secure areas	Firmware-level disablement survives OS reinstallation
Wake on LAN, wake on power	Enabled only where the patching or management process needs it	Reduces unexpected remote wake paths
Firmware update and downgrade behaviour	Signed updates only; rollback protection on where offered	Blocks installing older firmware with known weaknesses; see the update management guide for process

The Linux kernel documentation for the firmware-attributes class captures the vendor-common model well: an "Admin" password prevents modification of BIOS settings, a "System" password is required to boot, and on Dell, Lenovo and HP systems all BIOS attributes require password validation once an admin password is set. That last point is the reason the admin credential is the control everything else depends on.

Governing the BIOS administrator credential

Three authority models exist across current business hardware. Choose one per model family and record it in the baseline.

Model	How it works	Strengths	Watch points
Shared password	One admin password set at imaging and supplied to tooling when settings change	Simple, works offline and on every model	Disclosure of one value exposes the fleet; rotation needs the old value on every device; often embedded in scripts and packages
Unique per-device password	A management service generates and stores a different password per device	Blast radius limited to one device; retrieval is logged by the service	Retrieval rights become a privileged role; records must be removed on device retirement
Certificate or key-based authority	Firmware accepts only commands signed by an enrolled key; no reusable password exists	No secret on the endpoint; changes require the signing service	Signing keys need HSM-grade protection and a recovery plan; enrolment and removal must be planned before devices leave service

Rules that apply to every model

Never in plain text: passwords do not belong in task sequences, scripts, package command lines or log files. Use the vendor's encrypted password file or payload formats and remove temporary files after use.
Session discipline: on Linux the kernel interface is session based: the current password is written before a change and must be cleared once the session is over. Tooling that leaves it set keeps the firmware unlocked for anything else on the device.
Least privilege for retrieval: the people who can read or reset BIOS passwords are a small privileged group, ideally checked out through PAM with a reason code. See the LAPS vs PAM Vaulting guide for the same trade-off applied to local administrator accounts.
Rotation on events: rotate after a helpdesk disclosure, after a technician leaves, and when a device changes owner or is returned from repair.
Retirement: clear passwords or release key-based management before resale or recycling, otherwise the device is unusable to the next owner and the records linger in your systems.

Management channels

Most organisations use one cross-vendor channel where hardware supports it and OEM tooling for everything else. The sections below summarise each channel from its official documentation.

Dell

Dell Command | Configure is described by Dell as a tool to help IT administrators manage and automate BIOS settings on Dell client systems, with a graphical interface for building configuration packages and a command line interface for scripting; it was formerly known as the Dell Client Configuration Toolkit (CCTK). Dell Command | PowerShell Provider is a PowerShell module for BIOS configuration on local and remote systems and in Windows PE, and requires platforms supporting WMI-ACPI BIOS. For Intune-managed fleets, Dell Command | Endpoint Configure for Microsoft Intune (DCECMI) applies BIOS profiles built in Dell Command | Configure as packages pushed by Intune and supports a unique-per-device BIOS password; Dell notes that from Intune version 2405 the hardwarePasswordDetail API can retrieve those passwords and that password information can be deleted for unenrolled devices.

Availability: DCECMI requires a Dell commercial client running Windows 10 or later, Intune MDM enrolment and the .NET runtime version stated in Dell's article.

HP

The HP Client Management Script Library (CMSL) is a set of PowerShell modules; its BIOS and Device module queries client properties and manipulates HP BIOS settings through cmdlets such as Get-HPBIOSSettingsList, Set-HPBIOSSettingValue and Set-HPBIOSSettingValuesFromFile, with password state and change cmdlets such as Get-HPBIOSSetupPasswordIsSet and Set-HPBIOSSetupPassword, and Write-HPFirmwarePasswordFile for password files. For key-based authority, HP Secure Platform Management uses an endorsement key and a signing key provisioned through payload cmdlets (New-HPSecurePlatformEndorsementKeyProvisioningPayload, New-HPSecurePlatformSigningKeyProvisioningPayload), and HP Sure Admin builds signed payloads for setting changes, defaults and firmware updates, with optional key management service integration and local access keys for technicians. The Linux kernel exposes the same model through an SPM authentication object with kek and sk attributes, and HP Sure Start audit log entries are readable from the firmware-attributes class.

Availability: HP notes that firmware module functionality may differ between platforms or generations of platforms; check each cmdlet's documentation for the model in question.

Lenovo

Think BIOS Config Tool v2 is a PowerShell WPF interface built on the Lenovo.BIOS.Config module that reads and changes Lenovo BIOS settings through WMI. Its Generate INI action exports settings and can include a Supervisor password encrypted with a passphrase; Apply Settings takes the INI and passphrase; Change Supervisor Password can create a password-change file for deployment; and Create Intune Package produces Win32 or Remediation packages. Lenovo advises treating passwords and passphrases as secrets and deleting temporary password-change files after use. For password-less management Lenovo pairs the tool with its BIOS Certificates Tool and Module. The Linux kernel documents Lenovo certificate-based authentication used with a signing server as an alternative to password authentication, a system-mgmt role that carries security authority as configured by the SMP Access Control Policy, and notes that a changed admin password is not active until the next boot.

Availability: Lenovo states that Think BIOS Config Tool v2 does not support ThinkCentre desktops because their WMI BIOS implementation differs, and the kernel documentation states that Admin and System certificates are supported on systems from 2025 onward.

Cross-vendor channels

Microsoft Intune DFCI: the Device Firmware Configuration Interface lets Intune manage UEFI settings after Windows Autopilot enrolment, enforced at the firmware layer so that reinstalling or replacing the operating system does not override them. Its trust chain uses public key cryptography rather than a local UEFI password, and local users cannot change DFCI-managed settings even when the menu is password protected. Settings include Allow local user to change UEFI settings, CPU and IO virtualization, cameras, microphones, radios, Boot from external media (USB, SD), Boot from network adapters, USB type A and SD card ports, and wake settings. Devices must be registered in Autopilot by the OEM or a Cloud Solution Provider partner; manual CSV import is not supported. Hardware support is listed by Microsoft per OEM.
Linux firmware-attributes class: drivers for Dell, HP and Lenovo publish each setting under /sys/class/firmware-attributes/*/attributes/ with its current and possible values, authentication objects with role (for example bios-admin, power-on) and mechanism (password or certificate), and a pending_reboot flag that reads 1 when changes await a restart. fwupd-based tooling and configuration management agents can read this class for inventory.

Implementation: from shared password to managed baseline

Inventory first. Collect model, firmware version, admin password state, Secure Boot and TPM state for every device through the OEM WMI provider or the Linux class. The first finding is usually several password generations and a long tail of devices with no admin password at all. Feed the results into your Asset Inventory and CMDB Security Guide records.
Write the baseline per model family. One table per family with the required value, the reason and the owner, aligned with your OS baseline. Keep it in version control with change approval, like any other standard in the Configuration Drift and Baseline Enforcement Guide.
Pick one channel per device. DFCI where hardware and Autopilot registration allow it, OEM tooling otherwise. Two channels writing the same setting will fight, and DFCI documentation warns that conflicting category and granular settings loop between noncompliant and applied on every sync.
Pilot in rings. Start with IT devices of each model, then a business pilot ring, then broad deployment. Watch for BitLocker recovery prompts: changing measured settings such as Secure Boot state or boot order can change TPM measurements, so suspend protection or plan recovery key access for the change window. See the BitLocker guide.
Move authority off the shared password. Roll unique per-device passwords or certificate authority model by model, using the old shared value one final time to make the change. Record the date each device migrated.
Plan rollback before you need it. For OEM tooling, keep a known-good settings file per model and the procedure to reapply it. For DFCI, Microsoft documents that deleting the profile or removing the device from its group does not unlock the menus: retire management by setting Allow local user to change UEFI settings to Only not configured settings and every other setting to Not configured, then wipe and delete the Autopilot record. Microsoft warns that incorrect DFCI values can lock a device beyond repair, so never disable every boot and port option on the same device.
Close the loop with attestation. Add Intune compliance rules such as Require Secure Boot to be enabled on the device, Require BitLocker and Require code integrity, evaluated by the Device Health Attestation service, and tie conditional access to the result.

Choosing an approach

Situation	Recommended approach	Reason
New Windows devices bought through a CSP with Autopilot registration, on DFCI-capable models	DFCI for the settings it covers, OEM tooling for the rest	No local password to manage for DFCI settings; enforcement survives OS reinstall
Mixed or older Windows estate	OEM tooling through Intune or Configuration Manager, with unique per-device passwords where supported	Works on hardware outside DFCI support and covers vendor-specific settings
Linux workstations	Read and set through the firmware-attributes class from configuration management, with certificate or SPM authority where the hardware supports it	Same vendor-common model as Windows tooling, scriptable without vendor agents
Small organisation, one hardware vendor, no MDM	Vendor tooling with encrypted password files, a vaulted unique password per device recorded in the asset register	Avoids the shared-password trap without new infrastructure
High-assurance or secure-area devices	Key-based authority, ports and radios disabled at firmware, power-on password or pre-boot disk authentication	Firmware enforcement survives tampering with the OS and limits physical attack paths

Where identity fits

Firmware authority is a non-human credential problem as much as an endpoint one. The signing keys used by key-based models, the service accounts that run settings packages, and the API permissions that retrieve per-device passwords (Dell notes that listing hardware password information requires Global Administrator from Intune version 2404) are privileged identities. Put the signing keys in an HSM or managed key service with dual control, give the deployment service account rights only to the device groups it manages, and alert on every password retrieval. The Legacy LAPS vs Windows LAPS guide covers the equivalent pattern for OS administrator accounts.

Detection and measurement

Scheduled settings read: collect each baseline setting through WMI or the Linux class daily and compare with the baseline. Report differences per model and per setting, not just per device.
Change signals: the Linux class emits a change uevent when an admin or system password is set or cleared and when pending_reboot changes; forward these to the SIEM. On HP hardware, collect Sure Start audit log entries.
Attestation results: track devices failing Secure Boot, BitLocker or code integrity health checks and treat a device that changes from compliant to noncompliant without a change ticket as a potential tampering event. The Firmware and Bootkit Compromise Playbook covers response.
Credential use: log and review every BIOS password retrieval or reset and every signing request.

Metric	Target
Devices with an admin password or key-based authority set	100 per cent of in-scope devices
Devices still on a shared admin password	Falling each quarter to zero
Devices matching the firmware baseline for their model	98 per cent or higher, with exceptions recorded
Devices passing Secure Boot health attestation	Equal to the in-scope population, gaps explained
Mean time from drift detection to remediation	Within your configuration SLA, for example 7 days
Password retrievals without a linked ticket	Zero

Common failure patterns

The password in the task sequence: a shared BIOS password typed into a deployment script or package command line spreads to every technician, log and backup that touched it.
Two tools, one setting: DFCI and an OEM package both managing boot order or cameras produce flapping compliance and helpdesk calls.
Unplanned BitLocker recovery: a Secure Boot or boot order change rolled to thousands of devices without suspending protection triggers mass recovery key requests.
Locked returns: devices sent for resale or warranty with key-based management or passwords still in place, because retirement steps were never written down. DFCI retirement in particular must happen before the Autopilot record is deleted.
Attestation without inventory: compliance dashboards show green for Secure Boot while USB boot is enabled and the admin password is blank, because attestation does not report those settings.
Signing keys on a file share: key-based authority adopted to remove passwords, with the private signing key kept in a file next to the scripts.

Framework mapping

Framework	Reference	How this guide applies
NIST SP 800-53 Rev. 5	CM-2 Baseline Configuration; CM-3 Configuration Change Control; CM-6 Configuration Settings; CM-7 Least Functionality	Firmware baseline per model, change approval, disabling unneeded boot paths and devices
NIST SP 800-53 Rev. 5	SI-7 Software, Firmware, and Information Integrity; SI-7(9) Verify Boot Process; SI-7(10) Protection of Boot Firmware	Secure Boot settings, attestation and protection of firmware configuration
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; AC-6 Least Privilege	BIOS password and signing key governance, retrieval rights
NIST CSF 2.0	PR.PS-01 Configuration management practices are established and applied; DE.CM-09 Computing hardware and software are monitored	Baseline and drift detection
NIST SP 800-193	Protection, detection and recovery principles	Firmware and its data protected from unauthorised change, changes detected, recovery planned
CIS Controls v8.1	Control 4 Secure Configuration of Enterprise Assets and Software	Documented secure configuration including firmware. See the CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide
ISO/IEC 27001:2022 Annex A	8.9 Configuration management	Firmware configurations established, documented, monitored and reviewed
MITRE ATT&CK	T1542 Pre-OS Boot, T1542.001 System Firmware; mitigation M1046 Boot Integrity	Locked settings and attestation reduce pre-OS persistence paths. See the MITRE ATT&CK M1046 Boot Integrity guide

Practitioner checklist

Inventory admin password state, Secure Boot, TPM and firmware version for every device.
Publish a firmware settings baseline per model family under change control.
Assign exactly one management channel per device and setting.
Replace the shared admin password with unique per-device passwords or key-based authority.
Protect signing keys in an HSM or managed key service with dual control.
Restrict and log BIOS password retrieval; review retrievals without tickets.
Plan BitLocker handling for any change to measured settings.
Document rollback and retirement, including DFCI release before Autopilot record deletion.
Collect settings daily and alert on drift and password state changes.
Require Secure Boot, BitLocker and code integrity in device compliance and tie access to it.

BIOS and UEFI Settings Management Guide: Admin Passwords, Drift Control and Attestation Across Fleets