How to schedule a firmware update for equipment on site
Before firmware or BIOS is updated on equipment on site, write the time window, who authorises it, and which image is used if the update fails, then schedule that machine by its identifier. Power and cooling say whether the room can take the equipment. Asset tags say how the identifier is assigned. Return inspection says what is checked on the day a rental comes back. This note says when the firmware is updated.
On this page
- Keep the firmware update apart from power, tags, and returns
- The guide separates protection, detection, and recovery
- Whether an image is authentic, and who may authorise it, are not the same question
- The owner writes the window and the person who authorises it
- Name the image to return to if the update fails
- A remote screen is not the same as a person beside the machine
- Rented equipment still uses the same identifier
- The machine is scheduled when the window, the authorisation, and the images are written
Keep the firmware update apart from power, tags, and returns
Power and cooling answer whether the room's electricity and heat can take this equipment. Asset tags answer how this machine's shared identifier is printed, and which records must use that string. Return inspection answers what is checked, item by item, on the day a rental comes back, and who signs. A firmware update answers a different question: in which window this machine's firmware or BIOS is updated, who authorises it, and which image is used if it fails. The four point at one another with the same identifier. See What to check for power and cooling before equipment is installed, How to assign asset tags for equipment, and How to inspect rented equipment on return.
Measurement limits and maintenance work orders stay with predictive maintenance. See How to do predictive maintenance for equipment. Equipment can be bought, leased, or taken forward with development in the same project. That is the block Buy, lease, or plan it with development on the homepage. This note does not redo the room's power and heat, and it does not redo the return checklist.
The guide separates protection, detection, and recovery
NIST SP 800-193, Platform Firmware Resiliency Guidelines, read on 2 November 2026, was published in May 2018. The author is Andrew Regenscheid. The text says it is available free of charge, runs to 45 pages, and may be used by nongovernmental organizations on a voluntary basis. The guide describes the platform as the fundamental hardware and firmware needed to boot and operate a system. It states three principles: protection, so firmware code and critical data stay intact, including confirming that an update is authentic and intact; detection, when that code or data has been corrupted or has left an authorized state; and recovery, restoring code and critical data to integrity when corruption is detected or when an authorized mechanism forces recovery. Recovery is limited to firmware code and critical data.
The guide says it is aimed mainly at platform resiliency against remote attacks, and that the earlier SP 800-147 addresses host boot firmware, commonly called BIOS, including conventional BIOS, EFI, and UEFI. This note records that scope on the cover. If this machine is the boot firmware of a personal computer or a server, it is BIOS. If it is other platform-device firmware, it is platform firmware as SP 800-193 uses the term. Site equipment that matches neither has "not applicable" on the cover. The signature clauses are not used to fill in an update that has no image.
Whether an image is authentic, and who may authorise it, are not the same question
The guide says a central point of firmware protection is that only an authentic and authorized update image may be applied to a platform device. An image is authentic when its source and its integrity can both be verified. The technical process that verifies an image before it is applied is an authenticated update mechanism. Authorization is the permission to perform the update. Authentication is typically rooted in the device or system manufacturer. Authorization is typically rooted in the owner.
Section 4.2.1.1 says that, absent unambiguous physical presence through a secure local update, an authenticated update mechanism anchored in the root of trust for update shall be the exclusive means of updating device firmware. It also says an update image shall be signed with an approved digital-signature algorithm, and that the signature shall be verified by a root or chain of trust before the update is committed to non-volatile storage. On this machine's row the company records the image identifier, whether a signature was verified, and who verified it. If the manufacturer provides no signature, the row says "no signature". The update is not recorded as having used an authenticated update. The guide does not say the update must finish within a stated number of hours.
The owner writes the window and the person who authorises it
The guide places authorization with the owner. It does not set the length of a window. For this machine the company writes when the window starts and ends, the time zone, who is present, and which systems may keep running during that time. A window with no start and no end is not scheduled. The authorising person's name and the date of agreement go on the same row. If the name is blank, the window does not take effect.
Section 3.5.2 lists authorized ways to update an image, including a user-initiated update, a managed remote update, rollback to an earlier version, manual recovery by someone present during boot, and automatic recovery from a backup image stored apart from the damaged one. Those are the guide's categories for a platform. They are not a requirement that every piece of site equipment support all five. The row records which one this update uses. One that does not apply is marked "not applicable". A remote update by an administrator still needs the authorising person. A tool that can send the update remotely does not drop the signature.
Name the image to return to if the update fails
The guide says an implementation that verifies an update before applying it may also check version numbers. Rollback to older firmware may have its own process, for example requiring the user to be present, so that an attacker cannot install an old image with a known weakness. Automatic recovery, when an image is corrupt, restores from a backup kept apart from the damaged image. The guide's examples include a second flash chip, or a protected region of a storage device.
The company writes the identifier of the image to use if the update fails, where that image is kept, and who may authorise the switch to it. That image is not the new image about to be installed. If the identifier is blank, the update does not start. If a rollback to an older version is to be done, the reason is written separately, including whether someone must be beside the machine. The guide says presence might be required. It does not set that rule for every update the company runs. The company's own choice is written on the row and dated.
A remote screen is not the same as a person beside the machine
Section 3.5.3 says a secure local update authorises the change by unambiguous physical presence, rather than by a signature. A remote method such as a remote console does not meet that requirement for presence. A method that malware on the system can imitate does not meet it either. The guide also says a device that implements local update can still be affected by someone with physical access, and that further physical protection is outside the guide.
If this update is marked as requiring presence, the authorising person signs beside the machine during the window. Confirmation on a remote screen does not replace that signature. If it is marked as a remote administrator update, it is not also marked as presence having been met. If both are blank, the update is not scheduled. Who is present is written beside the authorising person. It may be the same person. The two fields stay separate.
Rented equipment still uses the same identifier
Whether the machine is owned or rented, the update row uses the shared identifier on the asset tag. See How to assign asset tags for equipment. Another machine of the same model is not folded into this row. If the identifier does not match, the row says "identifier not matched", and the update does not start.
If the rental contract says the lessee may not update firmware, that sentence stays on the contract. This page only records whether the authorising party is the company or the lessor. If that party is blank, the update is not scheduled. The check on the day of return still follows return inspection. See How to inspect rented equipment on return. If an update was done during the hire, the return record may point at this row's image identifier. The firmware steps are not copied into the return checklist. The room's power and heat stay with the power-and-cooling note. A restart of this machine does not rewrite that room check.
The machine is scheduled when the window, the authorisation, and the images are written
If the window has no start and end, if the authorising person is unnamed, if the new image has no identifier, or if the image for a failure has no identifier, this machine is not put on the schedule. Equipment marked "not applicable" on the cover does not gain an invented image name in order to fill a row.
Three checks show the update was scheduled: the window and the authorising person have a date; whether the new image has a signature is written; and the failure image and where it is kept are on the same row. A blank item leaves the machine on its current firmware. The update is not done outside the window to fill the gap.