What breaks when Android Key Attestation is relayed through another device?

What breaks in the trust chain when attestation is relayed?

Relayed Android key attestation breaks the assumption that the attestation reflects the same local device that initiated the request. The backend may still receive a valid, hardware-backed-looking response, but it no longer has a reliable provenance chain from request to device. That means attestation stops being deterministic proof of local device integrity and becomes only a signal that must be correlated with other evidence.

The practical failure is not just “the answer can be forged.” It is that the trust model silently changes. If a control treats attestation as a direct statement about the requesting handset, relay turns that statement into a remote proxy for another device or execution path, which can preserve cryptographic validity while destroying the security meaning of the result.

A useful way to frame this is that the attestation object may still be authentic, but the provenance is no longer sufficient. If your policy expects the key material, device state, and request origin to be bound together, relay breaks that binding even when the certificate chain and hardware indicators still verify cleanly. That is why the control fails at the decision layer, not at the verification layer.

Which assumptions in device trust and policy enforcement stop holding?

Any backend policy that equates a valid attestation response with “this exact device is trustworthy right now” becomes unsafe. Device enrollment, posture checks, conditional access, and high-risk transaction approval can all be bypassed if they rely on attestation as a standalone proof. The same issue appears when teams use attestation as a one-time bootstrap for ongoing trust without rechecking whether the response is still tied to the original device context.

Relay also weakens any control that assumes attestation proves resistance to emulation, virtualization, or compromise on the client side. If the backend cannot verify that the attestation was generated in the same physical context as the session it protects, then the result may support a device-class claim, but not a request-origin claim. Device and IoT Identity Guide is a useful broader reference because it treats attestation as part of device trust, onboarding, and lifecycle, not as a standalone trust verdict.

This is why provenance correlation matters more than cryptographic validity alone. Backend logic should compare the attested identity, the session origin, the enrollment history, and the expected device binding. If those signals do not line up, a “successful” attestation should be treated as incomplete evidence rather than as a pass condition.

How should teams design controls so relay does not become a blind spot?

Use attestation as one input to a composite trust decision, not as the only gate. The strongest designs bind attestation to enrollment records, per-device keys, session context, and transaction-level checks so that a response is only accepted when it is consistent with the known device and request path. Where the platform allows it, validate freshness, challenge-response behaviour, and any available proof that ties the response to the active session rather than to a reusable remote relay path.

Teams should also treat relay resistance as an architecture question, not just a cryptography question. If the relying party cannot distinguish local from relayed execution, then policy needs compensating controls such as step-up verification, device binding, risk-based re-authentication, or narrowing the actions permitted after attestation. The point is to make the security decision depend on multiple correlated facts, not on a single apparently hardware-backed blob.

For related identity and trust patterns, SPIFFE workload identity specification is a useful conceptual comparison because it emphasises workload identity, trust bundles, and attestation as part of an end-to-end trust model rather than as isolated evidence. For mobile and device environments, NIST AI Risk Management Framework is not the right control plane here, but a more relevant external reference for trust decisions is NIST SP 800-63 Digital Identity Guidelines, which reinforces the idea that authenticators and evidence must be evaluated in context, not in isolation.

Risk and Threat Considerations

Relayed attestation creates a trust-substitution risk: an attacker can preserve the appearance of a valid device signal while shifting the actual execution to another endpoint. That is especially dangerous when attestation gates enrollment, privileged actions, or fraud-sensitive transactions, because the backend may overestimate the assurance it has about the originating device.

Failure mechanism: The backend accepts a valid attestation response without verifying that the response is cryptographically and procedurally bound to the same physical device, session, and request origin, so a remote device can act as a proxy.

Impact: Controls that depend on attestation for device integrity, anti-emulation, or step-up approval can be bypassed, enabling unauthorized access, fraudulent approval, or poisoned trust state at scale.

Practitioner Guidance

What to verify: Check whether your backend can correlate attestation with device enrollment state, request origin, freshness, and expected key binding. If any of those are missing, do not treat attestation as deterministic proof of device integrity.

Decision rule: If attestation is used to authorize a sensitive action, require an additional binding signal or a second trust factor; if it is only used as a risk signal, keep it advisory and measure it against observed device consistency over time.

Common mistake: Trusting a hardware-backed result because the certificate chain validates. That proves the attestation object can be trusted as an object, not that the backend can trust the claimed device relationship.

Practitioner takeaway: The security question is not whether attestation is genuine, but whether it still refers to the same device and request that your policy is trying to protect.

Related resources from NHI Mgmt Group

• What breaks when device certification is treated as enough security assurance?
• What breaks when SSH endpoints cannot negotiate post-quantum key exchange?
• What breaks when device certificates are not tied to endpoint approval?
• What breaks when code signing is treated as a key-storage problem only?