App attestation vs device attestation

App attestation asks whether a request came from your genuine, unmodified app. Device attestation asks whether the phone it runs on is genuine hardware in an expected state: a locked bootloader, a verified operating system, a hardware-backed key. Each answers a different question, and neither tells you who the user is or whether the session has been hijacked. Useful attestation combines both kinds of evidence, binds them to the request, and lets your server decide. This article covers Android and iOS, which offer different platform services and must be treated separately.

Four kinds of evidence

People say “attestation” for several different claims. Separating them avoids trusting a result for something it never measured.

Application evidence

This says the code is yours: signed with your key, not repackaged, installed through an expected channel. On Android, the Play Integrity API returns an app integrity verdict that states whether Google Play recognises the package and certificate. On iOS, App Attest creates a key in the Secure Enclave and has Apple certify that the key belongs to a genuine instance of your app.

Environment evidence

This describes the running state: is the device rooted or jailbroken, is a debugger attached, is a hooking framework loaded, is it an emulator. Platform verdicts give a coarse view. In-app runtime checks see much more, but they run on the same device as the attacker, so their results must travel to the server as evidence rather than as a verdict.

Hardware evidence

This is device attestation in the strict sense. On Android, key attestation produces a certificate chain from the hardware-backed key store that describes the key and the device’s verified boot state and patch level. It proves properties of the device and the key. The certificate also names the package and signing certificate of the app that created the key, as the operating system reports them, but it says nothing about whether that app’s code was altered at runtime.

Identity evidence

Attestation does not authenticate a person. A stolen password typed into a genuine app on a genuine phone passes every check above. Account and session identity come from your login, step-up and device binding design.

Verification: freshness and the relying party

Evidence is only as good as the server that checks it. The relying party is your backend or gateway, and the app never tells the server whether it passed.

• Issue a challenge. Your server creates a single-use value, and the evidence must include it or a hash of the request.
• Check it where the attacker cannot. Verification runs on your side, never in the app.
• Limit its life. Evidence carries a short validity window and is accepted once, across every backend instance.
• Decide per endpoint. A balance read and a payee change deserve different thresholds and different failure responses.
• Log the failures. Rejected evidence, replays and emulator signals are the early warning your fraud team needs.

Choosing what to rely on

Read the “Leaves unknown” column first. Every row has a gap, and the user appears in all but the last. That is why sound designs combine sources rather than pick one.

Operational boundaries

Platform services have availability and quota limits, they need network access, and they do not exist on every device. Some markets use phones without Google Play services. Plan a fallback tier, test the failure path in observe mode before enforcing, and keep one verification contract for both platforms so your backend team does not maintain two logic trees.

Before you enforce

• List the endpoints that need evidence, and the failure response for each.
• Confirm every piece of evidence is bound to a server challenge or a request hash.
• Reject reused evidence across all backend instances, not only the one that saw it first.
• Decide the trust tier for devices without Google Play services.
• Run in observe mode and review the failure rate before switching to enforcement.

How Otukan brings the evidence together

Otukan gives your backend fresh, request-bound evidence that keeps app authenticity, device environment and request freshness as separate results. It works alongside Play Integrity on Android and App Attest on iOS, and labels which evidence came from the platform and which from Otukan’s own runtime checks for root, jailbreak, hooking, debugging and emulators.

Flutter and React Native apps are protected too, scoped per platform. The product control is covered on mobile app attestation.