Evaluate security policy management by following one sensitive user flow from end to end. Name the flow and the trust boundary its request crosses, then check three things. Can a rule be set for that flow alone? Is it clear which part the app, the operating system and your backend each play? And can a rule change be tested on real users, versioned and rolled back without guesswork? Otukan’s policy management answers yes to each, for Android and iOS apps including Flutter and React Native, with rules written per platform. Policy decides the response; it does not replace a server that verifies what it receives.
Flows and trust boundaries
A policy is only as good as its map of where risk sits. Start with the flows where a wrong decision costs most, and write down the boundary each request crosses.
| User flow | Trust boundary | What an attacker wants | Typical starting rule |
|---|---|---|---|
| First launch and onboarding | App to identity service | Mass account creation from scripted devices | Observe emulator and integrity signals, report to the server |
| Sign-in | App to authentication backend | Session theft or credential replay | Warn on modified devices, step up on hooking |
| Payment or transfer | App to transaction API | Altered amounts or payees | Restrict on hooking or debugging, server re-verifies |
| Account changes | App to profile service | Takeover by changing email, phone or device | Restrict until the server confirms the device |
| Content browsing | App to content service | Little of value | Observe only |
The table is a starting point. Your own flows and the value they carry set the final rules.
Responsibilities
Good policy is explicit about which layer does which job. Each layer sees something the others cannot.
The app
The app runs Otukan’s checks and applies the local response set for the flow. It is the only layer that can see hooking, debugging or tampering from the inside, and it can act before sensitive code runs. It also runs on a device the attacker may control, so its findings are sent on rather than trusted alone.
The operating system
Android and iOS each offer platform evidence your server can verify. On Android, a Play Integrity verdict speaks to the app and device. On iOS, App Attest lets your server check that requests come from a genuine instance of your app. Your policy should say where that evidence is required, and Otukan’s rules are written separately for each platform because the evidence differs.
Your backend
The backend makes the final decision on sensitive requests. It receives Otukan’s signals, including the policy version that produced each response, combines them with platform evidence and its own account history, and accepts, steps up or refuses. For signal handling on the server, see handling runtime threat signals.
Evaluation
Supported platforms
Ask for platform scope per control, not per product. A rule that relies on a control available on Android only must not be assumed on iOS. Otukan shows each platform’s rule set on its own, so a reviewer sees exactly what runs on Android and what runs on iOS.
Evidence
Every rule should be backed by a test. With your team, Otukan reproduces the targeted behaviour in an authorised lab and records the signal, runs the same journey on clean devices and confirms no response, and repeats install, update, sign-in and the protected flow. Results are kept with devices, OS versions and the reviewer.
Rollback of a rule
Ask how quickly a team can undo a rule that misfires. With Otukan, each policy version is kept, so returning to the previous one is a known step rather than an emergency edit. Where a response can be adjusted from your server, the correction reaches users without waiting for a store review.
User impact
Measure before you enforce. Observe mode shows how often each check fires across your real users. Test engineers, people who rely on assistive tools and users who customise their phones all look unusual to a check, and a rule that ignores them costs support time. Tighten one flow at a time and watch the effect. For designing responses in depth, see threat response.
Return to mobile app security for how policy fits the wider product. If your app is already published, you can request a free App Exposure Check of the public store release.