An installation can be linked to a device without locking out legitimate users when the link is a key, not an identifier, and when every way of losing that key has a planned path back. Otukan creates a binding key inside the platform’s protected key store when a customer first signs in, signs sensitive requests with it over a fresh challenge from your server, and lets your backend verify each signature. Reinstall, device replacement, account recovery and key rotation each follow a defined route. Binding proves continuity of an installation on Android and iOS; it does not replace user authentication.
For how binding fits the wider request evidence, see mobile API protection.
Binding semantics
Three identifiers are often mixed up in binding designs. Each answers a different question and changes at a different moment.
| Identifier | What it tells you | When it changes | How Otukan uses it |
|---|---|---|---|
| Installation | This copy of your app, as enrolled | Reinstall, clearing app data, restore to a new phone | The binding key belongs to the installation and is created at enrolment |
| Device | The hardware the installation runs on | New phone, repair that replaces secure hardware | The key lives in the device’s protected store and is non-exportable where the device supports it, so it does not travel to another phone |
| Account | The customer, as your service knows them | Almost never | Your backend links one account to its active bindings and decides how many it allows |
A request signed by the binding key tells your server that the same installation on the same device is still talking to it. It does not tell you who is holding the phone; that remains the job of your sign-in and step-up checks. Otukan also pairs binding with app attestation, because a key proves continuity, not that the enrolling client was your genuine release.
Freshness on the server
Each signature covers a challenge your server issued moments earlier, plus the request content that matters. Your backend checks the signature, the challenge and its age before business logic runs. A captured signature fails the freshness check if it is sent again.
Lifecycle
Binding designs fail on the ordinary events of a customer’s life. Otukan defines each path before the first release.
- Reinstall. On Android, keys in Android Keystore are removed with the app, so a reinstall means a fresh enrolment. On iOS, Keychain items can outlast an app deletion; Otukan does not treat a surviving item as proof of the same installation and asks for re-enrolment on the terms you set.
- Device replacement. The key cannot travel, by design. The customer signs in on the new phone, and your chosen path decides whether approval from the old device, a stronger identity check or both are needed.
- Recovery. A lost or broken phone leaves no device to approve from. Recovery runs through your strongest identity step, and the old binding is revoked on your server.
- Key rotation. Bindings can be renewed on a schedule you choose or after a risk event, without the customer noticing more than a normal sign-in.
Otukan works with your team to test every path before release: enrol and verify on a supported device, attempt the same request from a cloned installation and confirm it fails, then repeat install, update, sign-in and your most sensitive flow, recording OS versions, devices, expected results and the reviewer.
Sector needs are covered on fintech app security and telecom mobile app security.
Privacy
Binding can be built as a quiet tracking system, and Otukan deliberately does not build it that way.
- App-scoped keys. The binding key belongs to your app and means nothing to any other app or service.
- No permanent identifiers. Otukan does not rely on hardware serial numbers or other values that survive a factory reset or follow a person between apps.
- Replaceable by design. A customer who rebinds gets a new key; the old one is retired, not kept as a history of their devices.
- Pseudonymous references. Your backend and your logs see a binding reference, not a device fingerprint.
Both Android and iOS restrict access to persistent hardware identifiers for exactly this reason. Otukan’s approach proves what your security team needs to know, that this request comes from the enrolled installation, and stops there.