Measured Boot vs Secure Boot: Choosing Between Prevention and Proof

Secure Boot stops code it has been told not to trust, measured boot records what actually ran, and many fleets switch on both without deciding which one their access and response processes depend on. The result is predictable: Secure Boot is enabled everywhere and assumed to be sufficient, while TPM measurements accumulate on every device and nobody checks them. This guide treats the two as a design decision for fleets of laptops, servers and cloud virtual machines: what each one defends against, how each one fails, which PCRs matter, how attestation turns measurements into device trust signals for access, and how to roll out the combination safely. It assumes you know the basics of UEFI and the TPM; the boot chain itself is covered in the Firmware and Boot Security Guide, and the Windows and Apple attestation services in TPM and device attestation for enterprise endpoints.

Key takeaways

• Secure Boot prevents, measured boot proves. Secure Boot refuses to run unsigned or revoked boot code; measured boot blocks nothing and produces evidence that only a remote verifier can judge.
• Each covers the other's blind spot. Secure Boot trusts anything validly signed, including old vulnerable boot managers; measured boot sees those but cannot stop them.
• Measurement without a verifier is wasted. A TPM full of PCR values only matters if something compares them to a known-good reference and acts on the result.
• BlackLotus showed why you need both. NSA's mitigation guide explains that it loaded through signed boot managers that Secure Boot still trusted, while TPM attestation on PCRs 4 to 7 could flag infected machines.
• The access decision is where measurement pays off. Feed attestation results into conditional access or network admission, start in report-only mode, and plan for the PCR churn that firmware updates cause.

The short answer

Do not choose between them: Secure Boot is the baseline for every UEFI device, and measured boot with remote attestation is the layer you add when a device's boot state should influence what it is allowed to reach. Microsoft's description of the Windows boot process draws the line clearly. Secure Boot, Trusted Boot and Early Launch Anti-Malware each refuse to load something untrusted. Measured Boot instead lets "a trusted server on the network" verify the integrity of startup, and the server can then send the device to a quarantine network or the full network. Microsoft also states why the verdict must be remote: "you can't trust the client to tell you whether it's healthy."

NSA's TPM use cases guidance (November 2024) makes the same point in one line: the TPM observes but does not enforce, Secure Boot can enforce, and the two are complementary. The real decision is therefore how much you invest in the proving side: which devices are attested, by which verifier, against what reference, and what happens when a device fails.

Prevent versus prove

Threat model for each control

Secure Boot

Defends against: unsigned bootkits and boot loaders (ATT&CK T1542.003 Bootkit), replacement of the boot manager with arbitrary code, and boot drivers that are not signed by a trusted authority. Without it, as Microsoft puts it, a PC runs whatever boot loader is on the disk and cannot tell a trusted operating system from a rootkit.

Fails when: a signed component is vulnerable and not yet revoked; an attacker with physical or firmware access enrols their own key or turns Secure Boot off; the third-party UEFI CA is trusted and a signed third-party loader has a flaw; or administrators disable it to get a tool or driver working and never turn it back on. It also says nothing about the firmware below it (ATT&CK T1542.001 System Firmware), which is the job of firmware verification and platform protections.

Measured boot

Defends against: undetected change. Downgrade to an old signed boot manager, a changed Secure Boot configuration, an added option ROM or an enrolled Machine Owner Key all alter specific PCRs, so a verifier can see them even when Secure Boot was satisfied.

Fails when: no verifier exists; the reference is wrong or too permissive; the verifier accepts self-reported health instead of a TPM-signed quote; the response is only an alert nobody triages; or the compromise happens after boot. NSA's BlackLotus guide notes a subtler timing gap: implantation happens after that boot's measurements are taken, so the infection appears in PCRs at the next reboot, not immediately.

BlackLotus: the case for combining them

NSA's June 2023 BlackLotus Mitigation Guide is the clearest public account of why enforcement alone is not enough. BlackLotus exploits Baton Drop (CVE-2022-21894) by installing an older Microsoft-signed Windows boot manager that Secure Boot still trusts because it had not been added to dbx. It then installs its own shim with a Machine Owner Key, so Secure Boot appears to be enforcing while it has been subverted. NSA warns that published patches could give a false sense of security, because patching the boot manager logic does not revoke the old binaries.

On the proving side, NSA says the TPM can detect BlackLotus but not prevent it, and that in a network access control design based on TPM attestation, changes in PCRs 4 to 7 can flag infected machines and block them from protected resources until remediated. NSA also advises leaving Secure Boot enabled in standard mode rather than customising it, notes that adding dbx hashes has limited long-term effect because there are more vulnerable loaders than dbx can hold, and recommends integrity monitoring of the EFI system partition. The follow-on revocation work, including the 2011 certificate expiry, is in Secure Boot Certificate Expiry 2026. For response steps if you find a bootkit, see the Firmware and Bootkit Compromise Playbook.

