Intel Boot Guard and AMD Platform Secure Boot Explained

Intel Boot Guard and AMD Platform Secure Boot are hardware verified boot schemes. Before the main firmware runs, the processor itself (or the security processor inside it) checks that firmware's signature against a hash of the PC maker's public key, burned into one time programmable fuses at the factory. If the check fails, the machine refuses to boot.

That is the piece UEFI Secure Boot cannot provide. UEFI Secure Boot checks bootloaders, drivers and option ROMs, but it runs inside the firmware and trusts the firmware completely. Hardware verified boot moves the first check out of flash and into silicon, so a modified firmware image is caught before it gets the chance to switch Secure Boot off.

This guide goes one level deeper than our posts on coreboot, CPU microcode updates, System Management Mode and how the motherboard evolved from BIOS to UEFI, TPM and BMC. We built it from Intel's own developer article on key usage in integrated firmware images, the TianoCore project's "Understanding the UEFI Secure Boot Chain" book (written by Intel engineers), AMD's PRO technologies documentation, coreboot's documentation for Intel TXT, Authenticated Code Modules, measured boot and the AMD Platform Security Processor, the Linux kernel's ABI documentation, the fwupd Host Security ID specification, Microsoft's System Guard documentation, and NIST SP 800-147, SP 800-155 and SP 800-193. Intel's full Boot Guard and manifest specifications are distributed under NDA, and so is AMD's PSP BIOS architecture guide, so where public documents stop we say so rather than fill the gap.

This is a defensive explainer. It covers how these features work, what they do and do not protect, what the fuses mean for owners, and how to check a machine you own. It contains no bypass techniques.

Key takeaways

• Different layer, different job. UEFI Secure Boot checks what the firmware loads (bootloaders, option ROMs, UEFI applications). Boot Guard and Platform Secure Boot check the firmware itself, starting from a key hash held in hardware.
• Intel Boot Guard works through an Intel signed Authenticated Code Module (ACM). CPU microcode verifies the ACM against an Intel key hash inside the processor. The ACM then verifies the OEM's Key Manifest against a key hash in field programmable fuses, verifies the Boot Policy Manifest with a key from the Key Manifest, and finally checks the Initial Boot Block (IBB) against a hash in the Boot Policy Manifest.
• AMD Platform Secure Boot (PSB) starts on the AMD Secure Processor, an on-die security processor that boots before the x86 cores. AMD's own documentation says one time programmable fuses "bind the processor to the OEM's firmware code signing key", after which the processor only works on boards using that same key.
• Fuses are permanent by design. Intel says the fused values cannot change once the manufacturing lock closes. That is what makes the root of trust trustworthy, and it is also what ties a processor or a board to one vendor's signing key for life.
• A leaked OEM key cannot simply be rotated out. Intel's article says the OEM Key Manifest's private key "cannot be changed in the field", so key custody at the PC maker matters more than almost any other control.
• Verification is not measurement. Hardware verified boot decides whether to run code. TPM measured boot records what ran so someone else can check it later. You want both, and they answer different questions.
• You can check from Linux. fwupdmgr security reports Boot Guard attributes (org.fwupd.hsi.IntelBootguard.*) and AMD's org.fwupd.hsi.Amd.PlatformSecureBoot, and the Linux kernel exposes AMD Secure Processor fields such as fused_part and anti_rollback_status in sysfs.

What problem does hardware verified boot solve that UEFI Secure Boot does not?

Start with what UEFI Secure Boot actually checks. The TianoCore book describes it as a feature that "guarantees that only valid 3rd party firmware code can run" in the OEM firmware environment. The third party code is the OS bootloader, PCI option ROMs on add-in cards and UEFI shell tools. The firmware keeps four databases in authenticated UEFI variables: the Platform Key (PK), the Key Exchange Keys (KEK), the allowed signature database (db) and the forbidden signature database (dbx), plus the timestamp and recovery databases (dbt and dbr). Each third party image is checked against db and dbx before it runs.

The same document then states the assumption plainly: "UEFI Secure Boot assumes the system firmware is a trusted entity." The code doing the verification lives in the same SPI flash chip as everything else. If an attacker, a faulty update tool or a compromised service technician can write a modified firmware image to that chip, the modified firmware can simply skip the signature checks, enrol a different Platform Key, or report that Secure Boot is on when it is not. Secure Boot cannot protect the thing that implements Secure Boot.

The TianoCore chapter on Boot Guard opens with exactly this point: UEFI Secure Boot "trusts it implicitly", meaning the OEM firmware, and "a better implementation relies on a smaller TCB to verify the OEM platform firmware." TCB here is the trusted computing base, the set of components you must trust for the security property to hold. Hardware verified boot shrinks that set from "the whole firmware image in flash" down to "the processor's boot ROM, microcode and a small signed module".

