Evaluate runtime threat signals by what each one lets you decide. An Otukan-protected app creates a structured signal every time a runtime check fires: which check, what it found, the moment in the journey, the app build, platform, OS version, a pseudonymous install identifier, a severity level and a timestamp. A strong signal is precise enough to drive a response rule, consistent enough to count over time and lean enough to pass a privacy review. This page covers the signal itself for Android, iOS, Flutter and React Native apps. Trend views, case handling and SIEM delivery each have their own page.
The signal contract
A runtime signal is a contract between the app, your backend and your analysts. If one of them reads a field differently, triage slows down. Otukan fixes the structure so that every check, on every build, produces the same shape of record.
What each record holds
| Field | What it holds | Why your team needs it |
|---|---|---|
| Check | The runtime check that fired, such as instrumentation or signing identity | Tells an analyst what was observed without reading code |
| Result | What the check found | Separates a clear finding from a partial one |
| Moment | Launch, sign-in or a sensitive action you marked | Shows whether the condition was present before money or data moved |
| Build | The app version and build that produced the record | Ties the signal to a release you can reason about |
| Platform and OS version | Android or iOS, and the system version | Keeps comparisons within one platform |
| Install identifier | A pseudonymous value for the app instance | Links repeated signals without naming the person |
| Severity | A level from a small, documented scale | Lets the policy and the SOC rank signals the same way |
| Timestamp | When the check ran | Orders signals against backend and fraud logs |
Android and iOS stay separate
Each platform exposes different information to an app, so Otukan builds its checks per platform and names them accordingly. An Android root finding is reported as root; an iOS jailbreak finding is reported as jailbreak. A record is never relabelled to make the two look alike, which keeps your counts honest.
From signal to operations
A record only earns its place if someone acts on it. Otukan designs signals around three uses: triage by an analyst, input to the app’s response rule, and escalation when a pattern looks like a real attack.
| Situation | Triage question | Response input | Escalation |
|---|---|---|---|
| One debugger record on an internal test device | Is this our own lab? | Keep observe on internal builds | None |
| Instrumentation at sign-in across many new installs | Is a toolkit being used against login? | Restrict sign-in for affected installs | Security team reviews the pattern |
| Signing identity mismatch on a payment | Is a modified copy in circulation? | Keep the copy away from payments | Security and fraud teams open a case |
| Root records rising on one Android version | New system image or new tooling? | Hold the current rule while you check | Only if backend evidence agrees |
Triage
Severity and the journey moment let an analyst sort a queue quickly. A high-severity record before a transfer outranks a low-severity record at launch on a browsing screen.
Policy input
Records show how often a check fires on your real users. That rate is what tells you whether a flow can move from observe to warn, restrict or terminate. Policy design is covered on threat response.
Escalation
A single record is a lead. When several records and backend evidence point the same way, the detection is promoted to a confirmed attack and the owning team takes the case. Case handling is covered on threat investigation workflows.
Data handling
Detection comes before confirmation
Otukan labels every record as a detection first. It becomes a confirmed attack when signals and backend evidence agree, and a business incident when users, money or data are affected. That order keeps one noisy device from starting an incident response.
What stays out of a record
Runtime signals describe the app and the check, not the person. Names, phone numbers, email addresses, message content, contacts, precise location and file contents are never part of a record.
Retention and access
How long records are kept, and who may link an install identifier to an account, is agreed with you before collection starts. Data flows are documented for your privacy reviewers. Data handling is covered on data privacy.
Proving it on your app
Before a rollout, Otukan and your engineers prove each signal three ways: reproduce the behaviour in an authorised lab and confirm the record, repeat the journey on a legitimate device and confirm silence, then run install, update, sign-in and your most sensitive flow again. Results are recorded with devices, OS versions and the reviewer.
For an evaluation checklist, see the runtime threat signals solution guide. Backend handling of these records is covered on handling runtime threat signals. For the wider picture, return to mobile app threat monitoring.