A mobile security team should evaluate biometric flow protection by following one sensitive action, such as a sign-in, a payment approval or a new device enrolment, from the biometric prompt to the server’s decision. Check three things: where the trust boundary sits, which duties belong to the app, the operating system and the backend, and whether each claim holds on signed Android and iOS builds on real devices. The operating system performs the face or fingerprint match. Protection concerns what happens to the result afterwards. This guide gives the questions for each step and shows how Otukan answers them.
The product view is covered on biometric flow protection. Further evaluation aids are on solution guides.
Name the flow and its trust boundary
Start with one flow at a time. A banking approval and a login unlock carry different risks, so they deserve different answers.
The flow under test
- Which actions use a biometric check: sign-in, transaction approval, adding a payee, changing the registered device, revealing card details?
- Does the biometric check replace a password or add to one?
- What reaches the server after a successful check: a flag, a session token or a signature over a server challenge?
- What is the fallback when biometrics fail or are unavailable: device passcode, app PIN or a support call?
- What happens after someone enrols a new fingerprint or face on the device?
Where attacks land
Matching runs inside the operating system and dedicated hardware, out of the app’s reach. The attacker’s easier target is the app code that receives the answer and the request that carries it onward.
| Boundary | What crosses it | What can go wrong |
|---|---|---|
| OS prompt to app | A success or failure result | A hooked callback reports success with no match |
| App to its own code | The decision to proceed | A repackaged copy skips the check entirely |
| Screen to user | What the user thinks they approve | On Android, an overlay hides the real action |
| App to server | The approval request | A stored token is replayed from a compromised device |
Split duties between OS, app and backend
Each layer has a job. The evaluation should confirm that no layer assumes another is doing its work.
Operating system
On Android, BiometricPrompt used with a CryptoObject unlocks a Keystore key created to require user authentication, and among biometric sensors only Class 3 (strong) ones can unlock it. A key can also be set to become invalid when new biometrics are enrolled. On iOS, LocalAuthentication on its own returns a yes or no to the app. A Keychain item or Secure Enclave key protected by an access control such as biometryCurrentSet ties use of the secret to the biometrics enrolled at creation.
App
- Does the app use the key-bound path on both platforms, or only a success callback?
- Does the prompt tell the user exactly what they are approving, including amount and recipient?
- Is the approval code protected against modification and runtime interference?
Backend
- Does the server issue a fresh challenge per approval and verify the signature with the registered public key?
- Is the signed data bound to the transaction details, so an approval cannot be reused for another action?
- Does the server weigh a runtime signal about the device and app before accepting?
How Otukan answers. Otukan ties each approval to a key in the Android Keystore or the iOS Keychain that the platform unlocks only after a successful match, and your server verifies a signature over a one-time challenge that carries the transaction details, so an approval cannot be reused for another payee or amount. Keys can be set to stop working when new biometrics are enrolled, with a step-up you define to re-establish trust. Immediately before the prompt, Otukan checks for hooking and instrumentation, injected libraries, attached debuggers, repackaged copies, rooted Android devices and jailbroken iOS devices. It flags screen sharing during the approval and, on Android, overlays and remote-access tools. The result travels with the approval, so your server can refuse one that came from a compromised session. Otukan does not access or store biometric data: the match stays with the OS and the decision stays with your server.
Evaluate each platform with evidence and user impact
Ask for every answer twice, once for Android and once for iOS. The APIs, the hardware and the attacks differ.
Platform scope
- Which Android versions and which iOS versions does each protective check cover?
- How does the solution behave on devices without strong biometrics or with none enrolled?
- Which frameworks are in scope, such as Flutter or React Native plugins that wrap the native prompt?
Evidence to request
| Test | Android | iOS | Result you expect |
|---|---|---|---|
| Hook the biometric result in an authorised lab | Signed release build | Signed release build | Detection fires; server refuses the approval |
| Run a repackaged copy | Re-signed APK | Re-signed IPA | Integrity check fires before the flow |
| Show an overlay during the prompt | Test overlay app | Not applicable | Overlay flagged; approval paused |
| Approve on an unmodified device | Physical device | Physical device | Flow completes with no extra friction |
User impact
- Can a legitimate user whose device is flagged still complete the action through another verified path?
- Does the flow stay accessible to users who rely on the device passcode instead of biometrics?
- Who reviews a false positive, and how quickly does the user hear back?
How Otukan answers. Every Otukan check carries its own Android scope and its own iOS scope, shared with you before a protected build ships. Our engineers reproduce each detection with yours in an authorised lab on signed builds, including the unmodified-device case, so friction for genuine users is measured rather than assumed. Otukan fits your existing build and release pipeline, and your signing keys stay with your team.
For the account-level view of the same risk, see account takeover prevention.