App, identity and fraud teams stop account takeover best when they plan together around the customer journey rather than around their own tools. Map every step where an account can change hands, from login through recovery to payments, then give each step one owner and one decision point. The app contributes evidence about the device and session, identity decides who the customer is, and the fraud engine weighs the history. Otukan supplies the app evidence; this guide runs the workshop. It covers mobile apps on Android and iOS; call-centre and web channels need their own map, which you should link to this one.
The takeover chain itself is covered on mobile account takeover prevention.
Journey workshop
Bring one person each from mobile engineering, identity, fraud operations and customer support. Draw the journeys on one canvas and mark every step where an attacker could act as the customer.
Login
- Which sign-in methods does the app offer: password, one-time code, biometric unlock, passkey or a mix?
- Where does a new device first become trusted, and what proof does the customer give at that moment?
- Which requests would an attacker replay from a script instead of the genuine app?
- What does the app know at login that your server cannot see: device state, app integrity, screen activity?
Recovery
- How does a customer reset a password, replace a lost phone or move to a new number?
- Which recovery steps rely on a code sent by SMS, email or push, and where is that code typed?
- Can recovery and a high-value action happen in the same session without any pause?
- Who in support can override recovery checks, and how is that recorded?
Transactions and profile changes
- Which actions move money or value: transfers, new payees, limit changes, card controls, loyalty redemptions?
- Which profile changes make a later takeover easier: email, phone number, linked devices?
- Which of these actions are reachable within minutes of a fresh login?
Mark each step red, amber or green for exposure. The red steps drive the rest of this guide.
Control allocation
Each red step needs a decision owner and the evidence that owner requires. Write the allocation down; takeover often slips through where two teams assumed the other was checking.
| Journey step | App evidence | Backend and API | Identity service | Fraud engine |
|---|---|---|---|---|
| First login on a new device | App integrity, device state, attestation | Accept only attested calls | Step up before trust is granted | Score device novelty against history |
| Password or phone recovery | Screen capture, overlay and remote control signals | Throttle recovery attempts | Choose the proof required | Hold high-risk recoveries for review |
| New payee or limit change | Session binding and runtime integrity | Refuse unbound tokens | Re-authenticate the customer | Weigh payee and amount patterns |
| Session reuse after login | Device binding result | Reject replayed tokens | Shorten or revoke the session | Flag reuse across devices |
What Otukan contributes
Otukan is the app-side column. It checks whether the app is genuine and unmodified, whether the device is rooted or jailbroken, and whether something other than the customer is driving the screen. It attaches that evidence to the requests that matter and applies an on-device response per flow. Your identity service and fraud engine keep their decisions; Otukan gives them evidence they cannot collect from the server alone.
Platform notes
Android and iOS expose different things. Overlay and accessibility signals are Android signals: iOS does not let third-party apps draw over other apps or act as accessibility services, so iOS evidence centres on screen capture and mirroring state. Attestation on each platform asserts different facts, so record the scope per platform rather than one line for “mobile”.
- For each app signal in the table, is the Android scope and the iOS scope written separately?
- Which team receives each signal, and in which system?
- Which team can change the response for a flow, and who approves it?
Validation
A plan is only as good as its test. Validate each red step against an attack scenario and against a genuine customer who looks unusual.
Attack scenarios
- Stolen credentials used from a script that imitates the app’s login calls.
- Phished credentials used on a new phone, followed by a payee change.
- A recovery code read from the screen or notifications by a malicious app, on Android.
- A customer coached by a caller into installing screen-sharing or remote control software.
- A session token copied from a rooted or jailbroken device and replayed elsewhere.
Reproduce each scenario in an authorised lab on test accounts, never on production customers. Record the expected signal, the team that should act and what actually happened.
Legitimate-customer acceptance
- A customer replaces a lost phone and signs in from a new device.
- A customer travels and signs in from another country and network.
- A customer uses a screen reader or other assistive service to bank.
- A family shares one tablet between two accounts.
Each of these must reach its goal, with at most a step-up, and support must be able to explain what happened.
How Otukan helps you validate
Otukan reproduces the attack scenarios with your team in your lab and runs the same journeys on legitimate devices to confirm the signals stay quiet. Enforcement starts in observe mode, so you see how often each signal fires on real customers before any response is switched on. Results are recorded per platform, with devices, versions and the reviewer.
For product scope, see mobile app security. Sector requirements are covered on mobile banking app security, and the wider fraud programme is covered on mobile fraud prevention.