TPM PCRs that matter for the decision

PCRs 0 to 7 belong to firmware under the TCG PC Client Platform Firmware Profile (latest version 1.06 revision 52, December 2023); higher PCRs are allocated by operating system components. The UAPI Group's Linux TPM PCR Registry lists the common allocation, summarised below. Confirm your platform's documentation before writing policy, because higher PCR use differs between Windows and Linux boot chains.

The registry notes that PCR 0 changes on firmware updates and PCR 1 on hardware replacement. That is the central operational tension: the PCRs that best prove integrity are the ones that legitimate maintenance changes. The Keylime project's design documentation addresses this by preferring validation of the UEFI event log with a policy engine over static PCR values, because static values break whenever boot chain components change. Event log policy lets you say "boot manager signed by an allowed authority, version at or above N, Secure Boot on" rather than "PCR 4 equals this hash".

Turning measurements into device trust signals for access

1. Identity of the TPM: the endorsement key shows the device has a genuine TPM. NSA notes that the EK cannot sign or attest, so an identity or attestation key created at deployment signs the quotes. Record EK and platform certificate data in the asset inventory.
2. Quote and log: the verifier sends a fresh nonce, the TPM signs the PCR values, and the device returns the quote with the event log.
3. Appraisal: the verifier replays the log, checks it matches the quoted PCRs, and applies policy: Secure Boot on, approved boot manager, no unexpected MOK, approved firmware.
4. Verdict: the result becomes a claim (healthy, unhealthy, unknown) with a time stamp, passed to the policy engine.
5. Enforcement: conditional access requires a healthy verdict for sensitive applications, network admission places failures in a remediation segment, and key release services refuse secrets to unhealthy hosts.

On Windows, the management platform calls the attestation service and turns the report into a compliance state; the field-level detail, freshness limits and the difference between a TPM presence check and real attestation are covered in TPM and device attestation for enterprise endpoints. Microsoft notes that Windows supplies the APIs for Measured Boot but a remote attestation client and trusted attestation server are needed to use it. On Linux, Keylime provides an agent, registrar and verifier; its verifier can send revocation messages when an agent fails, so other systems can withdraw trust automatically. NSA's guidance adds that trustworthy appraisal depends on reference integrity manifests from hardware and OS vendors, and that few vendors publish them yet, so most organisations build their own references from a golden image per model.

Where identity fits: an attested device is a machine identity with a verifiable state. Bind device certificates and workload credentials to TPM keys, and make credential issuance or renewal depend on a passing attestation, so a host that boots into an unexpected state cannot obtain new secrets. See the Device Trust and Posture Guide.

Servers and cloud virtual machines

Cloud platforms offer virtual TPMs, Secure Boot and boot integrity checks for virtual machines, so the same prevent-and-prove model applies to workloads. These are customer-side settings in a shared responsibility model. Platforms are listed alphabetically.

• Amazon Web Services: UEFI Secure Boot for EC2 ensures an instance boots only software signed with keys held in the UEFI variable store. NitroTPM is a TPM 2.0 virtual TPM: the boot loader and operating system extend boot binary hashes into its PCRs, and it provides signed PCR values so remote parties can verify boot integrity, or seal keys to known-good PCR values. An AMI must be configured for NitroTPM support.
• Google Cloud: Shielded VM combines Secure Boot, a TPM 2.0 vTPM and Measured Boot. The first boot creates an integrity policy baseline; integrity monitoring reports separate early boot and late boot pass or fail results in Cloud Logging and Cloud Monitoring. After an expected change such as an update, you update the baseline; after an unexpected one, stop the VM and investigate. vTPM and integrity monitoring are on by default.
• Microsoft Azure: Trusted Launch for Generation 2 VMs provides Secure Boot (a VM fails to boot if validation fails), a TPM 2.0 vTPM that measures the boot chain, and boot integrity monitoring through guest attestation in Defender for Cloud, which needs Secure Boot, vTPM and the Guest Attestation extension. A VM attestation failure alert fires when the boot log deviates from the baseline. Trusted Launch is the default for new Gen2 VMs created in the portal.

For physical servers, attestation has the most value where hosts receive secrets automatically (disk keys, workload credentials, cluster join tokens), because a key release gate is the strongest enforcement point measurement can drive.

Decision criteria

Small organisations: buy hardware with TPM 2.0 and Secure Boot on by default, keep Secure Boot enforced, apply revocation updates through the vendor's channel and read the Secure Boot state from your device management tool. That is still enforcement, not attestation, but it is the right first step. Large organisations: attest privileged access workstations and servers first, where the access decision is valuable and hardware is uniform, then extend to the general fleet.

Worked scenario

