What Is a BIOS Update? The 2026 Guide for IT Teams and MSPs

Updated: October 2026

A BIOS update rewrites the firmware that starts a computer before Windows ever loads. On one machine it's a ten minute job with a progress bar. On four hundred machines under contract it's a policy question, and 2026 made that question sharper than it's been in a decade.

TL;DR

• What it is. A BIOS update replaces the code on your motherboard's firmware chip, the layer that runs before the operating system starts.
• What it fixes. Boot bugs, CPU and memory compatibility, thermal behaviour, and firmware security holes that antivirus can't see.
• The 2026 change. Microsoft's 2011 Secure Boot certificates expire across June and October 2026, and some machines need an OEM firmware update to accept the replacements.
• At scale. Inventory first, pilot ring second, never on battery, and never blind.

What a BIOS Update Is

Every computer runs a small program before it runs anything else. That program wakes up the CPU, counts the RAM, finds the storage, and hands control to Windows or Linux. It lives on a chip soldered to the motherboard, separate from the hard drive, which is why wiping a machine doesn't touch it.

That program is the BIOS. Strictly speaking, almost nothing sold since about 2012 uses the original BIOS anymore. The modern replacement is UEFI, short for Unified Extensible Firmware Interface, and it handles bigger disks, faster boots, and signed code. Everybody still calls it the BIOS, vendors included, so this guide does too.

A BIOS update is the process of writing new firmware onto that chip. The vendor publishes a file, a utility copies it over the old code, the machine restarts, and the pre-boot layer behaves differently afterwards. The industry word for it is flashing, a holdover from the flash memory the chip is built on.

The distinction that matters: this isn't a Windows update and Windows can't fix it. Patch Tuesday touches the operating system. Firmware sits underneath, in its own world, with its own version number and its own update path from whoever made the motherboard.

What a BIOS Update Changes

Vendors ship firmware updates for four reasons, and it's worth knowing which one you're installing.

Hardware support is the most common. A motherboard released in 2024 doesn't know about a CPU released in 2026. The silicon is compatible, the firmware isn't, and the machine won't post until the firmware learns the new chip's identifiers. The same applies to memory kits, fast NVMe drives, and the microcode Intel and AMD ship to patch their own processors.

Stability fixes come second. Random reboots, USB ports that drop devices, a laptop that won't wake from sleep, fans that scream at idle. Plenty of complaints that look like Windows problems are firmware problems, and the release notes will say so in one terse line.

Then there's performance and power behaviour, which mostly means memory timings and thermal limits. This is the category the enthusiast forums care about and the one that matters least in a managed fleet.

The fourth reason is security, and it's the one that's grown teeth. Firmware ships with vulnerabilities like any other code, and the fix arrives as a BIOS update or it doesn't arrive at all.

How to Check Your BIOS Version

Before deciding anything, find out what's installed. On Windows, open Command Prompt and run wmic bios get smbiosbiosversion, or press Windows and R, type msinfo32, and read the BIOS Version/Date line. Both give you a version string and a date.

That date is the useful part. Firmware from 2019 on a machine still in production tells you the update path was never set up, not that the vendor stopped caring.

Next, match it against what the manufacturer publishes. Every OEM has a support page keyed to the service tag or the motherboard model, and the release notes list what changed between your version and the current one. Those notes are the whole decision. A release that fixes a wake-from-sleep bug you've never hit is not urgent. A release that says it addresses a Secure Boot certificate update or a published CVE is a different conversation.

For a fleet, checking one machine at a time stops working somewhere around the fiftieth device. The same wmic and msinfo32 calls run fine from a script, so the version string is cheap to collect. What's expensive is the comparison, because knowing a laptop runs firmware 1.14.0 tells you nothing until you know the vendor shipped 1.23.0 eight months ago. That's an inventory problem before it's a patching problem, and it belongs in the same system that already tracks your IT asset lifecycle.

How the Update Gets Installed

There are three routes, and they've converged a lot in the last few years.

The vendor utility is the modern default. Dell Command Update, HP Image Assistant, Lenovo System Update and their equivalents run inside Windows, pull the right file for that exact model, and stage the flash for the next reboot. No USB stick, no keystroke timing. For managed hardware this is the route that scales, because those same utilities accept command line switches and can be driven from a script.

The firmware's own updater is the fallback. You drop the file on a FAT32 USB stick, reboot into the BIOS setup screen, and point the built-in tool at it. ASUS calls it EZ Flash, MSI calls it M-Flash, Gigabyte calls it Q-Flash. It works when Windows won't boot, which is precisely when you tend to need it.

The third route is Windows Update itself. Many OEMs now publish firmware through it as a driver package, so some machines quietly update their own BIOS with no technician involved. That's convenient on a home laptop and complicated in a managed environment, because it means firmware can change on a client device without anyone scheduling it.

Whichever route, the machine reboots into a state where it's rewriting its own startup code, shows a progress bar, and restarts once or twice. Two to five minutes, and the settings usually reset to defaults.

The Part Where It Goes Wrong

The warning every vendor prints is the same: don't interrupt it. Cut power to a machine halfway through writing its firmware and the chip is left holding an incomplete program. It can't boot, and it can't boot far enough to fix itself. The word for that is bricking.

Modern hardware has made this much rarer. Dual-BIOS motherboards keep a backup chip, and many business laptops can recover from a USB stick if the primary image fails verification. But rare isn't never, and a bricked machine is a desk visit and sometimes a motherboard.

So the rules are dull and non-negotiable. Mains power, not battery. No updates over a flaky remote session where you can't see the screen. Nothing scheduled fifteen minutes before someone needs the machine. Settings get captured first, because the flash resets them, and that includes anything the disk encryption depends on.