NIST framed the same problem for firmware updates more than a decade ago. NIST SP 800-147, BIOS Protection Guidelines (April 2011), asks for an authenticated update mechanism, integrity protection of the flash outside that update path, and "non-bypassability", meaning no component can route around the authenticated update. It also says plainly that the guidelines "do not attempt to prevent installation of unauthentic BIOSs through the supply chain, by physical replacement of the BIOS chip". Hardware verified boot is the control that covers the gap SP 800-147 left open: even if someone writes an unsigned image to the chip by clipping onto it, the processor will not run it.

There is a second gap, too. Secure Boot only starts working once the firmware has initialised enough of the platform to load and verify images. Everything that runs before that point (memory training, early chipset setup, System Management Mode setup, the code that installs the Secure Boot policy itself) is outside its reach. Hardware verified boot covers that early window, starting from the first instruction the main processor executes.

How does Intel Boot Guard work?

Intel describes Boot Guard in its developer article "Introduction to Key Usage in Integrated Firmware Images" (version 1.0, updated 11 October 2023, covering platforms up to 13th Gen Intel Core and 3rd Gen Intel Xeon Scalable) as a hardware based root of trust and "verified boot technology" whose goals include stopping reprogramming attacks and physical attacks on the SPI flash. Intel warns that guidance for later products may differ, which matters because newer platforms combine Boot Guard with TXT in a converged design whose details are not public. What follows is the public model.

The pieces

Intel's article adds detail on the fuses. The OEM public key hash and boot policy registers (it names BP.KEY, BP.RSTR, BP.Type and BP.Revocation) are stored in field programmable fuses. The OEM cannot write them directly; Intel's tools program them through the manageability engine during manufacturing, and once the lock closes at "End of Manufacturing" the values cannot change. The TianoCore book describes the same thing more simply: the key hash is a "Write once PCH register, programmed in manufacture fuse", and "The Key Hash is read-only. It cannot be updated." The Key Manifest and Boot Policy Manifest, by contrast, "can be updated in the firmware", which is what lets an OEM ship firmware updates without touching the fuses.

The verification chain, step by step

Putting Intel's article and the TianoCore book together, the boot of a Boot Guard platform runs like this:

Intel's article sums up the pattern: each step authenticates a public key against an already trusted hash, verifies the manifest's signature with that key, and then checks the firmware hash inside the manifest. The chain is only as long as the hardware part of it, though. The ACM checks the IBB and nothing else. TianoCore is explicit that "Boot Guard only verifies the initial boot block (IBB) of the whole OEM Firmware" and that the IBB must verify the rest. If an OEM's IBB does a poor job of verifying the OBB, the hardware root of trust does not save it. From that point on, the chain is software, written and maintained by the PC maker.

The manifests have recognisable structure. Intel's article names the Key Manifest by its __KEYM__ header (two formats exist, 1.0 and 2.1; version 2.1 adds a usage bitmask to each listed hash so one manifest can authorise different keys for different jobs) and the Boot Policy Manifest by its __ACBP__ header. The Key Manifest carries a security version number (KMSVN) and a KeyManifestID; the Boot Policy Manifest carries BPSVN, a BpmRevocation value and an AcmRevocation value. Those version numbers are how an OEM retires an older manifest or an older ACM: the fuses or policy record the minimum acceptable version, and anything older stops verifying.

coreboot's documentation shows what this means for the layout of a firmware image. It says the BIOS ACM "must be referenced by the FIT", the Firmware Interface Table that the processor reads at reset to find microcode, ACMs and boot blocks. coreboot's TXT IBB page lists the build rules: one IBB must contain the reset vector and the FIT, IBBs must not overlap each other or the BIOS ACM, the IBB size must be a multiple of 16, and the IBB should be as small as possible. In a coreboot build, files are marked as part of the IBB with the cbfstool --ibb flag, which tags the CBFS file so the build adds it to the FIT.

Verified and measured profiles

Intel's article says the OEM decides two things: whether to implement a Boot Guard enforcement profile at all, and whether to perform "just a verified boot or both a verified and measured boot". Unalterable policy lives in the fuses; mutable policy lives in the Boot Policy Manifest. The profile also determines whether the platform supports Intel TXT.

• Verified boot means the ACM checks the IBB and, depending on policy, halts the platform if the check fails.
• Measured boot means the ACM also hashes what it verified into a TPM Platform Configuration Register (PCR) before the IBB runs, so a remote verifier can later see exactly which firmware started.

The fwupd HSI specification adds one practical detail about policy: its org.fwupd.hsi.IntelBootguard.Policy test passes only when the "error enforce policy is set to shutdown". If it is not, fwupd says a broken chain of trust results in "just a console warning and then continue to boot". A machine can therefore report Boot Guard as present and enabled while still booting firmware that failed verification. That is why the fwupd checks are split into several attributes rather than one.

