One operator can look like many applicants
Fingerprint, a device-intelligence vendor, notes that most anti-fraud systems cap sign-ups per device and that controlling hundreds of devices lets attackers step around the cap. Four set-ups matter here. An emulator is software that imitates a phone on a computer or server. A rooted device runs with the platform's restrictions removed. App cloning runs several copies of one app on a single handset, which OWASP lists as a way to get past multi-account limits. A device farm is a set of phones, real or virtual, operated together to mimic many users.
Group-IB traces how the set-ups moved on as detection improved. Emulators leaked obvious artefacts and became easy to catch, so operators built racks of genuine Android phones on USB hubs, with real identifiers, sensors and radios and no sign of a virtual environment. Rented cloud phones followed, running on ARM server chips with real-device values. Each step looks more genuine than the last, so no single device check is enough.
Emulators and farms show up in installs and in applications
Installs with no genuine user behind them
AppsFlyer describes device farms as fraudsters performing clicks, installs and other engagement by hand to simulate genuine activity, hiding behind fresh IP addresses, a wide mix of devices and repeated device ID resets. Because each install looks new, judge the source by what its installs do afterwards. Installs that people are paid or rewarded to make are covered in incentivised traffic.
Applications from devices that each look new
Group-IB reports cloud phones used to create, verify and operate bank accounts, each on its own device with its own identifiers. Your onboarding has the same steps (registration, one-time code, application), so the same set-ups can be pointed at it. The giveaway is rarely one application. It is the pattern across applications. Fingerprint points to devices that share hardware and operating system attributes, many users from the same IP ranges, and new accounts that engage quickly with no browsing or idle time first, because farms favour throughput over realism.
Platform attestation checks the device and the app build, not the applicant
On Android, the Play Integrity API returns an encrypted token that your backend decodes on Google's servers into verdicts on the device, the app build and whether the app was installed or updated by Google Play. MEETS_DEVICE_INTEGRITY means a genuine, certified device. An empty device verdict points to signs of attack such as API hooking, system compromise such as root, or a non-physical device such as an emulator that fails Google's checks. Optional labels such as MEETS_BASIC_INTEGRITY support tiered enforcement, which Google recommends because fewer devices reach the top tiers. You enable them in Play Console, and on Android 13 and higher they are returned only for apps installed or updated by Google Play.
On iOS, App Attest creates a hardware-backed key in the Secure Enclave and has Apple certify that it belongs to a valid instance of your app. Your server then requests signed assertions at sensitive moments, each tied to a one-time challenge. Apple also reports an approximate count of attested keys per device over 30 days. A higher count than expected may mean one compromised device is serving several modified copies of the app.
Know what attestation does not say. A rack of genuine, certified phones is genuine by these tests, so a farm of unmodified handsets passes. Group-IB also reports that cloud phones can present valid app integrity signals and device attestation, so a passing verdict does not rule out a rented device. Attestation needs an app, so a web form gets none of it and relies more on network, timing and per-device counts.
Build and hardware anomalies help only in combination
OWASP lists what default emulator images tend to expose: generic or emulator strings in build fields such as fingerprint, model, hardware and product, fixed telephony values, and emulator-specific files and packages. Group-IB adds hardware that contradicts the claimed model, such as x86 processors on a handset presenting as ARM. OWASP calls emulator detection a cat-and-mouse game and warns that a single source of indicators, such as system properties, is one emulators can trivially fake.
A hit is not proof either. In 2020, IBM Trusteer flagged an emulator-based operation against bank apps with several fraud-like red flags. The investigation traced it to a third-party financial service working with account holders' consent: legitimate actors, though against the bank's app terms.
Each signal has a blind spot
| Signal | What it suggests | Where it misleads |
|---|---|---|
| Device integrity verdict | An empty verdict suggests root, hooking or an emulator. A basic label alone (opt-in, Play-installed apps) means the device may be uncertified or have a bootloader that is not locked. | Farms of unmodified handsets and cloud phones can pass. A weak connection can return no labels, and so can decoding the same token twice. |
| App integrity verdict | UNRECOGNIZED_VERSION means the certificate or package name does not match Play records, which can point to a modified or re-signed build. | Describes the build, not the person using it. |
| App Attest result | A failed attestation or assertion suggests the request did not come from a valid instance of your app. | Apple says it cannot definitively pinpoint a device with a compromised operating system. |
| Attested keys per device | Apple's 30-day count. A high value may mean one compromised device serving many app copies. | Reinstalls, restores and device transfers raise it. |
| Recent device activity | If enabled, LEVEL_4 on Android means more than 50 standard integrity requests from your app on that device in an hour. | Google calls the levels approximate. It shows volume, not intent, and is not evaluated for apps not installed from Google Play on Android 13 and higher. |
| Build and hardware values | Generic build strings, fixed telephony values, emulator files, or a CPU that contradicts the claimed model. | Easy to fake on emulators. Cloud phones report real-device values. |
| App virtualisation | Several copies of one app running inside a container on a single handset. | Frameworks change, so detection needs regular testing. |
Signals you can read, and where each one misleads.
Controls you can run on your side
- Verify on the server and bind the verdict to the request. Use a one-time challenge, nonce or request hash so a verdict cannot be replayed on another application. Decode Android tokens on Google's servers. Do not cache verdicts: Google says caching raises the risk of proxying, where a verdict from a good device is reused elsewhere.
- Ask at sensitive moments, such as submitting the application. Apple notes that assertions are typically reserved for sensitive requests, though it sets no cap on their number, and Google applies a default daily quota to integrity requests that you can ask to raise.
- Answer in tiers, not yes or no. Google suggests outcomes such as allow, allow with limits, allow with limits after a CAPTCHA, and deny. For a borderline device, step up verification or send the case to manual review before the credit decision.
- Count identities per device and network range and watch the time between install and application, but send hits to review instead of rejecting automatically; windows, thresholds and shared-address cases are in velocity and behaviour signals.
- Remember bad devices. Google's device recall (beta, opt-in, Play-installed apps only) stores three true/false flags per device, shared across your developer account's apps, that survive reinstalls and resets, so a device you flagged once can be recognised again. Phones are resold and shared, so treat a recalled flag as a reason to look closer, not as a ban.
- Log raw verdicts with every application and compare outcomes by verdict, device class and install-to-application time. Thresholds should come from your own data; see lead quality by source.
Device integrity is one check among several
CYBERTECH reads device integrity as far as the channel exposes it, alongside its four other checks, and no single signal decides. The full sequence is on the anti-fraud page.
Related guides
- Screen loan leads for fraud and fit before they reach youFive checks, including fit to your own criteria, screen applicants before handoff. No single signal decides, and a stopped applicant is not delivered to you.
- Velocity and behavioural signals expose scripted loan applicationsHow velocity windows and form-fill behaviour expose bots and rings, where they misfire on shared devices and networks, and how to tune them.
- Incentivised traffic can inflate applications and hide weak outcomesRewarded installs and offerwall traffic can inflate application counts without intent; source signals point to them and contract terms limit them.
- Duplicate, recycled and synthetic identities hide between applicationsHow duplicate applications, recycled identities and synthetic identities appear in lead flows, and why de-duplication should run before billing.
Sources
- Google: Play Integrity API overview (2026)
- Google: Play Integrity API verdicts (2026)
- Google: Play Integrity API standard requests (2026)
- Google: Play Integrity API classic requests (2026)
- Google: Set up the Play Integrity API (2026)
- Google: Detect repeat abuse using device recall, beta (2026)
- Apple: Establishing your app's integrity (2026)
- Apple: Assessing fraud risk (2026)
- Apple: DeviceCheck (2026)
- OWASP: MASWE-0053 Emulated or virtual device detection not implemented (2026)
- OWASP: MASTG-KNOW-0031 Emulator detection (2026)
- OWASP: MASWE-0052 App virtualization environment detection not implemented (2026)
- Group-IB: Cloud phones, the invisible threat (2026)
- AppsFlyer: What is a device farm (2023)
- Fingerprint: How to detect device farm fraud (2025)
- IBM Security Trusteer: The new frontier of fraud (2020)