What Actually Happens When You Click 'Update' on Firmware
The progress bar is the least informative part of a firmware update. It moves at a rate that has almost nothing to do with the work being done, it frequently sits at the same percentage for two minutes, and the warning attached to it says not to power off the device without ever explaining what would break if you did. Here is what the sequence actually consists of, and where it can go wrong.
The click starts a download, not an update
Whatever you pressed hands off to a host-side updater: fwupd on Linux, the Windows Firmware Update driver, a vendor tool, or a web utility talking to a USB device. That process fetches an image file. The image is not raw flash contents. It’s a container with a header describing the target hardware, a version number, a payload that is often compressed, and a signature block.
Before anything touches the device, the updater checks that the image is meant for this hardware. Vendors gate this on board ID, silicon revision, region code and sometimes the specific SKU. This check exists because flashing a structurally valid image intended for a different board is one of the reliable ways to produce a device that cannot boot far enough to be fixed by software.
Verification happens on the device, not on the host
The host-side check is a convenience. The check that matters happens on the target, against a public key that was written into one-time-programmable fuses or masked ROM at manufacture. That key is the root of trust. It cannot be replaced by anything the operating system can do, which is the entire point of putting it there.
The device verifies the signature over the payload, and in most modern designs also checks a monotonic counter. Anti-rollback works by burning a fuse each time a security version increments. Once the counter has moved, images built against lower versions fail verification permanently. This is why the folk remedy of downgrading to the previous release often does not work on newer hardware. The device is not refusing out of policy. It physically cannot accept the older image.
Getting into a state where flash can be written
Code cannot generally execute from a flash region while that region is being erased. This constraint shapes the whole process.
On a PC, a UEFI capsule update solves it by deferring. The updater stages the capsule on the EFI system partition, sets a variable telling firmware that an update is pending, and requests a reboot. On the next power cycle, before any operating system loads, firmware processes the capsule from a small resident routine running out of SRAM or a protected region. That is why a firmware update requires a reboot, and why the real update happens on a screen you barely see rather than in the application where you clicked the button.
On embedded devices, the equivalent is entering a bootloader or DFU mode, where a minimal resident loader handles reception and writing while the main application is not running.
Erase, then write, and erase is the slow part
NOR flash, which is what most boot firmware lives in, can only clear bits in blocks. Writing is fast. Erasing a sector is orders of magnitude slower, and the granularity is fixed by the part, commonly four kilobytes or sixty-four kilobytes. Updating a single byte means erasing and rewriting the entire block containing it.
That accounts for the progress bar behaviour. The apparent stalls are erase cycles. The fast sections are the writes that follow them. Nothing is hung.
Two designs, very different risk profiles
Dual-bank, sometimes called A/B: the device has room for two complete images. The update is written to the inactive bank while the active one continues running. When the write completes and verifies, a pointer flips atomically and the device boots the new bank. Good implementations add a confirmation step, where the new image must check in with a watchdog within some window or the pointer reverts. This design is why phones and modern SSDs update with essentially no bricking risk.
In-place: there is one copy, and it is being overwritten. Between the first erase and the final verified write there is a window where the device holds neither a complete old image nor a complete new one. Interrupt power in that window and there is nothing to boot. This is what the warning is about, and it is the design still used in plenty of cheap hardware, some motherboard firmware, and a great deal of peripheral silicon.
A single update is usually several updates
What a vendor calls a BIOS update frequently contains payloads for the embedded controller, the management engine, the Thunderbolt or USB4 retimer, the TPM, the power delivery controller, and sometimes the battery gas gauge. Each targets a different processor with its own flash, its own signing key and its own update protocol.
They flash sequentially, which is why a machine may reboot three or four times during what looked like one operation. It also means partial success is possible: the main firmware updates, a companion controller fails, and the system boots into a state where two components disagree about protocol versions. Symptoms of that look like hardware faults, not like a failed update.
What survives, and what does not
Configuration lives in NVRAM variables that are usually preserved. Usually. Updates that change the variable layout will reset settings to defaults, which includes boot order, virtualisation toggles and fan curves. On systems with Secure Boot, enrolled keys normally persist, but firmware updates are one of the few things that legitimately modify the key databases, so a machine that stops booting a self-signed loader after an update is behaving as designed rather than failing.
Recovery when it does not come back
Boards with dual firmware chips hold a factory image on the second one and switch automatically after failed boot attempts. Many laptops implement a crisis recovery mode that reads a specifically named file from the root of a FAT-formatted USB stick when a key combination is held at power-on, and the file name is exact.
Below that, recovery means hardware. A SPI flash clip and a cheap programmer can rewrite a soldered chip in place if the board is cooperative about power isolation. That is a normal repair procedure, not an exotic one, and it’s worth knowing whether a given device supports it before buying it in quantity.
The one useful habit
Read what the update actually changes before applying it. Firmware releases mix security fixes, silicon errata workarounds and feature changes, and the third category is where regressions live. On hardware with anti-rollback, the decision to apply an update is not reversible, and that changes the calculation from “update everything by default” to “update deliberately.”