There is a public disagreement on the measured profile that is worth knowing about. coreboot's measured boot documentation says that when Boot Guard was designed, it "provided a measurement mode" in which the ACM would act as the static Core Root of Trust for Measurement, but that "this was never deployed", leaving the verification signature check as the only hardware rooted assertion. Intel's 2023 article, on the other hand, lists verified plus measured boot as an OEM choice. Both may be true at once (a mode can exist in the design while few or no shipped products enable it), but we could not settle it from public sources. If measured boot from the ACM matters for your attestation design, ask the PC maker what their firmware actually configures and check the TPM event log, which is covered in the step by step section below.

Where the ACM fits with TXT

The same ACM mechanism serves Intel Trusted Execution Technology. coreboot's TXT page says the BIOS ACM "initializes the TPM and measures parts of the firmware, the IBB", and that IBBs are measured into PCR0 by the BIOS ACM, after which the ACM decides whether the boot firmware is trusted. A separate SINIT ACM, which coreboot notes "isn't referenced by the FIT", is used later for a dynamic launch. Microsoft's System Guard requirements for Intel vPro platforms (Coffee Lake, Whiskey Lake or later) say the OEM BIOS must carry the Intel SINIT ACM, signed by "the correct production Intel ACM signer for the platform". That is a separate feature from Boot Guard, but it uses the same family of Intel signed modules.

What Intel says about key separation and failures

Intel's article contains the clearest public statement of how keys should be split. It says "Intel recommends using separate key pairs for signing each component", recommends separate development and production key sets, and calls the OEM Key Manifest private key the most sensitive key, to be kept in a hardware security module or a secure signing server. It also lists failure behaviour beyond the IBB: Intel's own CSME components (ME bring-up, ME main firmware, the power management controller and others) are checked with Intel keys rooted in hardware whether or not an OEM Key Manifest exists, and a failure there stops the boot. Intel signs every firmware component loaded by the CSME, according to the article.

One design choice in the article is worth reading twice: Intel recommends always including an OEM Key Manifest, even an empty one, because if an OEM skips it at End of Manufacturing "a fuse is permanently set" and that board can never add an OEM Key Manifest later. Decisions made in the factory are permanent for the life of the board.

How does AMD Platform Secure Boot work?

AMD's design starts somewhere else. On AMD processors, the first code to run is not on the x86 cores at all. It runs on the AMD Secure Processor, which coreboot's documentation still calls by its older name, the Platform Security Processor (PSP).

The AMD Secure Processor boots first

AMD's PRO technologies documentation describes the AMD Secure Processor as "a dedicated on-chip security processor" in each AMD SoC that "enables secure boot with root of trust anchored in hardware" and initialises the SoC through a secure boot flow. coreboot's PSP firmware integration guide fills in the mechanics, based on AMD's NDA design guides:

1. The PSP is "an on-die, isolated security processor that runs independently from the main x86 cores". It runs its own firmware and shares the SPI flash with the system BIOS.
2. At power on, on-chip boot code (a ROM inside the PSP) searches fixed flash addresses for the Embedded Firmware Structure, a table of pointers to the PSP and BIOS directory tables.
3. The PSP directory contains an AMD public key (entry type 0x00) that the on-chip boot code uses "to verify the signature of PSP boot loader firmware". The PSP boot loader, the PSP's secure OS, the power management firmware and the AGESA boot loaders are loaded from flash this way.
4. The AGESA boot loaders run on the PSP and initialise the silicon, "including but not limited to" the memory interface, "prior to releasing the main cores from reset".
5. The BIOS directory contains the BIOS reset image (type 0x62). The PSP copies it from flash into DRAM "at the location where the x86 begins execution when released from reset".

So on AMD, by the time the first x86 instruction runs, the PSP has already authenticated its own firmware with AMD's key, trained memory and placed the BIOS reset image in DRAM. Platform Secure Boot extends that existing chain to cover the OEM's BIOS.

Fuse binding to an OEM key

AMD's public description of PSB is a footnote on its PRO technologies page, and it is unusually direct:

An OEM who has enabled the AMD Secure Boot feature grants permission for their cryptographically signed BIOS code to run only on their platforms using an AMD secure boot enabled motherboard. One-time-programmable fuses in the processor bind the processor to the OEM's firmware code signing key. From that point on, that processor can only be used with motherboards that use the same code signing key.

The fwupd HSI specification describes the same feature as one that "prevents the machine from running firmware images not released by the system manufacturer" and "forms a root-of-trust by fusing in cryptographic keys into the processor itself". coreboot's measured boot page calls it "AMD's Hardware Validated Boot (also known as Platform Secure Boot)" and groups it with Boot Guard as hardening that moves the root of the verification chain "into hardware".

