Key takeaways
- NIST SP 800-147, "BIOS Protection Guidelines," is the original free, vendor-neutral NIST reference for stopping unauthorized modification of a PC's system firmware.
- Section 3.1 requires that "all updates to the system BIOS shall either go through an authenticated BIOS update mechanism...
- Section 2.5 walks through the realistic attack paths against a deployed BIOS.
- Platform Deployment Phase — install the approved BIOS from the golden image using the secure local update mechanism, with the RTU and configuration parameters established, before the system is deployed.
NIST SP 800-147, "BIOS Protection Guidelines," is the original free, vendor-neutral NIST reference for stopping unauthorized modification of a PC's system firmware. Authored by David Cooper, William Polk, Andrew Regenscheid and Murugiah Souppaya of NIST's Computer Security Division, it was published as Final in April 2011 and has not been revised since, though it remains listed as active/Final on NIST's own publication page rather than withdrawn. Its Executive Summary states the threat plainly: "unauthorized modification of BIOS firmware by malicious software constitutes a significant threat because of the BIOS's unique and privileged position within the PC architecture. A malicious BIOS modification could be part of a sophisticated, targeted attack on an organization — either a permanent denial of service (if the BIOS is corrupted) or a persistent malware presence (if the BIOS is implanted with malware)." As a U.S. government work prepared under NIST's FISMA authority, SP 800-147 "is not subject to copyright, though attribution is desired," and is mandatory guidance for U.S. federal agencies while usable voluntarily by anyone else.
Scope: what counts as "BIOS," and what this document does not cover
Section 1.2 defines BIOS broadly to track the industry's own terminology shift: "the term BIOS refers to conventional BIOS, Extensible Firmware Interface (EFI) BIOS, and Unified Extensible Firmware Interface (UEFI) BIOS." The guidelines apply to "system BIOS firmware... stored in the system flash memory of computer systems, including portions that may be formatted as Option ROMs" — but explicitly exclude "Option ROMs, UEFI drivers, and firmware stored elsewhere in a computer system," meaning firmware on a separate video card, network adapter or hard-drive controller sits outside this document's scope even though the system BIOS routinely loads and executes it during boot.
The document is equally explicit about threats it does not try to mitigate: its guidelines "do not attempt to prevent installation of unauthentic BIOSs through the supply chain, by physical replacement of the BIOS chip, or through secure local update procedures." Section 2.5 reinforces this, listing supply-chain tampering and user-initiated installation by someone with physical access as threats the Section 3.1 technical controls cannot address — only the Section 3.2 management practices (golden master images, periodic baseline verification) offer any mitigation there.
The four security guidelines for a secure BIOS update mechanism
Section 3.1 requires that "all updates to the system BIOS shall either go through an authenticated BIOS update mechanism... or use an optional secure local update mechanism," built from four features:
| Guideline | What it requires |
|---|---|
| BIOS Update Authentication (3.1.1) | A Root of Trust for Update (RTU) holding a public key or its hash in a protected key store; update images "shall be signed in conformance with NIST SP 800-89... using an approved digital signature algorithm as specified in NIST FIPS 186-3... that provides at least 112 bits of security strength"; the mechanism should also resist rollback to an authentic-but-vulnerable earlier version |
| Secure Local Update (3.1.2, optional) | A mechanism that updates the BIOS without the authenticated path, but only by "requiring physical presence" — intended solely for first-image provisioning or recovering from a corruption the authenticated mechanism can't fix |
| Integrity Protection (3.1.3) | The RTU and the BIOS itself must be "protected from unintended or malicious modification with a mechanism that cannot be overridden outside of an authenticated BIOS update," and that protection mechanism must itself resist tampering |
| Non-Bypassability (3.1.4) | No system processor or other component may bypass the authenticated update mechanism; the guideline specifically calls out DMA-capable bus mastering and on-board microcontrollers as components that "shall not be capable of directly modifying the firmware" |
Section 3.1.1 adds a pointed note for high-security environments: an organization can assert active control over updates "by countersigning [BIOS images] with an organization-controlled key, which would be verified during the update process" — rather than trusting the manufacturer's signature alone.
Threats this document is built to stop
Section 2.5 walks through the realistic attack paths against a deployed BIOS. Malware could "leverage weak BIOS security controls or exploit vulnerabilities in the system BIOS itself to reflash or modify the system BIOS," delivered "either over a network, or using media" — the guidelines in Section 3.1 are "designed to prevent these kinds of attack." A compromised organization-run BIOS update server could push a malicious image "across the organization," which the document calls "a high-impact attack" that the same controls are designed to prevent. And because an authenticated-but-superseded BIOS image is still cryptographically valid, "any of the preceding mechanisms could be used to rollback to an authentic but vulnerable system BIOS" — "a particularly insidious attack, since the 'bad' BIOS is authentic (i.e., shipped by the manufacturer)," which is why Section 3.1.1 separately calls for rollback-resistant version checking.
For historical grounding, the document notes that "the only publicly known malware targeting the system BIOS that has infected a significant number of computers is the CIH virus, also known as the Chernobyl virus," first discovered in 1998 — evidence the guidelines were written ahead of widespread BIOS-level attacks rather than in reaction to one, drawing instead on published proof-of-concept research such as Sacco and Ortéga's 2009 "Persistent BIOS Infection" and Wojtczuk and Tereshkin's 2009 "Attacking Intel BIOS."
The five-phase BIOS management lifecycle
Section 3.2 lays out operational practices that complement the Section 3.1 technical guidelines across a platform's life cycle:
Provisioning Phase— establish a configuration baseline and maintain a "golden master image" for each approved BIOS version, including superseded versions, in secure offline storage; if the RTU uses organization-controlled keys, maintain those under multi-party control. Platform Deployment Phase— install the approved BIOS from the golden image using the secure local update mechanism, with the RTU and configuration parameters established, before the system is deployed. Operations and Maintenance Phase— apply BIOS updates only through the authenticated update process under a change management process; continuously monitor the image and configuration baseline, and treat unapproved deviation as an incident-response matter. Recovery Phase— use the secure local update mechanism when a corrupted BIOS or RTU cannot execute the authentication procedures, and re-validate the configuration baseline afterward. Disposition Phase— before a system leaves the organization, remove sensitive data, delete passwords and keys from the key store, and restore the manufacturer's default BIOS and configuration.
How this relates to later NIST guidance
SP 800-147 is deliberately narrow: it only covers the PC client system BIOS, and its own Section 1.2 flags that "future efforts may look at boot firmware security for enterprise server platforms" — which NIST delivered in 2014 as the companion document SP 800-147B. A broader generalization followed in 2018: NIST SP 800-193, Platform Firmware Resiliency Guidelines, states that its own Protection principle "is similar in... purpose to the guidelines found in NIST SP 800-147, BIOS Protection Guidelines" — SP 800-193 takes the same authenticate/protect/non-bypass model and extends it from the BIOS alone to a platform's full set of critical firmware devices (embedded controller, BMC/management engine, TPM, NIC and GPU expansion ROMs, and more), while adding formally separate Detection and Recovery properties that SP 800-147 does not require. Teams building a modern firmware security baseline should treat SP 800-147 as the BIOS-specific foundation and SP 800-193 as the broader, more current model to design against.
A workable starting point
Confirm which update path is actually authenticated end-to-endMany platforms expose both a vendor utility and a lower-level flashing tool; only one may enforce the Section 3.1.1 signature check. Verify the digital-signature algorithm and key strength against SP 800-89/FIPS 186-3 rather than assuming "signed update" means compliant. Treat rollback protection as a distinct check, not a side effect of authenticationAn attacker reinstalling an old, authentic, vulnerable BIOS image passes a naive signature check; confirm the platform also enforces a version/anti-rollback comparison as Section 3.1.1 recommends. Maintain the golden master image and RTU key material as a documented asset, not tribal knowledge — Section 3.2's Provisioning Phase treats this as the baseline every later recovery and audit step depends on. Scope firmware security work beyond the BIOS using SP 800-193, since SP 800-147 by design does not cover Option ROMs, UEFI drivers, or firmware on separate add-in cards — a firmware SBOM that inventories those components is the natural next step after confirming the BIOS update path itself is sound.
SoftWSP's device and firmware security assessments check whether a product's BIOS/UEFI update, integrity-protection and anti-rollback mechanisms hold up against SP 800-147's guidelines, alongside the broader Protection/Detection/Recovery model in SP 800-193: see Device & Firmware Security.
This guide summarises NIST SP 800-147 (April 2011, Final); it is not a substitute for the full text and does not constitute compliance or legal advice.
Sources
- NIST: SP 800-147, BIOS Protection Guidelines — publication page (Final, 29 April 2011)
- NIST SP 800-147 (David Cooper, William Polk, Andrew Regenscheid, Murugiah Souppaya), full text PDF
- NIST: SP 800-193, Platform Firmware Resiliency Guidelines — the 2018 follow-on that generalizes SP 800-147's model beyond the BIOS
Frequently asked questions
What is NIST SP 800-147?
"BIOS Protection Guidelines," a NIST Special Publication authored by David Cooper, William Polk, Andrew Regenscheid and Murugiah Souppaya of NIST's Computer Security Division. Its own Executive Summary states it "provides security guidelines for preventing the unauthorized modification of BIOS firmware on PC client systems," because "unauthorized modification of BIOS firmware by malicious software constitutes a significant threat... either a permanent denial of service (if the BIOS is corrupted) or a persistent malware presence (if the BIOS is implanted with malware)." It was published as Final in April 2011 (27 pages), carries no later revision, and per its own Authority section "is not subject to copyright, though attribution is desired" — it was prepared under NIST's FISMA statutory responsibilities, mandatory for U.S. federal agencies and usable voluntarily by others. A companion document for servers, SP 800-147B, followed in 2014; as of this guide's writing SP 800-147 remains listed as Final/active on NIST's publication page, not withdrawn.
What does 'BIOS' mean in this document, and what is explicitly out of scope?
Section 1.2 defines the term broadly: "the term BIOS refers to conventional BIOS, Extensible Firmware Interface (EFI) BIOS, and Unified Extensible Firmware Interface (UEFI) BIOS." The guidelines "apply to system BIOS firmware... stored in the system flash memory of computer systems, including portions that may be formatted as Option ROMs," but explicitly do "not apply to Option ROMs, UEFI drivers, and firmware stored elsewhere in a computer system" — i.e., firmware on add-in cards such as video, network or hard-drive controller cards is out of scope even though the system BIOS itself often loads and executes it. The document also states directly that its security guidelines "do not attempt to prevent installation of unauthentic BIOSs through the supply chain, by physical replacement of the BIOS chip, or through secure local update procedures" — supply-chain tampering and physical access are acknowledged, separate threats addressed (if at all) by the management practices in Section 3.2, not the technical controls in Section 3.1.
What are the four security guidelines for system BIOS implementations?
Section 3.1 specifies four features, summarized in its own Executive Summary: (1) BIOS Update Authentication — "the authenticated BIOS update mechanism, where digital signatures prevent the installation of BIOS update images that are not authentic," built on a Root of Trust for Update (RTU) holding a public key or its hash, with images "signed in conformance with NIST SP 800-89... using an approved digital signature algorithm as specified in NIST FIPS 186-3... that provides at least 112 bits of security strength"; (2) Secure Local Update — "an optional secure local update mechanism, where physical presence authorizes installation of BIOS update images," intended only for the first BIOS image or to recover from corruption the authenticated mechanism can't fix; (3) Integrity Protection — mechanisms preventing unintended or malicious modification of the BIOS outside the authenticated update process, which must themselves be tamper-resistant; and (4) Non-Bypassability — ensuring "there are no mechanisms that allow the system processor or any other system component to bypass the authenticated update mechanism," explicitly naming DMA-capable bus mastering and microcontrollers as components that must not be able to directly rewrite the firmware.
What are the five BIOS management lifecycle phases in Section 3.2, and how does SP 800-147 relate to later NIST guidance?
Section 3.2 names five phases: Provisioning (establish a configuration baseline and a "golden master image" for each approved BIOS version in secure offline storage); Platform Deployment (install the approved BIOS from the golden image using the secure local update mechanism before systems go into service); Operations and Maintenance (apply updates only through the authenticated mechanism under change management, and continuously monitor for unapproved deviation from baseline); Recovery (use the secure local update mechanism when the authenticated path itself cannot execute, e.g., after corruption); and Disposition (strip sensitive data, passwords and keys, and restore manufacturer defaults before a system leaves the organization). SP 800-147 is explicitly a narrower, earlier document: NIST's own 2018 follow-on, [SP 800-193 (Platform Firmware Resiliency)](/guides/nist-sp-800-193-platform-firmware-resiliency/), states its Protection principle "is similar in... purpose to the guidelines found in NIST SP 800-147" and generalizes the same authenticate/protect/non-bypass model from the BIOS alone to a platform's full set of critical firmware devices (BMC, embedded controller, NIC, GPU and more), adding Detection and Recovery as formally separate, independently gradable properties.
In this cluster
