Two different boot claims
Secure boot verifies each next component against an authorization policy before execution. It can stop unsigned, revoked, or otherwise unapproved firmware and software. Measured boot records cryptographic measurements of selected components and configuration into protected state and an event log for later appraisal.
Secure boot answers whether a component is authorized to run. Measured boot records what the measurement chain observed. A system can use either or both.
Chain of verification and measurement
The chain starts at a root of trust. Each stage verifies or measures the next stage before control passes. The design must cover firmware, option ROMs, boot loader, kernel, initial filesystem, critical configuration, and any later code relevant to the claim.
Measurements need an ordered log and protected accumulators such as TPM platform configuration registers. A hash alone has no meaning without component identity, version, order, configuration, reference values, and a trusted account of how it was measured.
Update, revocation, and recovery
Define trusted keys, allowed versions, rollback policy, key rotation, and emergency recovery. Protect reference values and revocation data. Test power loss and partial update. The system must recover from unauthorized or corrupted firmware through a protected mechanism that does not accept arbitrary older code.
Cryptographic agility matters because boot verification keys and algorithms can outlive ordinary application releases. A lost root key or unsafe recovery key can strand a device or authorize malicious code.
Failure and residual risk
Authorized software can contain vulnerabilities. A measurement can omit a device, configuration, mutable data, late-loaded code, or runtime compromise. Rollback to an old signed version can restore a known vulnerability. A valid event log can be misappraised against stale or incomplete reference values.
Boot integrity does not protect application data after an authorized process receives it. It also does not prove that the physical device is untampered or that the current running state still matches boot.
Pomerium boundary
Pomerium relies on the integrity of the platform where it runs. It does not establish that platform's secure-boot keys, firmware measurements, reference values, or recovery path. Operators can use verified platform state as one input to workload or device trust, but Pomerium route policy must not treat a boot result as application authorization.
Evaluation checklist
- Which stages are verified, which are measured, and which mutable configuration or late-loaded code is omitted?
- Who authorizes signing keys, versions, reference values, revocations, and rollback exceptions?
- Can an attacker boot an older signed component or use an unmeasured recovery path?
- Does appraisal bind the ordered event log to protected registers and a fresh device report?
- Can the platform recover securely after corrupt firmware, key loss, or an interrupted update?
