Firmware and BIOS Update Management Guide: Patching Laptops, Servers and BMCs Safely

Firmware is the layer most patch programmes skip: operating systems and applications are updated monthly, while BIOS, UEFI, baseboard management controller and device firmware often stay at the version they shipped with. Firmware flaws give an attacker persistence below the operating system and survive reimaging, and a failed firmware update can leave a laptop unbootable or a server offline. This guide is about the operational side: how to inventory firmware versions, where updates come from, how to stage and deploy them to laptops, servers and BMCs, how to handle BitLocker and rollback, and how to measure coverage. It is written for endpoint, infrastructure and vulnerability management teams. For the security architecture of the boot chain, Secure Boot and BMC hardening, see the Firmware and Boot Security Guide.

Key takeaways

• You cannot patch what you have not inventoried. Collect system firmware, BMC, storage controller, network adapter and dock firmware versions per model, not just per device.
• Use signed, authenticated update paths only. UEFI capsules through the operating system, signed packages through your management tool, or the BMC's update service. Never allow unsigned flashing in production.
• Ring firmware separately from operating system updates. Firmware is model specific and harder to roll back, so it needs its own pilot rings per hardware model.
• Plan for disk encryption and rollback. Firmware changes alter boot measurements, so manage BitLocker suspension, and keep anti-rollback protection on so attackers cannot reinstall vulnerable versions.
• BMCs are servers in their own right. Patch BMC firmware on its own schedule, through an isolated management network, with credentials treated as privileged.

Why firmware needs its own process

NIST SP 800-147 (BIOS Protection Guidelines) addresses unauthorised modification of client BIOS firmware, which can cause permanent system failure or let malware persist, and SP 800-147B extends that guidance to servers. NIST SP 800-193 (Platform Firmware Resiliency Guidelines) adds three principles: protection against unauthorised change, detection of change that does happen, and recovery to a known-good state. A management process has to keep the platform patched while preserving all three.

Firmware differs from software patching in ways that change the process:

The attacker interest is real: MITRE ATT&CK lists T1542.001 System Firmware and T1542.002 Component Firmware for persistence below the operating system, and T1495 Firmware Corruption for destructive attacks. See the MITRE ATT&CK T1495 Firmware Corruption guide.

Inventory: knowing what firmware you run

An inventory needs the manufacturer, model, and the firmware version of every updatable component, plus the date of the latest available version. Sources differ by platform:

• Windows clients: UEFI firmware publishes an EFI System Resource Table (ESRT). Microsoft documents that ESRT entries let Windows surface each updatable firmware resource with a hardware ID and report its current version and the status of the last update. Endpoint management and inventory tools read the system BIOS version and these resources.
• Linux clients and servers: fwupd enumerates updatable devices and reports their versions; fwupdmgr supports headless administration over SSH or a management framework.
• Servers and BMCs: the DMTF Redfish UpdateService links to a FirmwareInventory collection that lists platform firmware components and their versions, and a SoftwareInventory for OS-hosted components such as drivers. Querying it gives BIOS, BMC, storage controller, network adapter and power supply versions from one API.
• Peripherals and docks: docking stations, monitors with USB hubs and storage devices have their own firmware. Inventory the models, even if updates are user-initiated.

Feed the result into the asset inventory and compare it with the manufacturer's latest versions and security advisories. See the Asset Inventory and CMDB Security Guide and the Hardware and Firmware SBOM Guide.

Platform security posture alongside versions

Version data says whether you are current; posture data says whether firmware protections are on. The fwupd Host Security ID (HSI) specification grades hosts from HSI:0 (Insecure) to HSI:4 (Secure), with HSI:5 defined but not yet testable, and treats HSI-1 as the minimum baseline. Its attributes include whether BIOS capsule updates are enabled in firmware setup (HSI-1) and whether BIOS firmware rollback protection is on (HSI-2). A "!" suffix marks runtime issues such as Secure Boot being off. The specification is marked as still in development, so treat it as a practical baseline rather than a standard.

Update channels

Windows clients: Intune driver update policies

