UEFI Secure Boot and TPM-Measured Boot Explained

Updated on Oct 10, 2026

9 min read

UEFI Secure Boot and TPM-measured boot protect different parts of the startup trust chain. Secure Boot checks whether firmware is allowed to launch an EFI program; measured boot records what started so that a local tool or remote service can evaluate the platform. System administrators, security engineers, and people troubleshooting encrypted computers need to understand both controls because a valid signature, a recorded measurement, and a trustworthy system are related but not interchangeable claims.

Why These Boot Controls Matter

Modern attacks can target a machine before its operating system security tools load. A malicious or vulnerable boot component may persist below endpoint monitoring, alter startup behavior, or undermine protections such as disk encryption. Secure Boot and TPM measurements make parts of this early startup path enforceable and inspectable.

They also appear in device compliance checks, operating-system security baselines, and BitLocker recovery planning. A firmware setting change or bootloader update can alter the measurements that a disk-encryption policy expects. The practical question is therefore not simply whether a device has a TPM, but which stages are verified, which are measured, and what happens when the platform changes.

What Are Secure Boot and TPM-Measured Boot?

UEFI Secure Boot is a firmware policy for deciding whether signed EFI applications may run during startup. The firmware checks an image against its enrolled trust and revocation databases before launching it. A bootloader accepted by firmware can then apply its own policy to later components, such as a kernel or operating-system loader. Microsoft’s Secure Boot documentation describes the firmware databases and key hierarchy used on Windows devices.

Measured boot records cryptographic measurements of startup components in a Trusted Platform Module (TPM). A measurement is typically a hash of firmware, boot configuration, or another event. Rather than deciding whether that event is acceptable, the TPM extends the value into a Platform Configuration Register (PCR). Software can later compare the PCR values with an event log, and an attestation service can request signed evidence from the TPM.

The TianoCore project develops open-source UEFI firmware components, including EDK II. Its work illustrates that UEFI is the firmware interface and ecosystem in which Secure Boot policy is implemented, not an operating system or a TPM feature.

In short, Secure Boot is primarily an execution gate: an untrusted image can be refused. Measured boot is primarily an evidence mechanism: startup events are recorded for later assessment. A platform can use one without the other, although organizations often combine them.

The Problem They Solve

Without firmware-level checks, a system may launch a bootloader from removable media or a modified system partition before operating-system security controls begin. Later defenses can miss a compromised early component because they rely on the very software that component helped start. Secure Boot creates a policy-controlled checkpoint before the OS begins.

Signature checks alone do not tell an administrator exactly what ran, whether a permitted component used an unexpected configuration, or whether a device matches a required baseline. Measured boot helps fill that gap by preserving a sequence of measurements. This evidence can support troubleshooting or attestation, but only when a verifier knows which states are expected and how to interpret the log.

How Secure Boot and Measured Boot Work

The trust path begins in platform firmware. After hardware initialization, UEFI firmware applies its boot policy to an EFI executable such as a boot manager or loader. Secure Boot commonly uses a hierarchy of authenticated variables: the Platform Key (PK) controls platform ownership, Key Exchange Keys (KEKs) authorize updates to signature databases, db contains allowed certificates or hashes, and dbx contains revoked entries. The exact enrollment and update process depends on the device vendor and deployment.

If the selected EFI application is allowed, firmware transfers control to it. A boot manager or loader may then validate later components according to its own design. Secure Boot does not automatically guarantee that every file, driver, configuration, or application used after that handoff is checked; the rest of the chain must continue the policy. Linux systems, for example, may use a signed shim and a distribution-managed trust database before loading a kernel.

During measured boot, firmware and later boot stages extend measurements into designated PCRs. Conceptually, an extend operation combines the current PCR value with a new digest, so each event contributes to the final value and order matters. The TPM usually holds the accumulated PCR values, while an event log records what was measured and is made available to software. A verifier can replay the log and check that it produces the quoted PCR values.

For remote attestation, the device can ask its TPM to sign selected PCR values with an attestation key and a fresh challenge from the verifier. The verifier checks the signature, freshness, device identity or enrollment, and whether the measurements match its policy. The IETF RATS Architecture describes the roles of an attester, verifier, and relying party that consume this kind of evidence. The resulting decision is a policy outcome, not a verdict generated by the TPM itself.

Property	UEFI Secure Boot	TPM-measured boot
Main purpose	Enforce which EFI images may execute	Record startup state for later evaluation
Primary mechanism	Signature or hash checks against firmware policy	Hash measurements extended into TPM PCRs
On a policy mismatch	Firmware can refuse to launch an image	PCRs differ; a verifier may reject the evidence
Typical evidence	Firmware state and boot policy	PCR quote plus a replayable event log
TPM required	No	Yes, for TPM-backed PCR evidence

