Secure Boot and Measured Boot: Authorization and Evidence in Server Startup

Follow the image to the startup authorization decision

Consider a server beginning startup and reaching a boot-software image. With Secure Boot enforcement active, the relevant authorization check determines whether that image may run. Microsoft’s Windows overview, updated December 9, 2025, explains firmware checking boot-software signatures before passing control onward. It includes firmware drivers such as Option ROMs in its description.

The distinction is between an image carrying a signature and the platform enforcing its loading policy. A signed file sitting on storage does not demonstrate that the check was active during the startup being assessed. Nor does permission to load identify which permitted image was selected.

The Windows overview and Azure implementation illustrate different contexts. Neither defines universal measurement coverage or requires Windows on a GPU host.

References: [M1][M2]

Follow the startup sequence into a measurement record

Microsoft’s Azure host account, updated July 21, 2026, describes hash-chained boot measurements in TPM Platform Configuration Registers, or PCRs, alongside a boot configuration log called TCGLog.

Each PCR extend combines the previous accumulated value with the new measurement through hashing. A PCR accumulates measurements; it is not a separate readable slot for every image. The event log helps explain the sequence behind that accumulation, as TCG’s September 10, 2025 guidance describes.

Recording state supplies material for assessment. It does not choose the acceptable state. That distinction becomes visible when two different images are both permitted to load.

References: [M2][T1]

Images A and B are both authorized, but the expected sequence contains A

Use a fictional server and two symbolic boot-software images, A and B. Stipulate that active load policy L authorizes both images. Separately, appraisal policy P expects the earlier measured sequence containing A and requires review of a different sequence. For this example, the selected image is measured, A and B have different measurements, and the other measured events and their order remain unchanged.

The first startup selects A. Policy L permits it to run. Its recorded sequence contains A and meets P’s expectation by assumption.

A later startup selects B. Policy L also permits B to run. The recorded sequence now contains B where the earlier sequence contained A. The load decision remains affirmative while the measured state differs from P’s expectation. Under the fictional policy, that change needs review.

Suppose B arrived through a legitimate update. The measurement difference remains useful: the appraiser must reconcile the changed state with the intended update and applicable expectations. Calling the update legitimate does not make B’s sequence identical to A’s. Equally, finding a difference does not establish that B was introduced maliciously.

The buying decision is whether the proposed startup assurance connects these two questions. An offer saying only that B is authorized leaves its appraisal against P unresolved. An offer supplying measurements without an appraisal leaves the same acceptance question open. Producing the record cannot decide whether its values are acceptable.

References: [M1][R1]

Appraisal connects the evidence to an acceptance decision

RFC 9334 separates the attester producing evidence, the verifier appraising it against policy and reference values, and the relying party using the result. Those roles explain the missing step between having measurements and deciding what to trust.

TCG distinguishes checking a log against TPM-backed evidence, validating its records and evaluating policy. A plausible list of image names alone does not establish that validation or acceptance.

For A/B, the appointed team must assess the later startup under the applicable policy. An earlier acceptable result cannot silently establish the later state; RFC 9334 treats freshness as part of appraisal. Retain the actual coverage rather than reading boot evidence as an assessment of every running application.

References: [R1][T1]

The trust state is part of what needs explanation

UEFI Specification 2.11 describes image validation using authorized and forbidden signature databases. Authorization therefore has a trust context; the presence of a signature cannot be read as permanent permission to run.

The Azure implementation illustrates this distinction by checking signature and revocation database digests, the relevant keys, and whether Secure Boot is active. These are checks within Azure’s described Host Attestation Service, rather than capabilities established by a TPM label on an arbitrary server.

For an offered platform, establish which loading policy and trust state applied to the startup being appraised, and who operates the appraisal. Hardware support for recording measurements is only one part of that explanation. It does not demonstrate that an attestation service is operating or that anyone has evaluated the resulting state.

References: [U1][M2]

Keep startup evidence connected to its own question

The related factory-component guide concerns comparison of delivered hardware identities with an authenticated factory baseline. The confidential-computing guide concerns the protected runtime and its attestation boundaries. The SBOM and build-provenance guide concerns software composition and artifact production. Each supplies context for a different decision.

A factory identity record cannot answer whether the startup loading policy was enforced. A protected GPU runtime does not resolve whether the host’s measured startup met its expectations. A statement about how an artifact was built leaves its selection, authorization and measurement during a particular startup to be established. Follow those adjacent guides when those are the questions at issue; this article’s decision remains startup authorization versus recorded state and appraisal.

Connect the physical installation to the appointed platform team

Leviathan’s rack-and-stack service covers agreed equipment mounting, IT cabling, labels and physical installation records. Those records can connect installed equipment to the platform team’s asset references. They do not turn the physical handoff into an attestation result.

Security appraisal remains with the appointed platform or security team. Agreeing physical installation does not appoint the installation crew to operate attestation or change boot trust policy.

Use the related rack-and-stack service and project inquiry for the surrounding physical work. Share a nonconfidential equipment outline, site, released rack and cable plans, and requested physical handoff so scope and availability can be discussed.

References: [L1]