Entity Attestation Token (EAT)

What EAT is used for

Entity Attestation Tokens exist to let systems speak about an entity, such as a device or workload, with machine-readable evidence instead of assumption. That matters because defenders can verify provenance, freshness, and claim integrity before granting trust.

An EAT is most useful at trust boundaries, where one system must decide whether another system is genuine, healthy, or operating in an expected state. The token becomes part of the decision trail, not a replacement for policy or validation.

What an EAT contains

An EAT can carry claims about measured state, identity, and other trust evidence. In practice, that means the token may describe what the entity is, what state it reported, and how recent that evidence is.

The practical value comes from portability and consistency. A single attestation format can be moved across components and checked by different verifiers, which helps standardise trust decisions across fleets, platforms, and integrations.

Why EATs matter for trust decisions

EATs reduce blind trust by letting a verifier inspect claims before accepting an entity as trustworthy. They are especially important where the entity cannot be treated as inherently reliable just because it connected successfully.

That makes the token useful for device posture checks, workload admission, and any control that needs evidence of state rather than simple possession of a credential. When used well, the attestation becomes a compact signal for policy enforcement.

Related identity and trust concepts are often easier to understand alongside SPIFFE workload identity concepts, since both deal with machine trust and verification.

Common validation and failure points

Defenders should expect to validate the issuer, freshness, and claims in every token before relying on it. A token that is stale, unverifiable, or inconsistent with the expected environment should not be treated as a valid trust signal.

EATs fail when attackers can replay old attestations, forge claims, or exploit weak issuer validation. They also fail when the verifier accepts the token format but does not actually enforce the claims it receives.

For adjacent control patterns, workload attestation in SPIFFE and OpenID Connect Core 1.0 show how identity and trust evidence are validated in other ecosystems.

Risk and Threat Considerations

EATs create a high-value trust signal, so failures in issuer validation, freshness checks, or claim verification can let an untrusted entity appear legitimate. The main danger is not the token itself, but misplaced reliance on claims that were never properly authenticated or that are no longer current.

Failure mechanism: Attackers can replay stale attestations, substitute forged tokens, or exploit verifiers that accept claims without checking issuer trust and token age. If the verifier trusts the token more than the evidence behind it, a compromised entity can keep access after its real state has changed.

Impact: A bad attestation decision can admit unhealthy devices, untrusted workloads, or impersonated entities into sensitive systems, which can extend compromise, weaken segmentation, and undermine downstream authorization decisions.

Practitioner Guidance

Why practitioners should care: Treat EAT validation as part of access decisioning, not as a logging artifact. The verifier should be the policy checkpoint that decides whether the entity’s claims are current, trustworthy, and consistent with the intended trust model.

What to watch for: Stale tokens, unverifiable issuers, missing claim checks, and environments where attestation is collected but not enforced are the usual signs of weak implementation. Where attestation backs admission or privilege decisions, the surrounding trust lifecycle should be reviewed as carefully as the token format itself.

Related resources from NHI Mgmt Group

• Should organisations prioritise runtime attestation over faster token rotation?
• Why do mobile APIs need attestation and token binding?
• Why is OAuth token management critical in cloud environments?
• How should organizations respond to OAuth token abuse incidents?