The important difference from Intel is where the fuses sit. On Intel platforms the OEM key hash lives in the chipset or SoC fuses programmed at the board factory. On AMD, the AMD documentation places the binding in the processor. On a socketed desktop or workstation part, the processor can be moved to another board, and that is where the second hand problem comes from (covered below). The detailed format of AMD's signed BIOS images, and exactly which parts of the BIOS image the PSP verifies, are in AMD's NDA PSP BIOS architecture guides, which coreboot lists as documents 55758 and 54267. We have not seen them, and we describe only what AMD and the open source projects say publicly.

Related protections the PSP reports

The Linux kernel's ccp driver documents a set of read only sysfs attributes that the AMD Secure Processor reports to the operating system on supported SoCs. The kernel ABI documentation lists them under /sys/bus/pci/devices/<BDF>/:

The newest entry, boot_integrity, carries a note worth keeping in mind: "Vendors may provide design specific alternative hardware root of trust implementations." A zero there is not proof that a machine has no hardware root of trust, only that the AMD part is not the one doing it. fwupd's PSP plugin documentation makes a similar point about all of these files: "The lack of these sysfs files does NOT indicate the lack of these security features", only that the platform does not export the information.

Rollback protection deserves a sentence of its own. fwupd describes the AMD Secure Processor's rollback feature as one that "prevents an attacker from loading an older firmware onto the part after a security vulnerability has been fixed", notes that end users cannot change it directly because it is "controlled by the manufacturer", and makes it an HSI-4 requirement. Microsoft's System Guard Secure Launch requirements for AMD platforms (Zen 2 or later) include "AMD Secure Processor Firmware Anti-Rollback protection enabled". A verified boot chain without rollback protection still accepts old, signed, vulnerable firmware, because the old firmware was signed with the same key.

Timeline: hardware rooted boot integrity in public documents

Every date below is taken from the linked primary source. Feature launch dates for Boot Guard and Platform Secure Boot on specific processor generations are not given in the vendors' public pages we could fetch, so we do not guess them.

Why are the fuses one time, and what does that cost?

A root of trust is only useful if nothing that runs later can change it. NIST SP 800-193 says vendors "typically protect RoTs by either making them immutable, or by ensuring that" any update is authenticated by another root of trust. One time programmable fuses are the immutable option. Once blown, a fuse cannot be reset by software, by a firmware update or by reflashing the SPI chip. That is why Boot Guard and PSB can make promises that a key stored on flash cannot.

The same property has consequences that are easy to miss when you buy hardware.

The board belongs to one signing key for life

On a Boot Guard platform with enforcement fused on, firmware that is not signed under the OEM's key hierarchy will not pass the ACM's check. On a PSB platform, firmware not signed with the OEM key bound into the processor will not be accepted. Neither the owner nor a later buyer can add their own key, because the fused hash cannot be changed. There is no equivalent of UEFI Secure Boot's setup mode, where the owner clears the Platform Key and enrols their own.

Open firmware needs the OEM's cooperation

This is the practical effect for coreboot and other open firmware on enforced platforms. coreboot can be built to run on Boot Guard platforms (its documentation covers the FIT, ACM and IBB rules), but the resulting image only boots on a fused board if it is signed with keys that chain to the fused hash. In practice that means open firmware ships on locked boards only when the PC maker builds and signs it. An owner of a locked board who wants to replace the vendor firmware with their own build cannot do so, and the right response to that is to choose hardware whose maker ships or supports the firmware you want, not to look for ways around the lock.

Second hand processors can be tied to the wrong boards

AMD's own footnote spells it out: once fused, a processor "can only be used with motherboards that use the same code signing key." A socketed processor pulled from a PSB enabled machine from one vendor will not boot on a board from another vendor, or on a retail board. If you buy used processors, ask whether they came from systems with PSB enabled. If you sell or donate machines, know that the processor may not be reusable outside that vendor's boards.

Manufacturing mistakes are permanent too

Intel's advice about the empty Key Manifest shows the other side of the coin. A board that leaves the factory without an OEM Key Manifest has a fuse set that prevents adding one later. A board that leaves the factory with enforcement policy set to warn rather than shut down will warn forever. fwupd's org.fwupd.hsi.Mei.ManufacturingMode and org.fwupd.hsi.PlatformFused attributes (both HSI-1) exist for the same reason. The HSI specification notes "some unfortunate cases of the ME being distributed in manufacturing mode", in which any user with root access can provision the ME with new keys. That is a factory process failure, and only the PC maker can fix it.

What happens when an OEM signing key leaks?

Every hardware verified boot design rests on one assumption: the OEM's private signing key stays private. If it leaks, anyone holding it can produce firmware that the fused hardware accepts as genuine. fwupd's description of its key check puts the impact bluntly: a custom firmware signed with a leaked private key could "completely disable UEFI Secure Boot and allow complete persistent compromise of the affected machine."

