Application security protection

Mobile app threat monitoring

Otukan turns runtime threat signals from your mobile apps into clear, release-aware insight your security team can investigate and act on in its own SOC tools.

  • Android
  • iOS
  • Flutter
  • React Native
Attacks in the field is met at the backend monitoring boundary before it reaches the appAttacks in the fieldBackend monitoringYour app
  • Visibility in the field

    Protected apps report what their runtime checks observe on real devices, so you see how your app is attacked after release, not only in tests.

  • Context, not noise

    Otukan groups signals by release, platform, device and account, so analysts spend time on the patterns that matter.

  • Action in your tools

    Findings drive app response policy and flow into the SOC workflow you already run, with telemetry limited to what a decision needs.

What Otukan monitors in the field

Select a threat to see how Otukan detects it, how the app responds and what your team receives.

Hooking frameworks

  1. Detect

    Runtime checks spot injected code and instrumentation frameworks in the app's process.

  2. Respond

    The app observes, warns, restricts or terminates, per the policy for that flow.

  3. Report

    A signal with the check, severity, app build, platform and OS version reaches your backend and SOC.

Debuggers and tracers

  1. Detect

    Checks detect a debugger or tracer attached to the running app.

  2. Respond

    Sensitive flows are restricted or the session ends, as your policy sets.

  3. Report

    Analysts see where and on which builds debugging attempts cluster.

Rooted and jailbroken devices

  1. Detect

    Android root and iOS jailbreak checks, each scoped to its own platform, report a modified operating system.

  2. Respond

    The app limits high-risk features or asks the backend to step up.

  3. Report

    Rates per platform and OS version show whether a change is an attack trend or a new system image.

Repackaged builds

  1. Detect

    Integrity checks find code, resources or a signing certificate that differ from your release.

  2. Respond

    The modified copy is kept out of sensitive flows, per your policy.

  3. Report

    Your team sees which builds are being repackaged and where they surface.

Emulators and automation

  1. Detect

    Checks recognise virtual devices and automated environments.

  2. Respond

    Sessions from emulated devices are limited per flow.

  3. Report

    Volume spikes tied to new accounts are highlighted for investigation.

Parts of Otukan threat monitoring

From the signal on the device to the decision in your SOC, each part does one job well.

  • Runtime threat signals

    A structured record each time a check fires: what was seen, on which build, platform and OS version.

  • Threat analytics

    Trends, spikes and top-firing checks across users and releases, so changes in attacker behaviour stand out.

  • Investigation workflows

    Filter and link signals to sessions, pseudonymous accounts and releases to confirm whether an attack is real.

  • Threat response

    Turn what monitoring shows into app and backend policy: observe, warn, restrict or terminate, per user flow.

  • SIEM integration

    Normalised app signals delivered to the SIEM or SOC platform your analysts already use.

  • Endpoint detection signals

    App-level signals placed next to device-level detection, so analysts see a mobile case in context.

You choose the response

Set a response for each user flow. Start by observing, then tighten flow by flow as the signals prove themselves.

Observe

Signal sent to your backend

Rolling out a new policy and measuring real-world signals.

Warn

This device looks modified. Continue with care.

Conditions some genuine users create, such as developer settings.

Restrict

Payments are unavailable on this device.

Payments, stored data and account changes.

Terminate

Session closed for your security.

Clear tampering on a high-risk flow.

How it works

  1. Detect on device

    Runtime checks in the protected app observe threats while it runs.

  2. Send the signal

    A minimal, pseudonymous signal reaches your backend with build, platform and OS version.

  3. Group and filter

    Otukan aggregates signals by release, platform, device and account, with severity levels.

  4. Investigate

    Analysts link signals to sessions and releases to confirm a real attack.

  5. Act

    Tighten app response policy and route alerts through your existing SOC.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

Otukan shows your security team how your mobile app is attacked after release, on real devices. Protected apps send runtime threat signals to your backend while they run. Otukan groups them by release, platform, device and account and separates a detection (a check fired) from a confirmed attack (signals and backend evidence agree) and a business incident (users, money or data affected). Analysts see which signals matter, and the findings drive your app response policy and the SOC tools you already run. It covers Android, iOS, Flutter and React Native apps, reporting each platform on its own terms.

