A mobile security team should evaluate biometric flow protection by asking what your server actually receives when a customer approves an action with face or fingerprint, and whether that evidence would survive a tampered app. Otukan makes the approval provable. A real match unlocks a key held by the platform, the key signs a one-time challenge carrying the transaction details, and hooking, overlay and remote-control checks run around the prompt and travel with the signature. The operating system still performs the match, and Otukan never touches biometric data. Android and iOS are implemented separately, each on its own platform’s key storage.
The step-by-step evaluation checklist is on the biometric flow protection solution guide.
The flow and its trust boundary
Which actions depend on it
Biometric checks now sit in front of sign-in, payment approval, payee changes, card detail reveals and new device registration. Each is a different risk. A quick unlock on a balance screen needs less than a transfer to a new recipient, and your protection should reflect that.
Where trust changes hands
The match itself happens in hardware the app cannot reach. Trust changes hands at two points: when the platform tells the app the result, and when the app tells your server. Attackers go for those two points, not for the sensor.
What the customer is agreeing to
A biometric approval only means something if the customer knew what they approved. On Android, the app sets the title and description of the system prompt, so the amount and recipient can appear on it. On iOS, the Face ID sheet shows no transaction text, so the details belong on the app screen directly behind it. Otukan’s challenge carries the same details to your server, which lets the backend confirm that the action it executes is the action the customer saw.
| Handover | Weak design | Otukan design |
|---|---|---|
| Platform to app | App reads a true or false in a callback | Match unlocks a key; no key, no signature |
| App to user | Prompt shown over whatever is on screen | Overlay and screen-sharing checks before the prompt |
| App to server | App sends “approved” | App sends a signature over the server’s challenge plus integrity signals |
Who does what
The operating system
Performs the match, holds the key in the Android Keystore on Android or in the Secure Enclave on iOS, and releases it only after a successful check. On both platforms, a key can be created so that it stops working when the device’s enrolled biometrics change. Android also grades biometric sensors by strength: a key that requires user authentication can be unlocked by a Class 3 (strong) biometric or the device credential, never by a weaker sensor.
The app with Otukan
Creates the key at registration, requests a challenge before each approval, checks the app, the device and the screen, then asks the platform to sign. If a check fails, the response you set for that flow applies before the prompt appears. Platform specifics are on the Android biometric guide and the iOS biometric guide.
Your backend
Holds the public key for each registered installation, issues challenges and checks each returned signature against the right key, challenge and transaction. It combines the result with Otukan’s signals and decides: approve, step up or decline.
Evaluating it in practice
Platforms and scope
Ask for separate Android and iOS answers for every behaviour: how the key is created, what happens on re-enrolment, which screen checks apply. Remote-access tool detection and overlay checks are Android signals. Screen sharing is checked on both.
Evidence
In an authorised lab, hook the biometric callback and confirm your server rejects the approval. Show an overlay over the Android prompt and confirm the pause. Add a new fingerprint and confirm the old key no longer signs. Reuse a signature for a different amount and confirm the refusal.
User impact
Run the same approvals on ordinary phones and confirm they pass without extra prompts. Measure how often the fallback route is used, and test it with assistive technologies switched on. A protection that pushes customers towards weaker routes has moved the risk, not removed it. Keep a dated log of each run with the phone model, OS version, outcome and the engineer who checked it, and repeat the set after each release that touches sign-in or payments.
For the wider account security picture, return to identity and account protection.