Evidence about a target environment
Platform attestation is a procedure in which an attester produces protected evidence about a target platform, a verifier appraises that evidence against reference values and policy, and a relying party uses the attestation result in its own decision. The claim can cover identity, composition, configuration, measured state, boot history, or another defined property.
Attestation does not mean "the device is secure." It supplies bounded evidence to a named decision.
Roles and messages
Separate the attester, target environment, verifier, endorser, relying party, and owner. The attester collects or signs evidence. Endorsers supply claims and reference material about components. The verifier checks authenticity, freshness, evidence semantics, reference values, revocation, and appraisal policy. The relying party decides what the result permits.
Keep evidence appraisal separate from the final access decision. A valid known measurement can still be unacceptable for a sensitive action because the platform is obsolete, unmanaged, in the wrong tenant, or missing current risk signals.
Freshness, identity, and reference values
Bind evidence to a fresh challenge, epoch, or protected freshness mechanism. Authenticate the attestation key and its relationship to the target platform. Validate the complete measurement log, not only final register values. Maintain reference values for approved versions and configurations with issuer, validity, revocation, and update state.
Record what was not measured. Late-loaded code, runtime state, peripherals, user space, and mutable data can sit outside the evidence scope.
Failure and residual risk
Replay can make old good evidence look current. A compromised attester can omit evidence if the verifier does not know the expected set. Stale reference values can approve vulnerable software or reject safe updates. A privacy-sensitive platform identifier can enable tracking. A verifier outage can block access or tempt unsafe bypass.
Attestation observes a defined state at a time. It does not prove future behavior, absence of all compromise, correct application logic, or that an authorized process will use data safely.
Pomerium boundary
Pomerium can consume documented device or identity signals and apply them in route policy. It does not serve as a general platform attestation verifier for arbitrary TPM, TEE, or firmware evidence. Operators own evidence collection, verifier trust, reference values, freshness, privacy, lifecycle, and the mapping from an attestation result to an access rule.
Evaluation checklist
- Which attester, target environment, verifier, endorser, relying party, and owner perform each role?
- What exact component, state, configuration, and time does the evidence cover or omit?
- How are freshness, attestation-key identity, reference values, revocation, and appraisal policy validated?
- Can a valid but obsolete, partial, replayed, or privacy-invasive result still pass?
- What independent conditions must the relying party check before it grants the requested action?
