A foundation for a narrow function
A root of trust is a component that must be trusted because another security function starts from it. A hardware root of trust uses protected hardware, immutable code, fused keys, or isolated state to anchor measurement, verification, storage, reporting, update, or recovery.
There can be several roots with different purposes. A root of trust for measurement begins a measurement chain. A root for verification decides whether code may execute. A root for storage protects keys or state. A root for reporting signs evidence about a platform.
Trust chain and ownership
Name the first instruction or key, who provisions it, how a verifier authenticates it, and which later components it can measure or authorize. Define vendor, manufacturer, firmware, supply-chain, enrollment, ownership-transfer, update, revocation, and end-of-life assumptions.
A TPM provides protected operations and state. It does not decide whether every measurement is acceptable or whether software behaves safely. A secure element can protect a key while the surrounding application misuses the permitted operation.
Key and lifecycle controls
Bind each key to one purpose, policy, platform state, and authorized caller. Protect provisioning and endorsement material. Use freshness in reports. Maintain reference values and revocation. Plan replacement when hardware, firmware, algorithms, ownership, or trust policy changes.
Recovery is part of the root design. If recovery can install arbitrary firmware or extract secrets, it may be the stronger root. If no recovery exists, one fault can make the platform permanently unavailable.
Failure and residual risk
Hardware can have design defects, side channels, fault-injection paths, weak random generation, debug interfaces, compromised firmware, or counterfeit components. Vendor keys and update services remain trusted. A root can prove identity or measured state without proving physical location, current behavior, absence of malware after measurement, or safe application logic.
Hardware roots often reduce key extraction risk and can increase vendor dependency, privacy risk, replacement cost, and recovery complexity.
Pomerium boundary
Pomerium can use WebAuthn and device evidence in access decisions. It validates the documented evidence and policy inputs. It does not manufacture or independently certify the hardware root, platform firmware, authenticator, or attestation service. Operators must decide which roots, vendors, evidence, freshness, and lifecycle states meet their access requirement.
Evaluation checklist
- Which exact measurement, verification, storage, reporting, update, or recovery function starts at this root?
- Who provisions the first key or code, and how can ownership, firmware, or trust policy change safely?
- Which evidence proves freshness and binds the claim to the intended physical or logical platform?
- Which vendor, supply-chain, debug, side-channel, fault, and recovery assumptions remain?
- Does the relying party treat a narrow hardware claim as proof of unrelated application behavior?