The hard part is revocation. The fused hash points at the OEM's root key. Intel's article says the OEM Key Manifest's private key "cannot be changed in the field", that updates must be signed with the same key used for the original manifest, and that if that key is exposed and the hardware offers no way to switch to a second key, the platform cannot re-establish the chain of trust. The manifest version numbers (KMSVN, BPSVN) let an OEM retire an old manifest signed with a lower level key, and Intel mentions that the manufacturer can "revoke the Key Manifest or simply use a new KeyManifestID", but none of that helps if the key at the top, the one whose hash is in the fuses, is the key that leaked. On a fused machine, a leaked root key is a permanent property of that machine.

NIST SP 800-193 discusses the same risk for firmware update keys in general: "It is possible that the private key corresponding to the public key in the key store may become 'compromised'", and recovery techniques "range from the complex, including key hierarchies, to simpler, including updating the key store". Key hierarchies are the answer that works with fuses. If the fused root key signs only a Key Manifest, and lower level keys sign everything else, then a leak of a lower key can be handled by issuing a new manifest with a higher version number. Only a root key leak is unrecoverable.

This is not hypothetical. fwupd's HSI specification records that in 2022 a number of Boot Guard platform keys were leaked and the leak was confirmed by the processor vendor, and fwupd added the org.fwupd.hsi.Mei.KeyManifest attribute (fwupd 1.8.7, required for HSI-1) to flag machines whose fused key is on the known compromised list. We are not going to narrate that incident; the general lesson is enough.

How key custody should work

For PC makers, and for anyone building their own signed firmware on a platform that allows it, the public guidance converges:

• Keep the root key offline in a hardware security module, with M of N approval for every use. Intel names the OEM Key Manifest key as the most sensitive key and recommends an HSM or a secure signing server. The coreboot verified boot key table reproduced in the TianoCore book describes the root key as held in a locked room with "N of M present".
• Use the hierarchy. The root key signs a manifest, not firmware. Day to day signing uses lower level keys that can be retired through version numbers.
• Separate keys by component and by stage. Intel: "separate key pairs for signing each component", and separate development and production sets. A development key should never be able to sign a production image.
• Plan for revocation before you need it. Decide which version counters you will raise, and test that raising them works, before a leak forces you to.
• Log and review every signing operation. A signing server should record what was signed, by whom, under which approval.

For buyers, the useful question is not "has your key ever leaked" but "what is your process if it does, and which of our machines would be affected".

How do these relate to TPM measured boot, SP 800-147 and SP 800-193?

Verification versus measurement

Hardware verified boot answers "should this code run". Measured boot answers "what code ran". The Linux kernel's TPM event log documentation describes the measured side: "The preboot firmware maintains an event log that gets new entries every time something gets hashed by it to any of the PCR registers." PCRs can only be extended, never set, so the final values are a fingerprint of everything measured since reset. The event log explains how the fingerprint was built. As the kernel documentation quotes from the Trusted Computing Group, the log is "not trusted on their own" and the PCR values are what validate it.

coreboot's measured boot page explains why the start of that chain matters. The first measurement is taken by the Core Root of Trust for Measurement (CRTM). When it runs once per power cycle, it is a static CRTM, and the chain built from it is the Static Root of Trust for Measurement (SRTM). In a plain firmware design, the IBB measures itself, which coreboot describes as a root of trust "rooted in software". Boot Guard and PSB move the root of the verification chain into hardware. Whether they also move the root of the measurement chain depends on the profile the OEM configured, which is the disputed point covered above.

EDK II, the open source UEFI implementation, shows how firmware cooperates with a hardware root of trust on this. Notes on the EDK II trusted boot chain describe interfaces that let a "BootGuard platform module" tell the TPM measurement code that the ACM has already measured the first firmware volume, so it is not measured twice, or pass along a hash the ACM verified so it can be logged without being recomputed. A Boot Guard platform "may report" the ACM, Key Manifest and Boot Policy Manifest as EV_S_CRTM_CONTENTS events in the TPM event log. When you read an event log from such a machine, those entries are the trace of the hardware chain.

Microsoft's System Guard documentation adds a third option: the dynamic root of trust for measurement (DRTM). Microsoft explains that SRTM measurements vary across thousands of PC models and firmware versions, which makes allowlists slow to maintain and blocklists easy to evade, and that Secure Launch "lets the system freely boot into untrusted code initially" before re-establishing a measured, controlled state with a processor instruction. DRTM complements hardware verified boot rather than replacing it: the first protects the firmware, the second limits how much the OS has to trust it.

NIST SP 800-147 and SP 800-155

SP 800-147 is about updates: it requires a Root of Trust for Update "that contains a signature verification algorithm and a key store that includes the public key needed to verify the signature on the BIOS update image". Boot Guard and PSB are not update mechanisms, but they make SP 800-147's goals hold even when the update path is bypassed by physically writing the flash chip, which the guideline explicitly leaves out of scope. SP 800-147 also asks for a recovery phase with "authorized rollback", which is the opposite pressure to anti rollback fuses; a platform has to decide which old versions remain acceptable.

