iOS app attestation lets your backend verify that a request comes from a genuine, unmodified copy of your app running on a real Apple device, and that the proof is fresh rather than replayed. It builds on Apple’s App Attest: a key created in the Secure Enclave, vouched for by Apple for your team and bundle identifiers, then used to sign a challenge from your server. It does not prove who the user is, and it does not see hooks inside a genuine app. Otukan handles the app side, gives your server the verification checks and adds runtime signals for what attestation cannot see. For the cross-platform view, see mobile app attestation.
Attestation versus user authentication
Teams often reach for attestation to solve a login problem, or for login to solve an app problem. They answer different questions.
| Question | Answered by | Example failure it catches |
|---|---|---|
| Is this request from our real app? | App attestation | A script replaying captured API calls |
| Is the app running on genuine Apple hardware? | App attestation | A request forged on a server farm |
| Is the app being manipulated right now? | Otukan runtime signals | A hooked transfer function in the genuine app |
| Is this the account holder? | Authentication, biometrics, step-up | A fraudster using stolen credentials in the real app |
Treat attestation as a gate on the channel. Keep authentication as the gate on the person. The strongest backends check both on every sensitive flow, and Otukan sends its runtime signals with the same request so the decision is made once, with everything in view.
Challenge freshness and backend verification
Attestation is only as strong as the server that checks it. Two exchanges matter.
First attestation
The app generates a key pair in the Secure Enclave and asks Apple to attest it, hashing in a challenge your server just issued. Your server then verifies the returned object:
- The certificate chain leads to Apple’s App Attest root.
- The embedded nonce matches your challenge.
- The identifier hash matches your team and bundle identifiers.
- The environment matches: development keys stay out of production.
- The counter starts at zero, and the public key is stored against the install.
Every protected request
Afterwards, the app signs each sensitive request together with a fresh challenge. Your server checks the signature with the stored key, confirms the challenge was issued and not yet used, and confirms the counter has increased. Reject anything that fails, and never accept a challenge twice. A step-by-step reference is in how to verify mobile app attestation.
Key lifecycle, unsupported states and failure policies
Keys do not live forever
An attested key belongs to one install on one device. Deleting the app removes it, and restoring a backup to a new phone does not bring it back. Otukan regenerates and re-attests in those cases, and your server should expect a new key for a known account rather than treat it as fraud by default. Tracking how often an account changes keys turns churn into a useful signal.
When attestation is not available
The simulator does not support App Attest, and some devices and contexts do not either. Apple’s service can also be briefly unreachable. Decide in advance, per endpoint:
| Situation | Low-risk endpoint | Sensitive endpoint |
|---|---|---|
| App Attest not supported | Allow with runtime signals | Require step-up authentication |
| Attestation service unreachable | Allow and retry later | Retry, then step up |
| Verification fails | Allow read-only | Refuse and record |
| Counter or challenge invalid | Refuse | Refuse and alert |
Rolling out to an existing user base
Every install that upgrades to the attesting version generates and attests a new key, and Apple asks developers with large audiences to spread that load rather than switch everyone on at once. Otukan lets you enable attestation for a growing share of users, starting in observe mode where failures are logged but not enforced. Your team watches verification results by app version and device, then turns enforcement on endpoint by endpoint once the numbers look as expected.
Otukan helps your team write this table for your own flows and keeps the app’s behaviour consistent with it, so each failure is handled by design rather than becoming an accidental lockout or an open door. Related controls are covered on iOS app security and in iOS app security guides.