That last one is the trap people hit in production. Changing firmware settings can alter the measurements a TPM uses to seal a BitLocker key, and the machine comes back asking for a recovery key nobody has to hand. Suspend BitLocker before the flash, or make sure the recovery keys are escrowed somewhere you can reach at eight in the morning.

Why Secure Boot Made 2026 Different

Here's the thing that turned a maintenance chore into a calendar item.

Secure Boot checks that the code running before your operating system is signed by someone trusted. That trust chains back to certificates Microsoft issued in 2011, and certificates expire. Per Microsoft's Windows IT Pro guidance, the Microsoft Corporation KEK CA 2011 expired on 24 June 2026, the Microsoft Corporation UEFI CA 2011 on 27 June 2026, and the Windows Production PCA 2011 expires on 19 October 2026.

Machines that miss the replacements don't stop booting. What they lose is the ability to receive new signed boot components and updated revocation lists, which is the mechanism that blocks known malicious bootloaders. After October, affected devices stop getting security fixes for the Windows boot loader itself.

Microsoft has been pushing the new certificates through Windows Update since the January 2026 cumulative update, and for most machines it's automatic. The exceptions are the problem. Devices with Secure Boot switched off, models whose manufacturer never shipped the firmware update that accepts the new keys, and machines with known blocking firmware bugs all sit outside the automatic path. Each one needs a human to notice.

Dell, HP and Lenovo have each published guidance on which of their models need a firmware update before the new keys will take, and the lists don't overlap. Checking them is per-vendor work.

That's a firmware inventory question arriving with a deadline, which is exactly the kind of work that gets discovered late.

Firmware Became an Attack Surface

The consumer framing of BIOS updates is performance and compatibility. The security framing is newer and harder to ignore.

Microsoft's Security Signals study, published in 2021 from interviews with 1,000 enterprise security decision makers, found more than 80% had experienced at least one firmware attack in the previous two years, while only 29% of security budgets went to firmware protection. The same study found 82% of respondents said manual work like patching was eating the time they'd otherwise spend on higher-impact security work.

The attacks stopped being theoretical a while ago. BlackLotus, a UEFI bootkit sold on criminal forums for around $5,000, bypassed Secure Boot on fully patched Windows 11. In 2023 the Binarly research team disclosed LogoFAIL, a set of flaws in the image parsers UEFI uses to draw the boot logo, affecting firmware from Insyde, AMI and Phoenix and shipping in hundreds of models from Acer, Dell, HP, Intel, Lenovo, MSI and others. In July 2025, researchers found memory corruption flaws in the firmware of more than 100 Gigabyte motherboard models that allowed persistent bootkit installation.

What links them is the layer they live in. Code that runs before the operating system runs before your endpoint agent too. An EDR product can't inspect what loaded ahead of it, and reimaging the machine doesn't clear it. The patch is a firmware update, which means the fix only lands if somebody is tracking firmware versions in the first place.

NIST wrote the guidance for this in SP 800-193, the Platform Firmware Resiliency Guidelines, which sets out protection, detection and recovery for exactly this layer.

What Changes at Four Hundred Machines

Everything above is true for one computer. Multiply it by a client base and the shape of the problem changes.

Fleets aren't uniform. A typical book of business runs Dell, HP and Lenovo, four hardware generations, a few dozen models, and each one has its own firmware release cadence and its own utility. There's no single update button across that spread, which is why firmware tends to drift for years while the operating system stays current.

Visibility is the harder half. Most remote monitoring platforms report the operating system patch level in detail and say very little about firmware versions, and antivirus doesn't look below the OS at all. So the question "which of our endpoints are running firmware older than the fix for this CVE" often has no answer available from the tools already deployed.

Scheduling is the third constraint. Firmware updates need a reboot, mains power, and a window where the user isn't mid-task. That's a narrower window than a Windows patch, and it's per-client, which means it lands in the same calendar as everything else on the endpoint management side of the house.

A Firmware Policy You Can Run

Firmware doesn't need the monthly cadence the operating system gets. It needs a rule that survives contact with a busy week.

Two habits make the table work. Pilot on a small ring first, five to ten machines per model, and wait a week before the fleet follows. A bad firmware release announces itself within days, and you want it announcing itself on ten machines instead of four hundred. And record the version you decided not to install, with the date, so the next technician inherits a decision instead of a mystery.

The rest is ordinary patch management discipline pointed at a layer that usually gets left out of it: inventory that includes firmware versions, a documented exception list, and the OEM utilities deployed and driven by script rather than by hand.

Where the Tooling Falls Short

Nobody sells a single console that patches firmware across every vendor, because the vendors won't allow it. What good tooling can do is close the visibility gap: report the firmware version on every endpoint, flag the machines behind on a known-vulnerable release, and drive each OEM's own utility from one place instead of three.

That's the practical bar to hold vendors to. Ask whether firmware version is a field you can query and alert on, or whether it's absent from the schema.

Flamingo's OpenFrame is an AI-native all-in-one MSP/IT platform, with RMM, native PSA and security in one place rather than stitched across separate contracts. The positioning worth caring about here is affordability and no vendor lock-in, plus AI agents that do the work instead of suggesting it. It isn't the answer to every firmware problem, because no platform is, but the endpoint data model is the right place for firmware version to live.

The Short Answer

A BIOS update is new firmware for the chip that starts your computer, and most of the time you install one because a vendor fixed something specific you can read in the release notes. Update when there's a named reason. Skip when there isn't, and write down that you skipped it.

At fleet scale the calculation flips. The risk isn't the update, it's the machines nobody has looked at since they were imaged, quietly running 2019 firmware through a year when the certificates underneath Secure Boot expire. Firmware you can't see is firmware you can't patch, and that's the part worth fixing before October.