SP 800-155, BIOS Integrity Measurement Guidelines, was a December 2011 draft about measuring and reporting firmware integrity. NIST stopped developing it on 25 October 2024 and says its content went to the Trusted Computing Group, with related guidance in NIST SP 1800-34. It is useful history but not a current requirement.

NIST SP 800-193

SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), widened the frame to three principles: protection, detection and recovery. It defines separate roots of trust for update (RTU), detection (RTD) and recovery (RTRec). Hardware verified boot is mostly a detection control in SP 800-193's terms: it detects that the firmware is not authentic before it runs. On its own it offers no recovery. A Boot Guard machine with a corrupted IBB under enforcement simply does not boot, which protects your data but leaves you with a machine that needs service. Platforms that want SP 800-193 style recovery add a protected recovery image or a separate recovery controller.

Comparison: Boot Guard, Platform Secure Boot, UEFI Secure Boot and coreboot verified boot

coreboot's verified boot documentation describes the root of trust it uses as "basically the read-only portion of the" SPI flash, protected by the flash chip's write protect pin and status register bits, with a 4096 or 8192 bit public root RSA key in the read only Google Binary Blob (GBB) area that verifies the signed read/write firmware. Its documentation notes that the hardware write protection can be removed by eliminating the ground connection to the write protect pin. That is a deliberate owner control, and it is the main philosophical difference from fused schemes: vboot puts the root of trust where the physical owner can reclaim it, while Boot Guard and PSB put it where only the OEM can define it. Each makes sense for a different threat model. A fleet operator worried about evil maid attacks wants the fused model; a researcher or an organisation that builds its own firmware wants the owner controlled one. Some hardware layers both: a fused Boot Guard chain whose IBB is coreboot, followed by vboot and then UEFI Secure Boot or a payload's own checks.

Step by step: check Boot Guard or PSB status on Linux

Everything below is read only. None of it changes firmware settings, and none of it requires disabling Secure Boot or loading unsigned kernel modules, which is one reason fwupd's HSI exists: its specification says HSI only measures protections "that can be verified by the end user without requiring any extra hardware to be connected, additional software to be installed, or disabling any existing security layers".

Step 1: install or update fwupd

Most desktop distributions ship fwupd. Check the version, because several attributes only exist in newer releases (Boot Guard attributes since 1.5.0, the compromised key check since 1.8.7, the AMD Platform Secure Boot attribute since 2.1.1).

fwupdmgr --version
# Debian or Ubuntu
sudo apt install fwupd
# Fedora
sudo dnf install fwupd

If your distribution ships a release older than 2.1.1, the PSB attribute will be missing from the output even on a machine that has PSB enabled.

Step 2: read the host security report

fwupdmgr security

The output groups attributes by HSI level and prints an overall level such as HSI:2. The fwupd specification calls HSI-1 "a safe baseline" and says that if a system does not meet it, you should adjust firmware setup options, contact the manufacturer or replace the hardware. For hardware verified boot, look for these lines:

A runtime suffix of ! after the HSI number means fwupd detected a runtime issue, such as UEFI Secure Boot turned off, a tainted kernel or kernel lockdown not active. Those do not change the base level but are worth fixing.

Step 3: get machine readable output for an inventory

For a fleet, collect JSON instead of reading text. fwupdmgr supports --json for scripted use.

fwupdmgr security --json > hsi-$(hostname).json

# Show only the hardware root of trust attributes and their results
jq '.SecurityAttributes[]
    | select(.AppstreamId
        | test("IntelBootguard|PlatformSecureBoot|PlatformFused|Mei.KeyManifest|Mei.ManufacturingMode|RollbackProtection"))
    | {AppstreamId, HsiResult}' hsi-$(hostname).json

Field names in the JSON output can change between fwupd releases. If the filter returns nothing, open the file and confirm the key names for your version before relying on the query in automation.

Step 4 (Intel): look at the raw ME firmware status

fwupd reads Boot Guard state from the Intel Management Engine interface. The kernel exposes the same registers through the MEI driver:

ls /sys/class/mei/
cat /sys/class/mei/mei0/fw_status

The kernel documentation says the ME firmware writes "its status information into fw status registers for BIOS and OS to monitor fw health", and that "the way the registers are decoded depends on PCH or SoC generation." Treat these hex values as evidence to keep with the fwupd report, not as something to decode by hand without the generation specific register definitions. On some machines the MEI device is disabled in firmware setup, in which case fwupd cannot report Boot Guard state at all.

Step 5 (AMD): read the Secure Processor attributes

The AMD fields live under the PCI device that the ccp driver binds to. Rather than guess the PCI address, search for the files:

