Attestation Policy Evaluation
Attestation policies encode the conditions under which a verified claim is sufficient to grant access, turning raw attestation evidence into a decision by comparing measured values against.
Definition
Attestation policy evaluation takes verified claims — boot measurements, signing keys, device state — and decides access by comparing them against a policy that specifies which measured values, in which combination, satisfy the trust requirement for a given resource.
Context and scope
Applied in confidential computing, secure boot, and zero-trust device access where the decision is not "is it authenticated" but "is it in a trustworthy state".
Common misconceptions
- A valid signature on the attestation means the device is trusted — the signature proves authenticity; the policy decides whether the measured state is acceptable
- Attestation is a one-time boot check — runtime attestation re-checks state, because a device can boot clean and then be compromised
Anti-patterns
- Writing policies that accept any measurement signed by the vendor, defeating the purpose of measuring
- Evaluating attestation at the gateway but not at the resource, allowing a device to attest once and then drift into untrusted state
Related concepts
Authoritative source
What it is
Attestation policy evaluation takes verified claims — boot measurements, signing keys, device state — and decides access by comparing them against a policy that specifies which measured values, in which combination, satisfy the trust requirement for a given resource. Applied in confidential computing, secure boot, and zero-trust device access where the decision is not “is it authenticated” but “is it in a trustworthy state”. The threat model determines which controls apply: preventive controls block exploits, detective controls surface violations, and corrective controls restore integrity after an incident.
How it works
Effective implementations layer controls so that no single bypass compromises the asset. Verification happens at trust boundaries, not just at the perimeter. Cryptographic primitives are selected for the concrete property needed — unforgeability, indistinguishability, or non-malleability — and never composed ad hoc. Failure modes fail closed: a verification error denies rather than allows.
When to enforce and pitfalls
Enforce wherever an attacker can influence input that crosses a trust boundary. Common pitfalls include treating obfuscation as a control, relying on secrecy of the algorithm rather than the key, and auditing the happy path while ignoring error-handling branches where bypasses often hide. Rate-limit and log every verification attempt so brute-force and oracle attacks become visible.