The Outlier Lab

Emulator and Rooted Device Detection

Platform attestation and integrity checks that reveal whether a request comes from a genuine, unmodified app on a genuine device, or from an emulator, modified OS or tampered client.

What it measures

Three questions, which are often confused with each other:

QuestionTypical evidenceWhy it matters
Is this my genuine app?Platform app attestation, signature and binary integrity, install sourceModified or repackaged clients can manipulate amounts, skip client-side checks, or fake camera input
Is this a genuine, certified device?Hardware-backed device verdicts, verified boot state, bootloader lockEmulators and virtual devices are how device diversity gets manufactured at scale
Is the OS environment intact?Root or jailbreak indicators, hooking and instrumentation indicators, OS patch recencyA modified OS can intercept or forge app behavior, including what the camera and sensors report

The trend is away from client-side heuristics, which a modified environment can lie about, and toward server-verified platform attestation, where a signed verdict comes from the OS vendor.

Why it matters

Emulators and modified devices are the infrastructure of scaled fraud in mobile-first products. They matter most where the app itself is the control:

  • Rewards and cashback: device farms and emulators generate the "unique devices" that bonus, referral and receipt programs ration by device. See Device Farms and Emulators and Receipt Fraud (Cashback).
  • Remote deposit capture and identity capture: if the camera feed can be substituted, document checks, liveness checks and check-image checks are undermined. NIST SP 800-63A-4 now requires identity-proofing services to confirm that media comes from a genuine sensor, giving virtual cameras, emulators and jailbroken devices as examples of what to detect. See Check and Mobile Deposit Fraud, Document Verification and Liveness and Generative AI and Deepfake Fraud.
  • Business logic: tampered clients are a common way to probe pricing, buying-power and reward logic (Business Logic Exploitation).
  • Brokerage and neobank onboarding: emulator-originated applications that go on to fund and withdraw are a strong precursor of Synthetic Identity Fraud and mule staging.

How to collect it

  • Android: the Play Integrity API returns signed verdicts on app integrity, licensing and device integrity. Since May 2025, verdicts on Android 13+ rely on hardware-backed signals by default. The strongest device label also requires a security update within the past year. Google states the basic label can still be met by rooted devices. Optional signals include recent device activity, Play Protect status, app access risk and device recall (beta). SafetyNet Attestation was shut down in January 2025.
  • Apple platforms: App Attest lets your server verify that requests come from a legitimate instance of your app on genuine Apple hardware. It also offers a fraud metric: an approximate count of attested keys for your app on a device over 30 days, where a high count suggests one device serving many app instances. DeviceCheck offers two server-side bits per device, for example to mark a device that has already used a promotion. At WWDC 2026 Apple announced App Attest for macOS 27 and new launch-context and bundle-version data on iOS 27; verify what is available on the OS versions you support.
  • Build or buy: platform APIs are free but need careful server-side validation, quota management and fallbacks. App-shielding and device-intelligence vendors add tamper and instrumentation detection, cover non-Play Android and web, and keep up with an adversary that iterates. Most mature programs combine the two.
  • Validate on the server. A client-side "isRooted" boolean means little without it.

How to use it

  • Tier the response by action. An integrity failure at app open might justify reduced functionality, while the same failure at bonus claim, check deposit, payee add or withdrawal justifies a block or a step-up to a different channel.
  • Use it as a device-diversity check alongside Device Reputation and Linkage. A cluster of "unique" devices that are all virtual is effectively one device.
  • Look for disagreement between sources. A client that reports a phone model while attestation says otherwise, or a timezone that contradicts IP Reputation and Proxy Detection, is more telling than any single verdict.
  • Follow platform guidance. Apple recommends degrading gracefully rather than blocking outright, and treating the fraud metric as an investigation signal. Key rotation from reinstalls and restores is normal.

Strengths and limitations

Strengths: hardware-backed attestation is costly to fake at scale, cheap to consume, and directly addresses camera-injection and device-farm risks that other signals only infer.

Limitations:

  • No attestation is absolute. Apple's documentation notes that a sufficiently modified OS might bypass restrictions, and Android's basic label still accepts rooted devices. Assume detections can be degraded and layer them.
  • Coverage gaps: web traffic, non-Play Android distributions, desktop, and older OS versions.
  • Quotas, latency and outages. Design a fallback for when the platform service is unavailable, and decide in advance whether unknown means allow, review or step-up.
  • Adoption is uneven. A 2025 study of about 125,000 Android APKs found roughly 90% of banking and crypto apps referenced neither SafetyNet nor Play Integrity. Many teams have not yet used the signal they already have.

False positives and fairness

  • Enthusiasts and developers run rooted phones or custom ROMs for legitimate reasons, and the May 2025 hardware-backed changes caught many of them. Blocking them from a balance view is a CX problem; blocking them from instant withdrawal may be defensible.
  • Older or unpatched devices fail the strongest label simply because they aren't patched. Google estimated about a 14.5% drop in strong-integrity responses. Don't require the strong label for everyday actions, or you'll penalize customers with older and cheaper phones.
  • Accessibility and assistive setups sometimes rely on modified environments.
  • Desktop app players and legitimate emulators show up too (QA, some PC gaming contexts).

Privacy and compliance considerations

  • Attestation verdicts are low in personal data compared with fingerprinting and are designed with privacy in mind, which makes them a privacy-favorable substitute where they fit.
  • Disclose integrity checks in privacy notices, and log verdicts with the same retention discipline as other device data. See Privacy and Data Use in Fraud Prevention.
  • If you deny service to customers on modified devices, make sure the policy is stated in your terms and applied consistently.

Mechanisms it helps detect

Device Farms and Emulators · Fake Account Creation (Bots) · Multi-Accounting · Sign-Up Bonus Abuse · Receipt Fraud (Cashback) · Business Logic Exploitation · Check and Mobile Deposit Fraud · Generative AI and Deepfake Fraud · Account Takeover (ATO)

Sources and further reading