How to Update Firmware on Everything That Isn't the BIOS

Updated: October 2026

The BIOS gets all the attention, but the SSD, the dock, the network card and the firewall in the comms cupboard all run firmware too. Each one updates a different way, and a couple of them can brick if you get it wrong. Here's how to update firmware across all of it, which tools do the heavy lifting on a fleet, and the handful of rules that keep an update from turning into a site visit.

Firmware Lives in More Than the BIOS

Firmware is the small program baked into a piece of hardware that tells it how to behave. The motherboard has it, and so does nearly everything plugged into it: storage drives, network adapters, Thunderbolt and USB-C docks, keyboards, printers, and every switch, access point and firewall on the network.

Vendors ship firmware updates for the same reasons they ship software updates. They fix bugs, patch security holes, and add support for new hardware. The difference is where the code runs. Firmware loads before Windows does, or runs inside a device Windows barely sees, so your endpoint agent often can't tell you what version is installed.

The motherboard layer has its own guide. If that's the one you're after, our BIOS update guide covers what changes, how to check the version and how to run a BIOS policy. This post is about everything else.

How to Update Firmware on Windows PCs

On a single Windows machine there are two routes, and they overlap.

The first is Windows Update. Hardware vendors can package firmware as a special kind of driver, and Windows installs it through the same pipeline as everything else. Microsoft's own documentation for device makers puts the mechanism plainly: "Because WU can't execute software, the firmware update driver must hand the firmware to Plug and Play (PnP) for installation." In practice, firmware delivered this way shows up in Device Manager under a Firmware category, and in the update history like any driver.

The second is the vendor's own tool. Dell Command Update, HP Image Assistant and Lenovo System Update each know the exact model they're running on and pull firmware for the system, the dock and the storage in one pass. They usually carry updates before Windows Update does, and some firmware never reaches Windows Update at all.

For a fleet, the vendor tools are scriptable. Dell Command Update, for example, lets you choose which categories to install, block specific updates and throttle how they apply. This short walkthrough covers the blocklist and throttling options that matter when you're pushing to hundreds of machines.

Drivers and firmware often ship together in the same tool run. Our guide on updating drivers covers the driver half, including rollback when an update breaks something.

SSDs, Docks and NICs Need Their Own Path

Storage firmware is where a missed update costs data, not just stability. The best-known case is Samsung's 990 Pro. In early 2023 Samsung released firmware 1B2QJXD7 to stop drives reporting an abnormally fast drop in health. As Puget Systems noted in March 2023, the update halted the decline but didn't reverse it, quoting Samsung that "the S.M.A.R.T. values will not be restored to factory settings after the firmware update." Drives that waited longer for the fix kept the damage.

That's the pattern for storage: the fix only protects you from the day it's applied. SSD vendors publish their own update utilities, and the business-line vendor tools above often include the drive firmware for the models they ship. Retail drives bought separately are the ones that slip through.

Docks are the other repeat offender. A dock sits between the laptop and everything else on the desk, so a dock firmware bug looks like a network, display or USB problem. Update the dock with its own vendor utility, and keep the laptop connected to power while it runs. Pulling a dock mid-update is one of the few ways to brick it.

Network adapters usually get firmware through the same vendor tools, or bundled into driver packages. The NIC is worth checking first when a machine drops off the network after sleep, or when a dock's Ethernet port misbehaves on one model and not another.

Network Gear Is Where Firmware Bites

Switches, access points and firewalls run firmware too, and they update through the vendor's own console or management platform, not Windows. They're also the devices attackers go after, because they sit on the edge of the network and rarely run an endpoint agent.

The clearest recent example is Cisco's firewall line. On 25 September 2025, CISA issued Emergency Directive 25-03 for Cisco ASA and Firepower devices after attackers used two zero-day exploits against them. The directive noted that the attacker had "manipulated read-only memory (ROM) to persist through reboot and system upgrade." In other words, updating a compromised box didn't necessarily evict the attacker. CISA's April 2026 update added a hard power-off requirement for affected Firepower and Secure Firewall devices.

Keeping track of which box runs which version is the unglamorous half of the job. In this r/msp thread, an engineer running mostly FortiGate with some Cisco describes checking vendor security advisories against a spreadsheet every month, and missing one by three weeks. The replies point to the vendors' advisory feeds and APIs as the way out.

Both Fortinet and Cisco publish their security advisories as machine-readable feeds. Pull them, match them against your device inventory, and alert only when something you run is affected. That turns a monthly spreadsheet into a notification.

Linux Machines: fwupd and LVFS

Linux has a cleaner story than Windows here. Hardware vendors upload firmware to the Linux Vendor Firmware Service (LVFS), and the fwupd daemon on each machine installs it. The whole flow is four commands:

bash
fwupdmgr get-devices
fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr update

The first lists every device fwupd can see, the second pulls the latest metadata, the third shows what's available, and the last installs it. Updates that can apply live do so at once, and boot-time updates are staged for the next restart. Not every vendor publishes to LVFS, so check your hardware before assuming coverage.

Roll It Out Without Bricking Anything

A firmware update across a fleet is a change, and it deserves the same care as any other change. Three things go wrong most often: BitLocker, power, and a bad release reaching everyone at once.

BitLocker first. A firmware change can make the TPM see a different boot environment, and BitLocker responds by asking for the recovery key. The fix is to suspend BitLocker before the update and let it resume on its own afterwards. In this r/sysadmin thread, a Dell shop reports roughly one machine in ten hitting the recovery screen after firmware updates, even with suspension configured. The most useful reply: some updates restart more than once, so suspend for two reboots, not one.

On Windows that's one line, run before the update: Suspend-BitLocker -MountPoint "C:" -RebootCount 2. If a TPM error turns up afterwards, our TPM troubleshooting guide walks through it.

Then the rollout itself:

1. Check power. Laptops on AC, and no updates scheduled during a known outage window.
2. Suspend BitLocker for two reboots. Let the vendor tool do it, and verify it did.
3. Pilot ring first. A handful of machines per model, left for a few days.
4. Broad ring. The rest of the fleet, once the pilot is clean.
5. Keep a way back. Block the release in the vendor tool or pause it in the update policy the moment something breaks.

On Windows 11 and 10, Microsoft now gives you a central place to do this. Intune driver update policies, used alone or with Windows Autopatch, list firmware alongside drivers and let you approve it manually or automatically per deployment ring. Microsoft's Autopatch documentation lets you defer automatically approved driver and firmware updates by 0 to 30 days per ring, which is the pilot window built in. It needs Intune Plan 1 and a Windows license with the Autopatch entitlement.

For the machines outside Intune, the same rollout runs as a script. OpenFrame pulls live device inventory through osquery, and runs scripts and scheduled scripts across devices with an approval gate before anything risky goes out, so a vendor tool run can follow the same pilot-then-broad pattern.

Keep a List, Then Keep It Current

Firmware updates are dull right up until the one you skipped matters. Know what runs firmware in your estate, use the vendor tools and update policies to push it in rings, suspend BitLocker for two reboots, and keep a way back.

Start with the devices that sit on the network edge and the drives that hold the data. For the patching side of the same job, our patch management software roundup is the next read.