When a threat signal appears, your app should react in proportion to what is at stake in that flow. Otukan gives you four responses (observe, warn, restrict and terminate) and lets you set them per check and per user flow, so a rooted phone can keep browsing while a tampered copy is kept away from payments. The signal also goes to your backend, which makes the final call where an attacker cannot interfere. This page covers policy design, how legitimate users are treated and how policies are governed, for Android, iOS, Flutter and React Native apps. Detection itself is described on each control’s page.
Designing the policy
A response policy answers one question per check and per flow: what should the app do now? Otukan offers four answers, and most apps need all four.
| Response | What the user experiences | Risk it addresses | Where it fits |
|---|---|---|---|
| Observe | Nothing changes; the signal is recorded and sent | Unknown rates, new checks | New rules, low-risk screens, measuring before enforcing |
| Warn | A short explanation, then the flow continues | Conditions some real users create | Developer settings, screen recording on non-critical screens |
| Restrict | One function is held or needs a stronger factor | Clear risk to a specific action | Sign-in, payee changes, stored card screens |
| Terminate | The session ends | Strong evidence of an attack on a critical step | Tampered builds on payments or account recovery |
Match the response to the flow
Start from the flows, not the checks. List what moves money, exposes personal data or changes who controls an account. Those flows get restrict or terminate for the checks that matter to them. Everything else can observe or warn.
Let the server decide where it can
A restriction is often better expressed on your backend than in the app. When the app passes the signal with the request, your server can ask for a stronger factor, hold a transfer for review or let it through with a note. The app does not reveal to the attacker which rule applied.
Separate rules for Android and iOS
The two platforms expose different conditions, so the checks feeding a rule differ too. Otukan builds each check for its own platform, and a rule written for Android root does not quietly carry over to iOS; the iOS flow gets its own jailbreak rule. Write and test each platform’s rules on their own, even when the intended behaviour matches.
Protecting legitimate users
Every detection has innocent causes. Developers use debuggers, testers use emulators, and some customers run custom system images or assistive tools. A good policy plans for them.
A fallback for every restriction
When a flow is restricted, the user should know what to do next: try another device, use a different channel or contact support. Otukan lets the app show your own message at that point, so nobody is left at a dead end.
Support that can see the reason
Your support team needs to know which signal caused a restriction without seeing personal data. The pseudonymous install identifier and the check name are enough to explain the situation and log a possible false positive.
False-positive review
Review restricted and terminated sessions on a regular schedule. Where a legitimate pattern keeps appearing, such as one assistive tool or one corporate network, allow it explicitly in the next version rather than weakening the whole rule.
Governing policy change
Versions
Each response policy is a version with an owner, a date and a reason. That record answers the question every incident review eventually asks: what was the app told to do on that day, and who decided? How those versions are planned and tested on real users first is covered on security policy management.
Rollback
A new version can affect more real users than expected. Otukan keeps the previous version ready, so you can return to it while you investigate, and the rollback itself is recorded.
Accountable ownership
Name one owner for the policy, usually in application security. Product decides where friction is acceptable, fraud says which flows attackers target, and support reports what customers experience. The owner signs off every version.
Testing before enforcement
Before a version is enforced, Otukan and your engineers reproduce each targeted condition in an authorised lab and confirm the app responds as written. The same journey then runs on a clean device to confirm nothing happens, followed by install, update, sign-in and the protected flow. The results are attached to the version they tested.
The runtime checks behind these responses are described on mobile RASP, and Android device checks are on Android root detection. How monitoring informs policy is covered on mobile app threat monitoring. The product overview is on mobile app security.