Mobile threat data reaches your security operations workflow when it arrives in the SIEM your analysts already watch, in a shape they can correlate. Otukan delivers normalised signals from your protected Android, iOS, Flutter and React Native apps with a stable field set, a severity mapping agreed with your SOC, deduplication of repeated device noise and pseudonymous keys for joining mobile alerts with login, API and fraud logs. You choose what is forwarded: high-severity signals individually and lower levels as summaries. Personal data stays out by design. The delivery option is agreed with your team against the platform you run.
The event contract
A SIEM rewards consistency. If field names shift between app versions, parsing breaks and dashboards go quiet. Otukan treats the fields it sends as a contract agreed with your SOC before the first alert.
Fields your analysts can rely on
| Field | Purpose in the SOC |
|---|---|
| Check and platform | Tells the analyst what was observed and on which operating system |
| Severity | Ranks the alert on your SOC’s own scale |
| Detection label | Separates a lead from a confirmed attack or a business incident |
| Build | Links the alert to a specific app release |
| Pseudonymous install key | Groups alerts from one app instance |
| Pseudonymous account key | Joins the alert with identity and login logs, where you allow it |
| Count and window | Shows how many times the signal repeated before it was grouped |
| Timestamps | The moment the check ran on the device and the moment the signal was received |
Two clocks, both recorded
Device clocks can be wrong. Otukan records when the check ran on the phone and when the signal reached the backend, so analysts can order events reliably even when a device reports an odd time.
Transport
The way signals travel from Otukan to your SIEM is agreed during onboarding against the platform you already operate. The field contract stays the same whichever option you use.
Operational fit
Severity that matches your queue
Your SOC already has a severity scale and response expectations for each level. Otukan maps its own levels onto yours, so a mobile alert sits in the queue next to comparable alerts from other sources, not in a separate world.
Correlation
Mobile signals are strongest in combination. A hooking alert at sign-in means more when the same account shows a new device and a password reset in your identity logs. The pseudonymous keys and timestamps on every Otukan alert are there to make that join straightforward.
Saved searches that last
Because the fields are stable, your SOC can keep saved searches for mobile patterns: hooking at sign-in joined with password resets, integrity alerts on payment flows, or emulator summaries joined with failed logins. Those searches keep working as new app versions ship, since the build is a field rather than a change in format.
Deduplication
One compromised phone can trigger the same check many times in a session. Otukan groups repeats from one install in one window into a single entry with a count, so analysts see one line with context instead of a wall of copies.
Escalation
Write down who owns a mobile alert at each level. A common split: the SOC triages, application security owns tuning and policy, and fraud joins when money is involved. The detection label on each alert tells the analyst which path to take. Working a mobile case from alert to conclusion is covered on threat investigation workflows.
Data scope
Send what correlation needs
Every field that leaves Otukan should have a reason. Otukan removes anything outside the agreed scope before delivery. Names, phone numbers, email addresses, message content, contacts, precise location and file contents never enter the stream.
Retention responsibilities
Once alerts sit in your SIEM, your retention rules govern them. Otukan documents which fields it sends and why, and agrees its own retention with you before collection starts. That split makes both sides of a privacy review easier to answer.
Account linkage
Linking a pseudonymous key to a real customer should be a deliberate step. Keep that ability with a small group, record when it is used, and let the SOC work with keys for as long as possible.
Proving the feed
Before go-live, reproduce a small set of conditions in an authorised lab and confirm each alert arrives with the agreed fields, severity and grouping. Then run clean journeys and confirm that nothing reaches the SIEM that should not.
The signal record behind these alerts is described on runtime threat signals. Monitoring as a whole is covered on mobile app threat monitoring. Endpoint risk reported from inside the app is covered on mobile endpoint detection signals.