Event meaning

The same signal can mean very different things. Otukan labels each level, so a single detection does not set off an incident response.

LevelWhat it isExampleWho acts
DetectionOne check fired on one deviceA hooking framework seen in the app’s process at loginApp response policy acts automatically; analysts watch trends
Confirmed attackSignals and backend evidence agreeThe same detection across many new accounts, with scripted API patternsSecurity team investigates and tightens policy
Business incidentAn attack with real impactFraudulent transfers from accounts that showed those signalsIncident response, fraud and business owners

Every check maps to a small set of severity levels, so an analyst can tell a low-risk developer-device signal from repeated tampering on a payment flow without reading the app’s code. What a single signal records is covered on runtime threat signals.

Investigation

Aggregation

One device tells you little; patterns tell you a lot. Otukan counts signals over time, by check, platform and OS version, and highlights change. A sudden rise in one check on one Android version points to a new system image; a rise across versions tied to new accounts points to a campaign. Trend views are covered on threat analytics.

Filters

Analysts narrow signals quickly: by check, severity, app version, platform, OS version and time window, and by pseudonymous account or install identifier when a case needs it.

Linkage to app releases

Every signal carries the app build that produced it. Otukan compares rates before and after each release, so you can tell whether attackers shifted or a check changed, and see whether older versions still in use are being targeted. That makes monitoring a direct input to release planning. Case handling is covered on threat investigation workflows.

Platform differences

Android and iOS signals are reported separately. Android checks can usually see more of the system and report more categories; iOS checks work inside a tighter sandbox and infer more indirectly. Otukan keeps comparisons within a platform, so a gap between platforms reads as a difference in visibility, not in attack volume.

Action

App policy

Monitoring shows which responses are safe to enforce. Start a new check in observe mode, see how often it fires on legitimate users, then move specific flows to warn, restrict or terminate. When rates change, Otukan shows it, and you adjust the policy with evidence. Policy design is covered on threat response.

Existing SOC tools

Mobile signals are most useful next to login, API and fraud logs. Otukan delivers normalised signals to the SIEM or SOC platform you already run, with a field format and severity scale agreed with your SOC. Send high-severity signals and summaries rather than everything, and name who owns a mobile alert at each level. SIEM delivery is covered on SIEM integration.

Privacy of telemetry

Threat monitoring must never become user monitoring, and Otukan is designed that way. Signals carry what a decision needs and nothing more:

  • which check fired, its result and a timestamp;
  • app build, platform and OS version;
  • a pseudonymous install or device identifier, never a name, phone number or email;
  • no message content, contacts, precise location or file contents.

Retention is set before collection starts, access to account linkage can be restricted, and data flows are documented for your privacy team. Data handling is covered on data privacy.

For the wider picture, return to mobile app security.

Common questions

  • Is a runtime threat signal the same as an attack?

    No, and Otukan is built around that difference. A signal records that a check fired. It can come from an attacker, a developer device or a user with a custom system image. Otukan groups signals by release, device and account, so an attack stands out when many signals and backend evidence point the same way.

  • What data does Otukan telemetry include?

    Only what a security decision needs: which check fired, its result, the app build, platform, OS version, a pseudonymous install identifier and a time. No names, message content, contacts, precise location or file contents. Retention is agreed before collection starts, and the data flows are documented for your privacy team.

  • Can Otukan feed our existing SIEM?

    Yes. Mobile signals are most useful next to authentication, API and fraud logs, where your analysts already correlate events. Otukan delivers normalised signals with a severity scale you agree with your SOC, and can send summaries and high-severity signals rather than every observation, so the SIEM stays focused.

  • Why do Android and iOS show different numbers?

    Because each platform lets an app see different things. Android checks can usually observe more of the system; iOS checks work inside a tighter sandbox. Otukan reports each platform separately, so you compare like with like and read a gap as a difference in visibility, not in attack volume.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

See how your app is attacked

Tell us the platforms and app framework, the SOC or SIEM tools you already run and what you most need to see. We do not ask for binaries, signing keys, production credentials or user data.

Or request a technical demo