Why do app attestation and device attestation not solve relay attacks on their own?

What app and device attestation actually prove

app attestation and device attestation are integrity signals, not user-authentication proofs. They tell the relying service that the request came from a genuine app on a genuine, trusted device state, which is valuable for blocking tampered clients, rooted phones, emulators, and obvious automation. They do not, by themselves, establish who is physically holding the device or whether that person is the authorised user.

That distinction matters because the control answers a different question from the one a relay attack exploits. A relay attack preserves the legitimacy of the device and app while changing who is operating them, so the attestation can still succeed even though the human is not the expected one.

How relay attacks bypass the trust model

In a relay attack, an attacker uses a live, legitimate device session as a proxy rather than forging the device itself. The remote operator can trigger a valid attestation flow, pass challenge-response checks, and reuse the phone’s existing trust posture, while the authorised person is absent or unaware. That is why attestation is useful for client integrity, but weak as a standalone anti-relay control.

The practical failure mode is trust transfer. If the application treats attestation as a substitute for user presence, it may approve a high-risk action, because the proof describes the device and app state, not the proximity, intent, or immediate participation of the human. For transaction approval, that gap is the important one.

What has to be added to stop relay abuse

To resist relay attacks, the service needs a second layer that binds the proof to the transaction and to the present user. That usually means step-up authentication, transaction signing, explicit user verification at the moment of approval, or another control that checks for live presence rather than just device integrity. The exact method depends on the risk of the action and the assurance level required.

For mobile and endpoint-focused implementations, the attestation signal should be treated as one input into a broader trust decision. NHIMG’s Mobile App Security Testing Guide is useful where teams need to validate app attestation, runtime protections and the limits of client-side trust, while the Device and IoT Identity Guide helps frame device trust, certificates and attestation as part of a device identity lifecycle rather than a user-proofing mechanism.

Risk and Threat Considerations

Relay attacks are especially effective when organisations over-trust possession of a legitimate device. If attestation is accepted as proof of the authorised person, a remote operator can approve sensitive actions through a real phone without breaking the attestation model.

Failure mechanism: The control validates device integrity and app authenticity, but it does not bind that proof to a live, authorised human at the moment of use, so a legitimate session can be relayed or proxied.

Impact: Fraudulent approvals, unauthorised transactions, account compromise, and bypass of controls that assume attestation alone implies user legitimacy.

Practitioner Guidance

What to verify: Verify that the attestation result is consumed as a device-trust input, not as a stand-alone approval condition. For any high-risk workflow, check whether the system also requires a live user action that cannot be replayed remotely.

Decision rule: If the transaction can cause material loss, account takeover, or privilege escalation, require an additional user-presence or transaction-binding control before relying on attestation. If the action is low risk, attestation may be sufficient as a gate against tampered clients, but not as anti-relay assurance.

Practitioner takeaway: Attestation raises confidence in the endpoint, not in the person, so the control only becomes relay-resistant when the transaction itself is separately bound to a live human decision.

Related resources from NHI Mgmt Group

• Who should own mobile app attestation policy and exception handling?
• What is the difference between local device checks and remote attestation for Android app security?
• What is the difference between device attestation and origin validation?
• Why do short-lived credentials not solve healthcare identity risk on their own?