Components and Key Concepts

UEFI trust databases

The allowed database (db) and forbidden database (dbx) let firmware accept trusted signatures while rejecting revoked certificates or known-bad image hashes. The PK and KEK protect changes to those databases. Firmware vendors and operating-system vendors may update certificates or revocation data, so maintaining the trust store is part of ongoing security operations.

TPM PCRs and event logs

A PCR is a small register that accumulates measurements; it is not a readable list of filenames and it does not label a platform “safe.” The event log provides descriptions and digests for interpreting the accumulated values. A verifier should replay that log and confirm it matches the TPM quote rather than trusting either item by itself.

PCR selection matters. Different PCRs can reflect firmware code, boot configuration, boot manager activity, or other platform events, and the mapping depends on firmware and operating-system conventions. Policies that bind secrets to a specific PCR set can be sensitive to legitimate firmware, bootloader, or configuration updates.

Attestation keys and policy

An attestation key signs evidence without exposing the TPM’s protected private key. A remote service still needs a way to associate that key with an enrolled device and decide which measurements are acceptable. The attestation flow therefore depends on key provisioning, fresh challenges, trusted reference values, event-log parsing, and a policy that is updated as software changes.

Recovery and maintenance

Secure Boot key changes, firmware updates, bootloader changes, and altered PCR policies can affect startup or trigger a disk-encryption recovery prompt. Before changing firmware settings or updating boot components on an encrypted device, administrators should confirm recovery keys are escrowed and that a tested recovery path exists. A successful boot today does not prove that a fleet-wide policy will tolerate the same change.

Real-World Use Cases

Endpoint security: Organizations require Secure Boot to block unauthorized EFI images and use measured-boot evidence as one input to device compliance or conditional access.
Disk encryption: BitLocker can use TPM-backed protectors tied to platform measurements. If expected measurements change, recovery safeguards allow an authorized user or administrator to regain access. See the site guide to BitLocker management and recovery.
Linux deployment: Administrators combine firmware trust, signed bootloaders, kernel-signing policy, and distribution-specific keys. The Linux boot process and initramfs guide explains the later handoff from firmware through the bootloader to early userspace.
Server and cloud infrastructure: A verifier can use attestation results to decide whether a machine may receive sensitive workloads or secrets. This is useful only when the platform inventory, reference measurements, and update process are maintained.

Getting Started: Inspect Boot State

Start with read-only checks before changing firmware settings. Record the current boot mode, Secure Boot state, TPM readiness, and encryption recovery status. On managed devices, follow the organization’s change process and confirm recovery keys are accessible before changing boot policy.

On Debian or Ubuntu, install basic inspection tools if they are not already present:

sudo apt update
sudo apt install mokutil tpm2-tools

Then check that Linux booted through UEFI, inspect Secure Boot, and read common SHA-256 PCRs:

test -d /sys/firmware/efi && echo "Booted with UEFI" || echo "UEFI runtime not available"
sudo mokutil --sb-state
sudo tpm2_pcrread sha256:0,2,4,7
sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

The PCR output is a snapshot, not a diagnosis. A useful comparison requires the corresponding event log and a known-good baseline. Some systems do not expose the firmware event log at that path, and access to TPM devices may require appropriate permissions or a running TPM resource manager.

On Windows, use an elevated PowerShell session to query firmware Secure Boot support and TPM status:

Confirm-SecureBootUEFI
Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerIdTxt

Confirm-SecureBootUEFI reports whether Secure Boot is enabled on a supported UEFI system; it can fail on legacy BIOS boot or unsupported firmware. Get-Tpm distinguishes a missing TPM from one that is present but not ready. For a complete fleet assessment, combine these local checks with centralized policy and attestation reporting rather than treating a single command as proof of platform integrity.

Common Misconceptions

“Secure Boot and measured boot are the same feature.” Secure Boot checks whether an image may execute; measured boot records what contributed to startup. One can be enabled without the other.

“A TPM proves the computer is trustworthy.” A TPM can protect keys and sign measurements, but it does not decide whether a measured configuration is acceptable. A verifier must validate fresh evidence against a suitable policy and trusted baseline.

“If Secure Boot is enabled, the entire operating system is verified.” Firmware checks the EFI images within its policy boundary. Later components need their own verification policy, and runtime applications are not automatically covered by firmware Secure Boot.

Changelog

Initial publication.

Last updated: 2026-10-10