How does trusted boot work?

Trusted boot is a startup process that measures each boot component before it runs and records those measurements for later verification. If firmware, bootloader, or kernel code changes unexpectedly, the recorded measurements no longer match. Defenders compare the measured values against known-good baselines to detect tampering, malicious firmware, or unauthorised boot changes.

What trusted boot verifies before code is allowed to run

trusted boot is not a single check, it is a chain of measurement. Each stage, starting with firmware and continuing through the bootloader and kernel, is measured before execution, so the platform can later prove what actually started the system. The key idea is that the boot path becomes observable, not just trusted by assumption.

That makes trusted boot useful when you need evidence of the startup state rather than a simple yes or no on whether boot succeeded. It is especially valuable when defenders need to distinguish a normal boot from one altered by firmware tampering, bootloader replacement, or other pre-OS manipulation.

How the measurements are recorded and checked

In a trusted boot flow, the platform records hashes or similar measurements into a protected store during startup. Those records are then compared against a known-good baseline, either locally or during attestation. If a component changes, even if the machine still boots, the measurement chain no longer matches the expected values.

The value is in the comparison, not just the measurement. A changed measurement may point to an approved update, a configuration drift, or an unauthorised modification, so defenders need context for the baseline they trust. A clean result says the boot path matched expectation; a mismatch says it did not, and that difference deserves investigation.

For teams building boot integrity into wider firmware assurance, Firmware and Boot Security Guide covers the surrounding controls that make measurement useful, including Secure Boot, TPM attestation, and bootloader integrity.

Why trusted boot matters when the earliest code is the target

Trusted boot matters because attackers who reach firmware or pre-OS code can shape everything that follows. If malicious code starts before the operating system, it can hide from many endpoint controls, interfere with security tools, or persist across reinstallations. Measurement does not stop that by itself, but it exposes the change so defenders can act on it.

It is also useful for spotting subtle integrity failures. A platform may appear healthy, yet still have been started with altered firmware, a modified boot chain, or a bootkit that survived a previous compromise. Trusted boot gives security teams a way to detect that the startup trust assumption has been broken rather than assuming the running OS is necessarily clean.

Risk and Threat Considerations

Trusted boot reduces blind spots at the point where compromise is hardest to see, but it does not remove the threat. If the baseline is weak, if measurement records are not protected, or if teams ignore mismatches, an attacker can still gain durable pre-OS persistence and operate below the visibility of normal host controls.

Failure mechanism: An attacker alters firmware, the bootloader, or another early boot component, then relies on the system to start normally while the integrity change remains undetected or uninvestigated.

Impact: Defenders may lose trust in the platform state, and the compromise can survive routine OS-level remediation, making recovery slower and more disruptive.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AU-2 — Event Logging	Trusted boot depends on recorded startup evidence for later review.
	SI-7 — Software, Firmware, and Information Integrity	Boot measurements detect unauthorized firmware or boot chain changes.
	CM-5 — Access Restrictions for Change	Unauthorised boot changes are a change-control and integrity problem.
Recommendation — Log boot measurements and review mismatches as integrity events. Use integrity checks to detect altered boot components before trust is granted. Restrict who can modify firmware and boot components.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Trusted boot relies on controlled baselines for early-boot components.
Recommendation — Maintain approved configurations for firmware and boot loaders.
CIS Controls v8	CIS-5 — Account Management	Boot-chain integrity failures often require rapid privileged-response coordination.
Recommendation — Limit privileged access that can alter firmware and boot settings.

Practitioner Guidance

What to verify: Treat the baseline as part of the control, not an afterthought. Verify that measurements are being captured from the earliest boot stages, that the comparison source is known-good, and that the measurement store or attestation path is itself protected from tampering.

Decision rule: If the measurement changes after a firmware update or approved maintenance window, reconcile it against change records before escalating. If it changes outside an expected change path, treat it as a potential integrity event and investigate the boot chain before trusting the host.

Practitioner takeaway: Trusted boot is only useful when a measurement mismatch triggers action, because the control’s value comes from proving startup integrity, not from simply recording that the machine booted.