App Attest proves to your server that a request was signed by a hardware-backed key belonging to a genuine instance of your app on an Apple device. It does not prove who the user is, and it is not a replacement for authentication or server side authorization.
What the service is
App Attest is part of Apple's DeviceCheck framework. The app asks the operating system to create a key pair, and the private half is kept in the Secure Enclave, where Apple's documentation says no process can read or modify it. Apple's servers then certify that the key belongs to a valid instance of your app.
Apple's stated reasoning is simple: your app's own logic cannot check itself, because a compromised app can falsify the result. So the check happens on your server, using cryptographic evidence from Apple.
The flow in four steps
- Check availability. Not every device supports the service, so the app reads an isSupported property first. Your server has to cope with devices that cannot attest.
- Generate a key. The app creates one key pair for each user account on each device and stores the returned key identifier, because there is no way to get the identifier later.
- Attest the key. Your server issues a one time challenge of at least 16 bytes. The app hashes it and asks Apple to attest the key. The app sends the attestation object and key identifier to your server, which verifies it.
- Assert on sensitive requests. For later requests, your server issues a fresh challenge, the app combines it with the request, signs the hash with the key and sends the assertion along. Your server verifies it.
The one time challenges are what stop replay. Without them an attacker could record a valid attestation or assertion and reuse it.
What it proves and what it does not
| Question | Answer |
|---|---|
| Is this request from a genuine copy of my app? | Yes, if the assertion verifies |
| Is the device unmodified? | Mostly, though Apple notes an attacker who modifies the operating system might bypass restrictions |
| Who is the user? | Not answered, you still need sign in |
| Is this user allowed to access this record? | Not answered, check authorization on the server |
| Is one device serving many fake clients? | You can estimate it from Apple's attestation count metric |
Apple recommends not reusing a key among multiple users on a device. Its fraud risk guidance describes a server side receipt check that returns an approximate count of unique attestations for your app on one device. A count higher than expected may point to a compromised device serving many instances of the app.
Practical notes for API owners
Reserve assertions for sensitive moments, such as downloading premium content or changing account details. Apple says there is no limit on the number of assertions per key, but signing every request adds latency and server work with little extra benefit.
Keys do not survive reinstallation, device migration or restoring from a backup, so plan for a clean re-attestation path. Keep new key generation to those events and to new users, since a low key count per device makes fraud easier to spot.
If your app already has a very large number of daily users, Apple publishes separate guidance on ramping attestation up safely. Read it before you switch it on for everyone at once.
For development, Apple provides a sandbox environment, and receipts from one environment cannot be used in the other.
Where it sits in your design
Treat attestation as one signal. A request that passes attestation still needs a valid access token, scope checks and object level authorization. A request that fails attestation might simply come from an unsupported device, so decide in advance whether failure means block, step up or log only.
Safeguard does not provide app attestation. It can help you see which dependencies ship inside your iOS and Android builds through SBOM and dependency scanning, and you can start with the free scan at gold.safeguard.sh/scan.
Quick check
Does App Attest replace user login?
No. It speaks about the app instance, not the person. Keep OAuth or session authentication and server side authorization.
Should the app decide whether attestation passed?
No. The verification must run on your server, because app side checks can be falsified.
What happens on devices that do not support it?
Apple says the app should gracefully bypass the service and your server must stop requiring assertions for that device. Decide what extra checks apply instead.
Sources
Last reviewed: 19 October 2026.