Microsoft Intune driver update policies provide an approval surface for drivers and firmware released by device manufacturers through Windows Update. Administrators choose automatic approval of recommended updates or manual review and approval. As of November 2026 Microsoft documents these requirements: Intune Plan 1 and a Windows licence that includes the Windows Autopatch entitlement; Windows Pro, Pro Education, Enterprise or Education (Enterprise LTSC uses update ring policies instead); Microsoft Entra joined or hybrid joined devices; diagnostic data set to at least Required; and the Microsoft Account Sign-In Assistant service running. Use manual approval for BIOS and firmware so each version passes a pilot ring before broad release. See the Configuration Manager to Intune guide for the wider servicing model.

Servers: the Redfish update model

The DMTF Redfish Firmware Update White Paper (DSP2062) describes the standard model that server BMCs implement. SimpleUpdate tells the BMC to pull an image from an ImageURI, with optional Targets naming the components to update and a Stage option to stage the image for later activation. MultipartHttpPushUri pushes an image from the client. The @Redfish.OperationApplyTime annotation sets when the update runs: Immediate, OnReset, AtMaintenanceWindowStart, InMaintenanceWindowOnReset or OnStartUpdateRequest. Requests return a task monitor, and jobs end as Completed, Exception or Cancelled, which gives automation a clear success signal.

Two settings deserve policy attention. The ForceUpdate parameter bypasses update policies such as downgrade blocks, so restrict it to documented recovery procedures. And the credentials your automation uses to call the BMC have full hardware control: treat them as privileged machine identities, vault them and rotate them. See the Service Account Security Guide.

Implementation: a staged rollout

1. Build the model matrix: list every hardware model with device counts, current firmware versions and the latest available version. Retire models that no longer receive firmware updates, or record them as accepted risk.
2. Subscribe to advisories: follow each manufacturer's security advisory page and your silicon vendors' platform update announcements, and add firmware to the weekly vulnerability triage. See the Vulnerability Management Guide.
3. Prepare the safety net: confirm BitLocker recovery keys are escrowed for every pilot device, record current firmware settings (Secure Boot state, TPM, boot order, virtualisation), and confirm a recovery path exists (manufacturer recovery image, dual-bank firmware, or a BMC recovery procedure).
4. Pilot ring per model: deploy to IT devices of each model first, then to a small set of real users. Check boot, docking, sleep and resume, BitLocker state and Secure Boot state after the update.
5. Broad deployment: release in waves with a pause between them. For laptops, require mains power and allow user-deferred restarts within a deadline. For servers, use maintenance windows, evacuate workloads and update one node per cluster at a time.
6. Verify: re-read the firmware version from the inventory source after restart; do not treat a successful package install as a successful flash, because capsules are applied at the next boot.
7. Rollback: pause the ring as soon as failures exceed your threshold. Most platforms block downgrades once a security fix is installed, so rollback usually means a manufacturer-supported recovery procedure or a fixed newer version, not reinstalling the old one. Plan for that before you start.

BitLocker and measured boot

Firmware updates change what the TPM measures at boot, so a device with BitLocker using TPM protectors may ask for its recovery key after an update. Microsoft documents that Suspend-BitLocker suspends protection for a set number of restarts (RebootCount 0 to 15, default 1; 0 suspends until Resume-BitLocker is run), and that while suspended the key is available in the clear and startup integrity is not validated. Suspend for the smallest number of restarts the update needs, never indefinitely, and report devices left suspended. Many update mechanisms suspend automatically; test this on each model in the pilot. See the BitLocker guide.

Secure Boot database updates

Firmware management now includes Secure Boot key and database updates, not only BIOS versions. The 2026 rotation of the Microsoft Secure Boot certificates requires updated db and KEK content on many devices; the fwupd HSI checks flag systems missing the Microsoft 2023 certificate. See the Secure Boot Certificate Expiry 2026 guide.

BMCs and out-of-band controllers

A baseboard management controller is a separate computer with its own firmware, network stack and accounts, running whenever the server has power. Its firmware needs its own cycle:

• Update order: follow the manufacturer's documented order. BMC firmware is often updated before BIOS because the BMC applies the BIOS update; confirm per platform.
• Update path: deliver images from an internal repository on the management network, not from the internet. Use the BMC's signed update mechanism and confirm image signature checking is on.
• Network: BMCs belong on an isolated management network reachable only from administrative jump hosts. Disable IPMI over LAN (UDP 623) where Redfish over HTTPS can replace it.
• After update: re-check settings that an update may reset, such as enabled services, local accounts and certificates.

The Firmware and Boot Security Guide covers BMC hardening in more depth, including the NSA and CISA BMC guidance.

