BIOS, ME and SSD firmware: when updating is worth the risk

Verified 2026-10-293 min read

A decision rule for firmware updates, the order to do them in, and the BitLocker/TPM steps that prevent a recovery prompt.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Method

The short answer

Update firmware when it fixes something you can name:

a security advisory affecting your board/CPU (microcode),
a compatibility fix (memory kit, NVMe, GPU, Thunderbolt device),
a stability bug you have actually observed,
a CPU support addition you need.

Do not update because a version number is higher. Every flash is a small bricking risk and a BitLocker recovery prompt waiting to happen.

What “firmware” means on a PC

Component	Update path	Risk
BIOS/UEFI	vendor tool or built-in flash from USB	bricking on power loss
ME/PSP (management engine)	bundled with BIOS on most boards	same as BIOS
SSD/ NVMe firmware	vendor tool, live update	data loss if interrupted
TPM firmware	bundled with BIOS/firmware	can clear TPM state
Dock / peripherals	vendor tool	usually low risk
NIC / RAID controller	vendor tool, often reboot-required	low, but verify driver pairing

Server hardware adds BMC (iDRAC/iLO) firmware, which is separate from BIOS and has its own update path.

Before you flash

Back up — at minimum the recovery key and anything irreplaceable.
Suspend BitLocker if enabled:

Suspend-BitLocker -MountPoint C: -RebootCount 1

Record the current versions so you can prove what changed:

Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion,ReleaseDate,Manufacturer
Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer,Product,Version
Get-PhysicalDisk | Select-Object FriendlyName,FirmwareVersion,HealthStatus
Get-Tpm | Select-Object TpmPresent,TpmReady,ManufacturerIdTxt

Read the release notes — some BIOS updates remove features, reset settings, or require an intermediate version first.
Power: laptop on AC with a charged battery; desktop on a UPS if you have one. A flash interrupted by power loss is the one failure mode with no software fix.

The order that avoids surprises

Suspend BitLocker, note versions.
Update BIOS/UEFI (this usually includes ME and microcode).
Reboot, enter firmware, re-apply your settings (TPM, Secure Boot, XMP, fan curve) — updates often reset them.
Verify from Windows: Confirm-SecureBootUEFI, Get-Tpm, $env:firmware_type.
Update SSD firmware if the vendor lists a fix that affects you.
Update docks/peripherals last.
Resume BitLocker, confirm manage-bde -status shows protection on.

SSD firmware specifics

Update only from the vendor’s own tool, with the drive’s model confirmed.
A firmware update can change how the drive behaves under power loss; read the changelog.
Interrupting an SSD firmware update can leave the drive in a state that needs vendor recovery — do it on a laptop with a battery, or a desktop with a UPS.
After updating, re-check SMART and run a short write test before trusting it with data.

Server and BMC firmware

BMC first or BIOS first? Vendor guidance varies; follow the server vendor’s order, not a blog’s.
BMC updates can reset network settings and credentials — record them.
Some platforms require staged updates (update to X before Y).
Firmware updates on servers often reset Secure Boot/TPM settings; document before, verify after.

When not to update

The machine is stable, out of warranty, and the update fixes nothing you can name.
You cannot guarantee power for the duration.
The vendor’s release notes mention a regression on your exact model.
You have no way to recover if it fails (no second BIOS, no programmer, no service option).

Lab boundary

E1. Update paths and BitLocker behaviour are documented by Microsoft and hardware vendors. The lab updates firmware only in VMs (OVMF/vTPM), so no physical flash was performed.