# BIOS and firmware updates by vendor: Dell, HP and ASUS

> Three vendor toolchains, the order of operations that avoids a bricked board, and how to verify the version actually changed after the reboot.

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

Firmware updates fix real problems (memory training, USB/TB stability, security advisories) and carry one real risk: **the machine must not lose power mid-flash**.

The safe pattern is the same for all three vendors:

1. **Record the current version** (so you can prove it changed).
2. **Suspend BitLocker** if the drive is encrypted.
3. **AC power, no battery-only**, close every other app.
4. Flash with the vendor tool.
5. **Verify the version** after the reboot; confirm BitLocker protection came back.

Vendor toolchains differ. Dell and HP ship a Windows agent that also handles drivers; ASUS expects you to flash from the UEFI itself or with its own utility.

## Before you start

```powershell
# current firmware and board identity
Get-CimInstance Win32_BIOS | Select-Object Manufacturer,SMBIOSBIOSVersion,ReleaseDate,Version
Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer,Product,Version
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer,Model,SystemFamily
# is BitLocker on?  (Pro/Enterprise; Home lacks manage-bde)
manage-bde -status C:
```

Write the `SMBIOSBIOSVersion` down. After the update it should change — that is your only reliable proof, because the vendor UI will happily say "up to date" while reporting the old version.

> **Caution: Suspend BitLocker before the flash**
>
> A firmware update can change the measured boot state and trigger a recovery prompt on the next start. Suspending for one or two reboots avoids a surprise at the worst moment — and you still need the recovery key in hand. See [the BitLocker drill](https://winbook.fyi/en/windows/hardening/bitlocker-recovery-drill/).

```powershell
Suspend-BitLocker -MountPoint C: -RebootCount 2
```

## Dell — Command Update

Dell's tool is a single agent that inventories the machine, then offers BIOS, driver and firmware packages together.

| Step | Action |
|---|---|
| 1 | Install **Dell Command \| Update** from Dell's support site for your service tag |
| 2 | Run a **Check** — it lists BIOS plus driver updates with criticality |
| 3 | Install **BIOS first** if both BIOS and chipset appear, then reboot |
| 4 | Re-run Check to catch anything that depended on the new BIOS |

Notes that matter:

- Dell may **block downgrades** after a certain version; check the release notes before updating a stable machine.
- Command Update can be scheduled, which is convenient and also how a fleet reboots itself at 3am. If you schedule it, control the maintenance window.
- The service tag is the identity — driver pages keyed to the model alone can offer the wrong package.

## HP — Image Assistant / SoftPaqs

HP splits the job: **HP Image Assistant** analyses the machine and produces a SoftPaq list; individual **SoftPaqs** are the packages. BIOS is delivered as a SoftPaq that runs a flash utility.

| Step | Action |
|---|---|
| 1 | Install HP Image Assistant (or use HP Support Assistant for single machines) |
| 2 | **Analyze** — it reports recommended vs critical updates |
| 3 | Install the **System BIOS** SoftPaq, allow the reboot |
| 4 | Re-analyze; ME/EC firmware often follows the BIOS |

Notes:

- HP's flash utility asks for confirmation and may require the **BIOS administrator password** if one is set.
- Some business models expose **"BIOS rollback"** in the UEFI; consumer models often do not.
- **HP Sure Start** (business) can self-heal a corrupted BIOS — a genuine safety net, not a licence to flash carelessly.

## ASUS — EZ Flash / USB BIOS FlashBack

ASUS expects the firmware file, not an agent:

| Method | When |
|---|---|
| **EZ Flash 3** in UEFI | normal path: copy the `.CAP` to a FAT32 USB stick |
| **USB BIOS FlashBack** | the board will not POST — flashes without CPU/RAM on supported boards |
| **Armoury Crate / MyASUS** | convenience path on laptops and some boards |

Procedure:

1. Download the BIOS for the **exact board model** (not the series) from ASUS support.
2. Extract the `.CAP`; many boards require renaming via the bundled renamer.
3. Format a USB stick **FAT32**, copy the file to the root.
4. Enter UEFI (`Del` at POST) → **Tool → ASUS EZ Flash** → select the file.
5. Do **not** power off during the flash; the board reboots itself, sometimes twice.

Notes:

- **Do not cross-flash** a different model's BIOS, even from the same series.
- A BIOS update on AM5/LGA1700 platforms can reset **XMP/EXPO, fan curves and boot order** — re-check them afterwards.
- FlashBack needs the file in the specifically named USB port, usually marked on the rear I/O.

## After the flash: verify

```powershell
Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion,ReleaseDate
Confirm-SecureBootUEFI
Get-BitLockerVolume | Select-Object MountPoint,ProtectionStatus,KeyProtector
```

Checklist:

- [ ] Version string changed
- [ ] Secure Boot still `True`
- [ ] BitLocker back to `Protection On` (not `Suspended`)
- [ ] XMP/EXPO and fan curves re-applied
- [ ] Boot order unchanged
- [ ] TPM still owned and ready (`Get-Tpm`)

If BitLocker is still suspended, `Resume-BitLocker -MountPoint C:`.

> **Danger: Firmware updates are not a troubleshooting step**
>
> Do not flash firmware to fix a random crash. Update when there is a specific fix, a security advisory, or a hardware compatibility requirement — and never on battery, never with a pending Windows update, never mid-backup.

## Related

- [UEFI settings that matter](https://winbook.fyi/en/hardware/build/uefi-settings/)
- [Firmware updates: the general rules](https://winbook.fyi/en/hardware/build/firmware-updates/)
- [BitLocker recovery drill](https://winbook.fyi/en/windows/hardening/bitlocker-recovery-drill/)

## Lab boundary

E1. The vendor toolchains are documented by Dell, HP and ASUS; the version-check commands are Microsoft-documented. This lab is a Proxmox host with no physical Dell/HP/ASUS machine, so no flash was performed.

## Sources

- [Microsoft Learn — Bring up (firmware and UEFI)](https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/)
- [Microsoft Learn — Windows Performance Toolkit](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/)
- [HP Support](https://support.hp.com/us-en)
- [ASUS Support](https://www.asus.com/support/)

---

Source: https://winbook.fyi/en/hardware/build/firmware-vendors/