GPU server firmware updates: vBIOS, BMC and BIOS, where each comes from and in which order

Firmware layers in a GPU server

A GPU server's firmware is updated layer by layer: the BMC, the system BIOS, the GPU vBIOS and the firmware of network cards, drives and power supplies. Server makers publish the BMC and BIOS releases, Dell's support site lists GPU firmware per GPU model, and NVIDIA's MIG guide sends vBIOS questions to "your reseller or system provider". Update one node at a time with its workloads drained, the BMC first, and stop all GPU activity before a vBIOS update.

The layers differ in what they control and in who builds the release you install.

Our summary of the sources in the sections below, read on 24 October 2026. NVIDIA's DGX OS guide matches ConnectX firmware to the adapter's version, OPN and PSID.

The number of components is larger than most inventories show. NVIDIA's Redfish documentation for its own DGX B300 names, on the motherboard tray alone, the BMC, the BIOS, two external roots of trust for them, two CPLDs, twelve power supplies and two Gen5 PCIe switches as separate update targets. A PCIe server from another maker has its own list, set by that maker, on the same principle: each component has its own version, and the maker's bundle sets which versions belong together.

Where each update comes from

For the BMC and the system BIOS, the source is the server maker. The BMC firmware may be built on a commercial base such as AMI's MegaRAC, and the BIOS on AMI's Aptio, but the release you flash is the maker's build for that board. When AMI publishes an advisory, the question for the server maker is which of its own releases contains the fix, as our guide to securing a GPU server describes.

For PCIe GPUs the path is less obvious, because the card comes from NVIDIA and the server from someone else. NVIDIA's MIG user guide, updated on 13 October 2026, answers it for vBIOS updates: "If a vBIOS update is needed, contact your reseller or system provider for assistance." Dell's support article "PowerEdge: GPU firmware update considerations", modified on 2 September 2026, shows the server-maker side: GPU firmware is found on Dell's support site under the GPU model, and "For some models, the firmware update instructions are a separate download". The update package then states its own steps, reboot and prerequisites.

The card itself also has an out-of-band path. NVIDIA's product brief for the RTX PRO 6000 Blackwell Server Edition, SP-12355-001_v02, says the card "supports GPU out-of-band telemetry and firmware updates through SMBus and USB 2.0", as our article on out-of-band GPU monitoring through the BMC quotes. Whether a given BMC uses that path for a firmware update is stated in the server maker's documentation for the model, not in NVIDIA's brief.

On NVIDIA's own systems, NVIDIA publishes everything. For the DGX B300, firmware comes as bundles for the motherboard tray and the GPU tray, applied with NVIDIA's nvfwupd tool from the NVIDIA Enterprise Support Portal; our guide to DGX OS 8 on the DGX B300 lists the current versions.

We build AI servers to order on server platforms with manufacturer warranty on every component, assembled and tested before delivery; tell us which servers and cards you run or plan, and our team replies with a configuration within one business day.

Reading the versions before you change anything

Every update starts with an inventory, so that the result can be compared afterwards and a card with a different version stands out. NVIDIA's MIG guide uses nvidia-smi --query-gpu=vbios_version with --format=csv to read the vBIOS. The full query, nvidia-smi -q, shows more fields; NVIDIA's nvidia-smi documentation defines them.

NVIDIA nvidia-smi documentation (GPU attributes), NVIDIA MIG user guide "Getting Started with MIG" (updated 13 October 2026) and DMTF Redfish schema UpdateService v1.17.1 (release 2025.3), read on 24 October 2026.

nvidia-smi needs the driver; the BMC does not. Under /redfish/v1/, the UpdateService's FirmwareInventory lists the firmware the BMC knows about; NVIDIA's DGX B300 documentation reads its component versions there. On PCIe servers the depth varies: Supermicro's X14/H14 BMC manual documents a GPU tab with model, serial number and firmware version, which is useful when an update reached only some of the cards. Save both views with the server's name and date. Our guide to GPU server acceptance testing records them at delivery and expects identical cards bought together to report identical versions, and identifying a faulty GPU by bus ID, slot and serial maps each line to a physical card.

Why the vBIOS matters: MIG, signed firmware, identical cards

The most common reason to touch a GPU's vBIOS is a feature. NVIDIA's MIG guide lists minimum vBIOS versions for three RTX PRO Blackwell cards, on top of the driver floor of 575.51.03 for the RTX PRO 6000 in all editions and the RTX PRO 5000.

NVIDIA MIG user guide, "Getting Started with MIG", updated 13 October 2026, read on 24 October 2026. Display mode is switched with DisplayModeSelector 1.72.0 or later.

The guide lists no vBIOS minimum for the Server Edition or the RTX PRO 4500, so for those cards the driver is the documented requirement. For the Workstation Edition and the Max-Q, check the vBIOS before you plan MIG on them. Our RTX PRO 6000 MIG profiles show what fits in each instance size.

The second reason is integrity. In NVIDIA's H200 NVL product brief, the card's CEC device "authenticates the contents of the GPU firmware ROM before permitting the GPU to boot from its ROM", with rollback protection and key revocation. On the DGX B300, "Secure Flash is implemented … to prevent unsigned and unverified firmware images from being flashed onto the system." Take GPU firmware only from the server maker or NVIDIA; on a card with this protection, a ROM that fails authentication is not booted.

The third reason is consistency. A server whose eight cards report three vBIOS versions after a partial update no longer meets the acceptance criterion of identical versions on identical cards, and the difference has to be explained before the next update.

