Evaluate threat operations by following one finding from a user’s device to a decision: does it arrive with enough context, does it reach the right owner, and can the response change as fast as the attack does? Otukan is built for that loop in Android and iOS apps, native or built with Flutter or React Native. Runtime findings travel to your backend with the request they concern, your team tunes responses per flow from the server where your design allows it, and Otukan’s engineers review trends with you. This page covers the flows and boundaries involved, who does what, and how to test the loop before you rely on it.
For the controls that produce these signals, see mobile app threat monitoring.
The flows and the trust boundary
Threat operations start where a finding leaves the device. Up to that point the app observes; beyond it, your backend and your analysts decide. Three kinds of flow need the most attention.
- Account flows. Sign-in, device registration and account recovery, where a hooked or emulated session can signal takeover or automated abuse.
- Money flows. Payments, transfers and payout changes, where screen-reading services or an altered app copy change the risk of the transaction itself.
- Content and entitlement flows. Paid features and licence checks, where tampering aims to unlock what should be paid for.
Every finding crosses the same boundary: from the app, which can be attacked, to your servers, which run under your control rather than the attacker’s. That is why Otukan sends findings with the requests they concern. Your backend sees the signal at the moment it decides, instead of reconciling two streams later.
App, operating system and backend roles
| Role | App (with Otukan) | Operating system | Your backend and analysts |
|---|---|---|---|
| Observe | Detects hooking, debugging, emulation, root or jailbreak and altered app copies | Provides sandboxing and, where available, attestation | Receives findings with context |
| Decide | Applies the response set for the flow | Not involved | Sets the response per flow and changes it when needed |
| Correlate | Attaches flow, version and session reference | Not involved | Joins findings with fraud, account and network data |
| Improve | Runs the next approved profile | Delivers the new release through the store | Reviews trends with Otukan’s engineers |
The operating system does not make business decisions. It enforces its own rules and, through Play Integrity on Android or App Attest on iOS, can vouch for the device or the app. Everything that depends on your risk appetite belongs to your backend and your team.
Responses per flow
Otukan lets each flow carry its own response: observe, warn, restrict or end the session. A rooted device might only be observed on a news screen and restricted on a transfer. Where your integration reads the response from your server, your analysts can change it during an incident without a store review.
Evaluating threat operations
Prove the signals arrive
In an authorised lab, reproduce each behaviour you care about, such as a hooking framework attached to your app or the app running on an emulator, and confirm the finding reaches your backend with the expected type, flow and versions. Repeat the same journey on a normal device as a negative control and confirm nothing is raised.
Prove the loop closes
Change a response from the server and confirm the app applies it on the next request. Check that the change is recorded with who made it and when. Then confirm the finding reaches the analyst queue that owns the flow.
Rehearse an incident
Run a tabletop exercise before the first real event. Pick one flow, simulate a burst of findings from the lab, and walk through who is paged, who may change the response, how the change is recorded and when it is relaxed again. The rehearsal shows gaps in routing and authority while the stakes are low.
Check user impact
Run the baseline period with real users before any response goes beyond observing. Look for findings on configurations that are unusual but legitimate, and settle how they are handled before you restrict anything. Platform scope is stated per control; see supported environments.
For the controls and platforms behind these operations, return to mobile app security.