Skip to main content
Device Intelligence (DI) answers one question at the point of login, checkout, or any sensitive action: is this device and session trustworthy right now? It combines three layers:
1

RASP — on-device detection

A mobile/web SDK that runs entirely on the user’s device: root/jailbreak detection, emulator detection, debugger and dynamic-instrumentation (Frida) detection, app tamper checks, and more. See RASP in detail.
2

Beyond RASP — network and identity signals

Signals that only make sense with a backend and history behind them: device-to-user graph mapping (is this device shared across many accounts?), device binding, SIM/network signals, and SSL pinning enforcement. See Beyond RASP.
3

Delivery — SDKs, APIs, and live telemetry

Native Android/iOS SDKs (and a Flutter plugin wrapping both), a signed ingest API, and real-time delivery to your systems via webhook or live socket channel. See SDKs and API Authentication.

What Device Intelligence is built to catch

Account takeover

New-device + VPN + credential-stuffing patterns at login, before a session is trusted.

Card testing / BIN attacks

Pasted card numbers combined with rapid OTP failures — a classic bot signature.

Repackaged / tampered apps

Signature-mismatch detection hard-blocks regardless of every other signal — a repackaged APK is a different binary, not a risk gradient.

Multi-accounting / device farms

Device-to-user graph mapping surfaces one device transacting across many unrelated accounts.

Automated / scripted abuse

Behavioral entropy (mouse/touch timing, form-fill speed) and headless-browser/instrumentation detection.

MITM / traffic interception

SSL certificate pinning, enforced at the SDK level, independent of the OS trust store.

Where to go next

RASP in detail

Beyond RASP

SDKs & integration