A mobile security team should evaluate account and installation integrity by asking one question of every sensitive request: which installation of our app sent this, and is it one we already trust for this account? Otukan answers it. Each genuine installation gets a key-backed identity, your server links installations to accounts, and clones, duplicates, installation farms and suspicious reinstalls are flagged before they inherit trust. The signal describes the app installation, not the person, so it complements your authentication rather than replacing it. Signals are built separately for Android and iOS, and the final decision always sits on your server.
What an installation signal proves
The trust claim
An installation signal says three things: this request was signed by a key that a genuine copy of your app created, that key belongs to an installation your server has already linked to this account, and the integrity checks around it passed at the moment of signing. That is a strong statement about the software and its history with the account.
What it does not establish
It does not say who is holding the phone. A family member, a coerced customer or a remote-controlled session all use a genuine installation. That is why installation integrity feeds your identity decision instead of being the decision. Pair it with your authentication factors and, for coaching or remote control, with remote access risk signals.
| Question | Installation integrity answers | Needs another control |
|---|---|---|
| Is this our genuine app? | Yes, through integrity and attestation | |
| Is this installation known for this account? | Yes, through the installation record | |
| Is this a clone or parallel instance? | Yes on Android | |
| Is this the account holder? | Authentication factors | |
| Is the user being guided by someone else? | Remote access and social engineering signals |
Verification on your server
Challenge and freshness
Your server issues a challenge for each sensitive request. The installation signs it with its key and returns the signature alongside the integrity result. Because every challenge is used once, a proof captured in transit or copied from logs has no value later. Your server checks the signature, the challenge and the installation record together.
Who decides
Otukan produces the evidence inside the app. Your backend owns the verdict: it can accept the request, ask for a step-up or refuse it. Keeping the decision there means an attacker who controls the device still has to convince a server they cannot touch. On iOS, your server can combine this with App Attest; on Android, with the Play Integrity verdict it requests and checks. Attestation detail is on mobile app attestation.
How to test it
Reproduce each case in an authorised lab. Run the Android app in a cloning container and confirm the parallel instance is reported. Replay a captured proof and confirm the server refuses it. Register an installation from an emulator and confirm the step-up. Then repeat install, update, sign-in and your most sensitive flow on a normal phone and confirm nothing fires. Record the device, OS version, expected result and reviewer for each run, so the next release can be compared against the same baseline.
Privacy and the installation lifecycle
Reinstall and reset
On Android, uninstalling the app or resetting the phone removes its keys from the Android Keystore. On iOS, keychain items can outlive an uninstall, so Otukan ties the identity to the installation itself rather than to whatever the keychain kept. On both platforms the next launch creates a new key, and your server sees a new installation for an existing account. Good policy treats this as normal but unproven: allow everyday use, ask for a step-up before the new installation approves payments or changes account details.
Several devices per account
Many customers use a phone and a tablet, or keep an old phone as a spare. The installation record lets your policy set how many active installations an account may hold and what each one may do. A second trusted device is ordinary; a fifth installation in a week is a pattern worth a closer look.
Key rotation and retirement
Installation keys should not live for ever. Otukan supports rotating the key on a schedule you set and retiring the record at sign-out, account closure or device change. A retired installation can no longer sign requests, even if an old copy of the app survives somewhere.
Data minimisation
The installation record holds a pseudonymous identifier, a public key and integrity results. It does not hold hardware serials, advertising identifiers or contact data. You choose the retention period and who in your organisation can read the history.
For the wider view of account security, return to identity and account protection.