BMC and BIOS releases are security updates

CVE-2024-54085 shows why. The NVD record describes it as a flaw in which "AMI's SPx contains a vulnerability in the BMC where an Attacker may bypass authentication remotely through the Redfish Host Interface". AMI scores it 10.0 under CVSS 4.0, NIST 9.8 under CVSS 3.1. CISA added it to its Known Exploited Vulnerabilities Catalog on 25 June 2025 with a due date of 16 July 2025 for US federal agencies and the required action "Apply mitigations per vendor instructions". AMI's advisories of 8 September and 13 October 2026 list further flaws in its Aptio V BIOS, among them CVE-2026-33197, scored 8.7 by AMI.

A BMC on an isolated management network limits who can reach it, and the patch still has to be installed. NVIDIA's configuration guide for NVIDIA-Certified Systems, updated on 30 September 2026, lists Redfish 1.0 or later and a TPM 2.0 with Secure Boot among its requirements, so these servers are managed through the BMC in any case. Compare the BIOS configuration before and after each update, as the procedure below does; if Secure Boot settings change, our guide to the NVIDIA driver with Secure Boot explains how the driver's signing key is trusted.

The Redfish UpdateService

Redfish, DMTF's management standard, defines a standard update interface for BMCs. In the UpdateService schema, version 1.17.1 of release 2025.3, the SimpleUpdate action "updates software components" from an image the BMC fetches; MultipartHttpPushUri is the URI for "a Redfish Specification-defined multipart HTTP or HTTPS push update"; the older HttpPushUri "has been deprecated in favor of the MultipartHttpPushUri property". Targets is "An array of URIs that indicate where to apply the update image", and ForceUpdate tells the service whether to "bypass update policies".

Makers fill this standard in their own way. On the DGX B300, NVIDIA's documentation posts the firmware file to an upload endpoint with a JSON file naming the target, and states: "The DGX B300 system component firmware is only updated if the incoming firmware version is newer than the existing version." Re-flashing the same release or rolling back therefore needs ForceUpdate set first. Other makers document their own update paths per BMC generation; read them for the server model, since targets and package formats differ.

An update order that keeps the service running

NVIDIA publishes a complete sequence for its DGX B300, updated on 22 September 2026. It shows how the layers depend on each other:

1. Compare the installed firmware with the bundle, using show_version.
2. Back up the BMC configuration, then update the BMC and reset it.
3. Update the motherboard tray components; those already at the bundle's version are skipped.
4. Update the GPU tray, VBIOS, NVSwitch, ERoT and FPGA in parallel, after stopping all GPU activity.
5. Run an AC power cycle, then read the versions again.

Two warnings in it are worth carrying over to other GPU servers. GPU activity, nvidia-smi included, can block the VBIOS update, and "A high workload can disrupt the firmware update process and result in an unusable component." On a BMC older than 01.00.00, the AC power cycle needs the restore-to-defaults option, which resets the BMC settings and the credentials to admin/admin, so the BMC's address and password must be set again at once.

For a PCIe server, the same logic gives a procedure per node:

1. Read the release notes of the maker's bundle and of the NVIDIA driver you run, and note any minimum versions between them.
2. Drain the node: move its models or jobs to another node, as our guide to high-availability LLM inference on two nodes describes.
3. Stop GPU workloads and anything that polls the GPUs, including dcgm-exporter and scripts that call nvidia-smi.
4. Save the BMC and BIOS configuration and the inventory.
5. Update the BMC first, then the BIOS and board components, then the GPUs, with the reboots or power cycles the maker states.
6. Read the inventory again, compare versions across identical cards, and check the BIOS settings.
7. Bring the GPU stack back: driver, power caps and MIG layout, then return the node to service.

Step 7 matters because some settings do not survive. NVIDIA's product briefs state that a power cap set with nvidia-smi "must be reestablished after each new driver load", and on Hopper and later GPUs, NVIDIA's MIG guide says, MIG mode "is only persistent as long as the driver is resident in the system", so both are reapplied after the reboot. If the driver itself changes in the same window, the rules of our NVIDIA driver branches guide apply, with the vGPU Manager on a host before the guest drivers.

We found no general NVIDIA rule on whether firmware or driver goes first on a PCIe server. On DGX systems the answer is in the OS release notes, which list a firmware release next to each system; on other servers the maker's bundle notes are the place to look.

How often to update

A policy needs two speeds. Security releases for the BMC and BIOS, and GPU firmware that a maker marks as a fix, follow the advisory: a flaw in CISA's catalogue or a high score from AMI or NVIDIA is a reason for the next maintenance window. Feature releases, a newer vBIOS for MIG or a BIOS for a new card, are installed when the feature is needed and tested on one node first.

NVIDIA's DGX OS release guidance calls keeping software and firmware current "the most important task for protecting your DGX systems". Its DGX B300 firmware guide lists eight releases from 25.11.1 to 26.09.1, which gives an idea of how often a GPU platform changes. Over a five-year life, as our GPU server lifecycle guide plans it, that is many maintenance windows; recording versions per server after each one keeps the fleet comparable.

What we supply

You can buy GPU servers from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order with two to eight GPUs, assembled and tested before delivery, on one EU contract and invoice with manufacturer warranty on every component, and install the operating system, drivers, CUDA and a container runtime on request. Send us the server models and the GPU firmware versions you see, and we answer with a configuration for your next servers.

FAQ