Evaluate threat investigation workflows by how quickly and how fairly they turn one mobile signal into a defensible conclusion. Otukan links runtime signals from your protected Android, iOS, Flutter and React Native apps to the session, pseudonymous account and release around them, lays them out as a timeline and lets analysts add the backend evidence that confirms or dismisses an attack. Cases close with a clear label (detection only, confirmed attack or business incident), and account linkage stays with the analysts who need it. The app contributes device evidence; the verdict draws on your server records too.
The case and the boundary
Flows that produce cases
Most mobile investigations start at the same few flows: a transfer the customer disputes, a sign-in from a new phone followed by a change of contact details, a spike of new accounts that behave alike, or reports of a modified copy of your app. Each flow crosses a trust boundary between a device you do not control and a backend you do.
What each side can prove
The app sees the device at the moment of the action: instrumentation, remote control, overlays on Android, capture, integrity and environment. The backend sees the account: credentials used, payees added, amounts, IP ranges and timing. Neither side alone settles a case. Otukan is designed so an analyst reads both together.
Where the case starts
Leads arrive from three directions: an alert in your SOC, a trend in analytics, or a customer complaint to support. Otukan lets an analyst open a case from an install, an account or a build, whichever the lead points to. Trend-driven leads are described on threat analytics.
Who contributes what
| Party | Contribution to the case | Limits to respect |
|---|---|---|
| Protected app | Runtime signals with journey moment, build, platform and applied response | Observes only what each platform allows an app to see |
| Operating system | Platform evidence, such as attestation your server verifies | Varies between Android and iOS and between OS versions |
| Your backend | Login, transaction and account-change records | Needs a pseudonymous key to join with app signals |
| Otukan | Links, timelines, release lineage and case labels | Account linkage limited to named analysts |
| Your analysts | Judgement and the final label | Follow the escalation path agreed with fraud and engineering |
Android evidence
Android cases can include overlays drawn over your screens, accessibility services performing gestures, root traces and proxy settings. These are often decisive in remote-control fraud.
iOS evidence
iOS cases rely on screen capture and mirroring, jailbreak traces, the app’s own integrity and attestation that your server verifies with App Attest. Signals are fewer by design of the platform, so backend records carry more weight.
Evaluating the workflow
Platform scope
Ask for the signals available to investigators on Android and on iOS as separate lists, with OS versions. Otukan supplies them per platform.
Evidence quality
Test with cases you control. Reproduce an attack on a test account in an authorised lab and check that the timeline shows it clearly. Repeat the same journey on a clean device and check that the case would close as a false positive. Record devices, OS versions, results and the reviewer.
User impact
Investigations affect real customers when they end in a restriction. Check that support can see why an account was restricted, that the customer has a way forward, and that confirmed false positives turn into exceptions in the next policy version. Policy changes are covered on threat response.
Handover
A good workflow ends with a clear package for the next team: fraud gets the timeline around the transaction, engineering gets the build and check involved, and the SOC gets the label for its records.
Recording the outcome
Every closed case teaches the next one. Record the label, the evidence that decided it and any change it triggered, such as a new policy version, a raised minimum build or an allowed assistive tool. Over time, these outcomes show which checks most often lead to confirmed attacks, which is exactly what your analytics and response rules need. Alert delivery is described on SIEM integration.
For the wider picture, return to mobile app threat monitoring.