for f in fused_part debug_lock_on anti_rollback_status rom_armor_enforced \
         rpmc_production_enabled rpmc_spirom_available boot_integrity; do
  for p in /sys/bus/pci/devices/*/$f; do
    [ -r "$p" ] && printf '%s: %s\n' "$p" "$(cat "$p")"
  done
done

Read 1 as yes and 0 as no, using the meanings in the kernel table above. boot_integrity only exists on kernels new enough to carry it. Remember the plugin documentation's warning: a missing file means the platform does not export that field, not that the feature is absent.

Step 6: check UEFI Secure Boot and the TPM

Hardware verified boot protects the firmware; you still want Secure Boot on for the stages after it, and a TPM recording measurements.

mokutil --sb-state
ls /sys/class/tpm/
cat /sys/class/tpm/tpm0/tpm_version_major
cat /sys/class/tpm/tpm0/pcr-sha256/0
cat /sys/class/tpm/tpm0/pcr-sha256/7

The per bank PCR files were documented in Linux 5.12. PCR 0 covers the static firmware code; PCR 7 covers the Secure Boot policy. Record both values for a known good firmware version. A change after a firmware update is expected; a change without one is worth investigating.

Step 7: read the firmware event log

With the tpm2-tools package installed, you can decode the firmware's measurement log and look for the hardware root of trust entries:

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | less

Look for EV_S_CRTM_CONTENTS and EV_S_CRTM_VERSION events near the start of the PCR 0 entries. On a Boot Guard platform that reports its ACM and manifests as EDK II describes, those entries are where they appear. Their absence does not prove the hardware chain is missing; it means the firmware did not log it.

Step 8: store a baseline and re-run after every firmware update

Save the fwupd JSON, the sysfs values and the PCR values together with the firmware version (sudo dmidecode -s bios-version) in your asset inventory. Re-run after each firmware update. A Boot Guard or PSB attribute that flips from pass to fail after an update is a firmware regression to report to the vendor immediately.

Buyer checklist: what to ask a hardware vendor

Hardware verified boot is set at the factory, so the purchase is the moment you can still influence it. Ask these questions in writing and keep the answers with the purchase record.

Common mistakes

• Treating UEFI Secure Boot as firmware protection. Secure Boot checks what firmware loads. A machine with Secure Boot on and Boot Guard or PSB off can still run modified firmware.
• Reading "Boot Guard enabled" as "Boot Guard enforcing". The Enabled attribute and the Policy attribute are separate. A platform can be enabled with a warn and continue policy.
• Assuming the hardware chain covers the whole image. Boot Guard verifies the IBB. The IBB has to verify the rest, and that part is OEM software with its own bugs.
• Ignoring rollback. A signature check accepts any firmware the OEM ever signed, including vulnerable versions, unless version numbers and anti rollback are used.
• Treating a missing sysfs file as a failed check. fwupd's PSP plugin says the absence of a file does not mean the feature is absent.
• Running an old fwupd. The PSB attribute needs fwupd 2.1.1 or later, and the compromised key check needs 1.8.7 or later.
• Buying used socketed AMD processors without asking about PSB. A processor bound to one OEM's key will not boot elsewhere.
• Disabling Secure Boot or loading unsigned modules to run deeper checks on production machines. Use read only tools that work with protections on, and do deeper testing on dedicated lab hardware.
• Keeping firmware signing keys on a build server. Root keys belong in an HSM, used rarely, with approvals and logs.
• Assuming verified boot means measured boot. If you need attestation, confirm what the firmware actually measures by reading the event log.

FAQ

What is Intel Boot Guard in simple terms?

It is a processor feature that checks the first block of the PC maker's firmware before it runs. An Intel signed module, verified by the CPU, compares the firmware against keys whose hash the PC maker burned into fuses at the factory. If the check fails under the enforcing policy, the PC does not boot.

What is AMD Platform Secure Boot?

It is AMD's equivalent, run by the AMD Secure Processor inside the chip before the main cores start. AMD says one time programmable fuses bind the processor to the PC maker's firmware signing key, so the processor only runs that maker's signed BIOS and only works on boards that use the same key.

Is Boot Guard the same as UEFI Secure Boot?

No. UEFI Secure Boot is implemented inside the firmware and checks bootloaders and drivers it loads. Boot Guard checks the firmware itself, from a root of trust in hardware. They are designed to be used together.

How do I check if Boot Guard is enabled on Linux?

Run fwupdmgr security and look for the org.fwupd.hsi.IntelBootguard.Enabled, Verified, Acm, Otp and Policy attributes. For AMD, look for org.fwupd.hsi.Amd.PlatformSecureBoot with fwupd 2.1.1 or later, and read the AMD Secure Processor sysfs files such as fused_part.

Can I turn Boot Guard or Platform Secure Boot on or off myself?

No. Both are configured by the PC maker at manufacture and recorded in fuses. Firmware setup menus do not control them. If a report shows them disabled, the fix has to come from the manufacturer, which fwupd's resolution text also says.

Can I install coreboot or other open firmware on a Boot Guard locked board?

Only if the image is signed under the PC maker's keys, which in practice means the maker ships it. The fused key hash cannot be replaced. If you want to run your own firmware, choose hardware whose maker supports that, or hardware that uses an owner controlled root of trust.

Why won't a used AMD processor boot in my motherboard?

If it came from a machine with Platform Secure Boot enabled, its fuses may bind it to that OEM's signing key. AMD's documentation says such a processor "can only be used with motherboards that use the same code signing key."

What happens if a PC maker's Boot Guard key leaks?

Anyone holding the key could sign firmware that affected machines accept as genuine. Because the key hash is fused, the machines cannot be re-keyed in the field. fwupd checks for known compromised keys through org.fwupd.hsi.Mei.KeyManifest, which is an HSI-1 requirement.

Does hardware verified boot replace the TPM?

No. Verification decides whether firmware runs; the TPM records what ran so it can be checked later through attestation. A secure platform uses both, plus UEFI Secure Boot for the OS loader.

Does Boot Guard protect against firmware bugs?

No. It ensures the firmware is the version the PC maker signed. If that version has a vulnerability, it is still signed and still runs. You still need firmware updates, and rollback protection so old vulnerable versions cannot be reinstalled.

Where Safeguard fits

Safeguard does not inspect firmware images, read fuses or Boot Guard state, scan firmware, generate hardware bills of materials or manage devices. The checks in this guide come from fwupd, the Linux kernel and your hardware vendor. The fit is indirect, and it sits in the software around firmware rather than in it. Firmware is built like other software: EDK II and coreboot trees vendor open source libraries, firmware build hosts run Python tooling, compilers and OpenSSL linked signing utilities, and teams increasingly build firmware inside container images. Safeguard can scan those repositories, build containers and SBOM files for known vulnerable components, show which projects contain a given component and version, apply reachability analysis, and evaluate policies and gates before a build ships. Its CLI assistant can edit code and run commands in such a repository with your approval at each step. None of that changes what the fused root of trust accepts, and it would not have prevented a signing key leak; key custody is a process control at the PC maker.

Hardware verified boot decides which firmware a machine will run, but the tools and pipelines that build, sign and check that firmware still pull open source dependencies, and a rebuilt workstation pulls fresh packages for fwupd, tpm2-tools and Python. Those are dependencies you control, and the steps below apply to them, not to the firmware in your machine's flash.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session in a repository: it reads a vulnerability finding, asks before each command, edits the dependency, runs the install and tests with your approval and pushes nothing. The same flow applies to the tooling repository behind a firmware build, for example the Python scripts that wrap an EDK II build or prepare an image for signing. It does not touch firmware on a machine or the keys that sign it.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. A firmware team can use the same flow to scan a build container or a vendored coreboot or EDK II tree on a workstation inside its own network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. An engineer can then ask about the dependencies in a firmware build repository from the assistant they already use, with only the access they grant.

Click through it at your own pace, or open it full screen.

Download the apps at https://safeguard.sh/download and read the CLI documentation at https://docs.safeguard.sh/docs/cli .

Quick check

Sources

• Intel: Introduction to Key Usage in Integrated Firmware Images
• TianoCore: Understanding the UEFI Secure Boot Chain, Intel Boot Guard
• TianoCore: Understanding the UEFI Secure Boot Chain, UEFI Secure Boot
• TianoCore: Understanding the UEFI Secure Boot Chain, coreboot
• EDK II Trusted Boot Chain notes: TCG Trusted Boot Chain in EDK II
• AMD PRO technologies (footnotes GD-72 and GD-211)
• coreboot documentation: AMD Platform Security Processor firmware integration guide
• coreboot documentation: Security
• coreboot documentation: Measured boot
• coreboot documentation: vboot verified boot support
• coreboot documentation: Intel TXT
• coreboot documentation: Intel TXT Initial Boot Block
• coreboot documentation: Intel Authenticated Code Modules
• fwupd Host Security ID Specification
• fwupdmgr documentation
• fwupd PCI PSP plugin documentation
• Linux kernel ABI: sysfs-driver-ccp (AMD Secure Processor attributes)
• Linux kernel ABI: sysfs-class-mei
• Linux kernel ABI: sysfs-class-tpm
• Linux kernel documentation: TPM Event Log
• Microsoft Learn: How a hardware based root of trust helps protect Windows (System Guard)
• NIST SP 800-147, BIOS Protection Guidelines
• NIST SP 800-155 (draft), BIOS Integrity Measurement Guidelines
• NIST SP 800-193, Platform Firmware Resiliency Guidelines

Last reviewed: 24 October 2026. Boot Guard and Platform Secure Boot details vary by processor generation and by PC maker, and fwupd attribute names change between releases; check the documentation for your exact platform, firmware and tool version.