Where identity fits

Firmware management depends on credentials with great power: BIOS administrator passwords, BMC local accounts, and the service accounts or API credentials that lifecycle and endpoint management tools use to push updates. Set a unique BIOS administrator password per device or a managed password solution where your platform offers one, avoid a single shared BMC password across the fleet, and vault any break-glass account. An attacker who controls the update tool controls the firmware of the whole estate. See the If your patch management tool is compromised playbook and the Break-Glass Account Guide.

Choosing an approach

• Small estates (one or two laptop models, a few servers): use the operating system channel (Windows Update with manual approval, or fwupd) for clients and the BMC web interface or Redfish for servers, with a written quarterly check of server firmware against the manufacturer's site.
• Mixed client estates: combine the Windows Update channel for broad coverage with manufacturer tools where they offer settings management or components the Windows channel does not deliver. Avoid two tools updating the same component on the same device.
• Large data centres: automate through Redfish or the server manufacturer's lifecycle manager, tie updates to change windows, and validate firmware bundles against hypervisor and storage support matrices.
• Emergency firmware fixes: when a firmware vulnerability is exploited in the wild, shorten the pilot to hours, apply compensating controls (network isolation of BMCs, disabling affected features), and use the Emergency Out-of-Band Patching Playbook.

Detection and measurement

Monitor for unexpected firmware change as well as missing updates. Useful signals are firmware version changes outside a change window, BMC firmware update events in BMC logs forwarded to the SIEM, Secure Boot turned off, BitLocker left suspended, and failed capsule updates reported in ESRT status or fwupd history.

• Firmware currency: percentage of devices on the latest manufacturer-supported firmware, by model. Report clients, servers and BMCs separately.
• Time to deploy security firmware: median days from manufacturer release to 90% deployment, against your policy target for the severity.
• Inventory coverage: percentage of devices with a firmware version reported in the last 30 days.
• Update failure rate: failed or bricked updates per thousand devices per wave. Rising rates should pause the ring.
• Unsupported hardware: devices on models with no further firmware updates.
• Protection posture: percentage of hosts with Secure Boot on and rollback protection enabled, for example HSI-2 or better on Linux hosts.

See the Vulnerability Management Metrics guide for reporting.

Common failure patterns

• Firmware outside the patch policy: the policy says "all software", but nobody owns firmware, so BIOS stays at the factory version for the device's life. Name firmware explicitly in the Patch Management Policy Template.
• Install reported, flash never applied: the package installs, the device is never restarted, and the dashboard shows compliance. Verify the version after reboot.
• BitLocker suspended indefinitely: a script uses a reboot count of 0 to avoid recovery prompts and never resumes protection.
• BMCs forgotten: host BIOS is updated, the BMC firmware is years old and its web interface is reachable from the user network.
• Downgrade protection turned off for convenience: disabling rollback protection to recover one failed update leaves every device open to reinstallation of vulnerable firmware.
• One update tool, unrestricted: the server lifecycle tool's credentials can flash every server and are stored in a script. Vault them and limit who can start updates.

Framework mapping

Practitioner checklist

• Inventory system, BMC and component firmware versions per model, refreshed at least monthly.
• Name firmware in the patch policy with an owner and severity-based deployment targets.
• Use only signed update channels and keep firmware rollback protection enabled.
• Run firmware in separate rings per hardware model, with manual approval for BIOS and UEFI updates.
• Escrow BitLocker recovery keys before piloting, and limit suspension to the restarts the update needs.
• Verify the installed firmware version after restart before marking a device compliant.
• Update BMC firmware from an internal repository over an isolated management network.
• Vault and rotate the credentials used by lifecycle and update tools, and restrict forced or downgrade updates.
• Track Secure Boot database updates alongside BIOS versions.
• Report firmware currency and time to deploy by model and by clients, servers and BMCs.

Standards and references

• NIST: SP 800-147 BIOS Protection Guidelines
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• DMTF: Redfish Firmware Update White Paper (DSP2062)
• Microsoft: Windows UEFI firmware update platform
• Microsoft: Intune Windows driver update policies
• Microsoft: Suspend-BitLocker
• LVFS: Introduction to the Linux Vendor Firmware Service
• fwupd: Host Security ID specification

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Patch Management Guide · Secure Boot Certificate Expiry 2026 · Firmware and Bootkit Compromise Playbook