A mobile security team should evaluate runtime threat signals as a data contract and an operating process, not as a list of detections. Ask what each signal says happened, which fields and timestamps it carries and how severity is assigned. Map how signals reach triage, policy and escalation in your organisation. Then check how detections are kept apart from confirmed incidents, protected and retained. A signal reports what the app observed on one device at one moment; it supports a decision your backend makes. The questions below cover Android and iOS apps sending signals to servers you operate.
What Otukan signals carry is covered on runtime threat signals. How they feed monitoring is covered on mobile app threat monitoring.
Define the signal contract
Before comparing suppliers, write the contract you need. Then ask each option to fill it.
What was observed
- Which conditions produce a signal: hooking, debugging, emulation, root on Android, jailbreak on iOS, modified or repackaged app?
- Does the signal name the specific check that fired, or only a category?
- Does it say what the app did in response?
Fields to require
| Field | Why it matters | Question to ask |
|---|---|---|
| Signal type and check | Tells analysts the mechanism | Is the check named, not just grouped? |
| Platform, OS version, app build | Separates Android from iOS and one release from the next | Is the build traceable to a commit? |
| Device time and server receipt time | Device clocks can be wrong or altered | Are both recorded? |
| User flow | Links the signal to login, payment or enrolment | Is the flow named by your app? |
| Response applied | Shows observe, warn, restrict or terminate | Is the applied response logged? |
| Request reference | Joins the signal to the server-side request | Can you match it without personal data? |
How Otukan answers. Every Otukan signal records the check and its result, the journey moment (launch, sign-in or a sensitive action you mark), the app build, the platform and OS version, a pseudonymous install identifier, a severity level and a timestamp. Root is reported only for Android and jailbreak only for iOS, each from its own platform checks, and a signal is never relabelled across platforms. Every check maps to a small, documented severity scale, and your policy decides what each severity triggers in each flow.
Severity
- Is severity on a small, documented scale, and can you change what each level triggers without a new app release?
- Does severity depend on the flow, so the same finding weighs more during a payment than on a news screen?
Run operations on the signals
Signals earn their keep when someone acts on them. Map the path from arrival to decision.
Collection
- Do signals arrive with the request they concern, separately, or both?
- What happens when the device is offline or your endpoint is unreachable?
- Can you replay recorded signals into a test endpoint before going live?
Triage and escalation
| Signal pattern | First action | Escalation |
|---|---|---|
| Single low-severity finding | Record and watch | None unless repeated |
| Instrumentation during a payment | Refuse or step up the request | Fraud or security analyst |
| Repackaged copy seen on many devices | Block the build at your API | Store takedown request |
| Spike after a release | Check for false positives | Mobile engineering |
Policy changes
- Who may change the response for a flow, and how is the change recorded?
- Does your security monitoring platform or fraud engine receive the same signals, and in which format?
How Otukan answers. Otukan sends runtime threat signals to your own backend alongside login and transaction requests, so your server can decide on the request in front of it. Each signal records the response the app applied, so analysts see both what happened and what the user experienced. Before rollout, our engineers run positive, negative and regression tests for each signal with yours against a test endpoint.
Handle the data with care
A detection is not a finding until someone confirms it. Your data design should keep that line visible.
Detection versus confirmed incident
- Are raw signals stored apart from incidents your analysts have confirmed?
- Can an analyst mark a signal as false positive, and does that feed policy review?
Minimise and protect
- Which fields could identify a person, and are any unnecessary for your decision?
- Which data protection law applies to you, such as KVKK in Türkiye or the GDPR in the EU, and has your privacy team reviewed the signal content?
- Who can read raw signals, and is access logged?
Retention
- How long do you keep raw signals, and how long do you keep confirmed incidents?
- Who deletes data at the end of the period, and how is deletion evidenced?
How Otukan answers. Otukan labels each record as a detection, a confirmed attack or a business incident, and a detection is promoted only as evidence agrees, so a raw signal is not mistaken for proven fraud. Signals carry no names, phone numbers, email addresses, message content, contacts, precise location or file contents; the install identifier is pseudonymous. We document the full signal content and data flow with your security and privacy teams during the technical review, and retention and access to account linkage are agreed with you before collection starts.
For the questions that apply to every control, see the mobile app security evaluation checklist.