A financial services firm has 9,000 Windows laptops, 600 Linux servers and a cloud estate. Secure Boot is reported as enabled on 97 per cent of laptops; nobody uses the TPM beyond BitLocker. After reading the BlackLotus guidance, the security team wants device boot state to gate access to trading and admin systems.

1. Baseline enforcement: find the 3 per cent with Secure Boot off, fix or replace them, and confirm current dbx and boot manager revocations through the vendor channel in pilot rings, keeping recovery media updated first.
2. Attest the high-value group: 400 privileged access workstations get a health attestation compliance requirement in report-only mode for four weeks. The team logs which failures come from firmware updates and which are unexplained.
3. Tune references: firmware updates cause most failures, so the team ties attestation policy to the firmware versions approved per model and schedules updates through change records.
4. Enforce: conditional access requires a healthy verdict for admin portals; failures receive a remediation path through the service desk instead of a hard block on email.
5. Servers: Linux hosts that unlock disks automatically are enrolled in Keylime with an event log policy; a failed attestation stops credential renewal and pages the platform team. Cloud VMs have Secure Boot, vTPM and the platform's integrity monitoring enabled, with alerts sent to the SOC.

Rollback at every step is a policy change back to report-only, not a change to the devices, which keeps the blast radius of a bad reference small.

How to implement

1. Inventory: TPM version, Secure Boot state, firmware version and boot manager version per device; flag anything without TPM 2.0 or UEFI.
2. Enforce Secure Boot everywhere: standard mode, third-party CA only where needed, admin rights to change firmware settings protected by firmware passwords.
3. Apply revocations carefully: update recovery and installation media first, then roll dbx and boot manager updates through rings, watching for BitLocker recovery prompts caused by PCR 7 changes. See BitLocker.
4. Choose a verifier: your device management platform's health attestation for endpoints, an open-source or commercial verifier for servers, the platform service for cloud VMs.
5. Build references: per hardware model and image, from golden devices; prefer event log policy over raw PCR hashes.
6. Report-only first: collect verdicts, measure false failure rates, fix the update process that causes them.
7. Enforce in rings: privileged workstations, then servers that receive secrets, then the general fleet.
8. Define response: what an unexplained failure triggers: isolation, reimaging, firmware reflash or bootkit investigation.

Detection and measurement

• Attestation results: failed and missing verdicts by device, with the PCRs or log events that caused them.
• Secure Boot state changes: any device reporting Secure Boot off, and any change in PCR 7 outside a revocation rollout.
• EFI system partition changes: new or modified boot manager and shim binaries, as NSA recommends monitoring.
• Cloud integrity events: early and late boot failures, baseline updates and vTPM clears, all reconciled with change records.

Common failure patterns

• Secure Boot treated as a full answer. Signed but vulnerable boot managers stay trusted until revoked, which is the gap BlackLotus used.
• Measuring with no verifier. Every TPM records PCRs and nothing compares them to a reference.
• Raw PCR pinning across a mixed fleet. Every firmware update fails thousands of devices, and the policy is switched off within a month.
• Self-reported health accepted as attestation. A compliance check that reads a local setting, or only checks for TPM presence, is not proof of boot state.
• Alerts without consequences. Failed attestations go to a dashboard but do not change access, so an attacker loses nothing.
• Revocations skipped for fear of breakage. Recovery media and older devices are not prepared, so dbx updates are postponed indefinitely.

Framework mapping

Technique and mitigation detail: MITRE ATT&CK T1542 Pre-OS Boot, M1046 Boot Integrity, D3-BA Bootloader Authentication and D3-TBI TPM Boot Integrity.

Practitioner checklist

• Enforce Secure Boot in standard mode on every UEFI device and track exceptions.
• Apply dbx and boot manager revocations through rings, updating recovery media first.
• Decide which device groups need attestation, starting with privileged workstations and secret-receiving servers.
• Use a remote verifier with TPM-signed quotes and nonces, never self-reported health.
• Prefer event log policy over raw PCR hashes, and tie references to approved firmware versions.
• Run attestation in report-only mode before it gates access.
• Connect attestation verdicts to conditional access, network admission or key release.
• Enable Secure Boot, vTPM and integrity monitoring on cloud VMs and route alerts to the SOC.
• Define the response to an unexplained failure before you enforce.

Standards and references

• NSA: BlackLotus Mitigation Guide
• NSA: Trusted Platform Module Use Cases
• Trusted Computing Group: PC Client Platform Firmware Profile Specification
• Microsoft: Secure the Windows boot process
• UAPI Group: Linux TPM PCR Registry
• Keylime: Design overview
• MITRE ATT&CK: T1542 Pre-OS Boot
• MITRE D3FEND: TPM Boot Integrity

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · TPM and device attestation for enterprise endpoints · Linux Secure Boot and Shim Guide · Hardware Root of Trust Guide · Secure Boot Certificate Expiry 2026