Detecting Device Farms Behind Fake Web Accounts

Last updated: October 9, 2026

Device farm fraud detection begins by defining the activity you want to stop. A device farm can be a legitimate testing lab: AWS Device Farm runs automated tests and provides remote access to real devices. In an abuse investigation, the same phrase can describe coordinated devices or browser contexts used to create accounts and claim benefits repeatedly. AWS describes its test devices as “real, physical phones and tablets”. The equipment alone does not establish fraud.

For a web product, investigate the relationship between browser contexts, accounts, timing and the benefit being claimed. Look for repeated eligibility violations or coordinated actions, then connect those actions to available device and risk evidence. A collection of similar devices is a lead, not a confirmed fraud outcome.

TL;DR: Separate QA labs from coordinated account abuse. Review account creation, repeated rewards, browser/device linkage and timing together. Keep legitimate shared-device use visible, and release rewards only after the required qualifying event.

What does a device farm look like in web account abuse?

A web account farm is an operation that coordinates many accounts to repeat an action: consume introductory credits, receive referral payouts, amplify fake reviews or return after an access restriction. It may use physical devices, multiple browser profiles, automated sessions or ordinary human operators.

That range matters. Browser automation is evidence about how an action ran; multi-accounting is evidence about the relationship between accounts and activity. Human-operated account abuse can occur without automated browser signals, while permitted automated testing can produce those signals without abuse.

Define prohibited behavior in your product terms and qualification rules. An account investigation should explain the repeated action or eligibility issue, rather than simply attach the label “device farm.”

Which signals are useful for finding coordinated fake accounts?

Use a combination of relationship and sequence evidence. Link an account's signup, first use, benefit claims and later activity to the observations available at those moments. Look for repeatable connections across the cluster, not one isolated property.

Device evidence can connect accounts that otherwise look independent. Timing can show a repeated sequence. Application records can reveal whether several accounts claimed a benefit they were not entitled to. These answer different questions and should remain distinguishable in the record.

A helpful review packet includes the account IDs, associated observation IDs, browser/device contexts, named risk signals, signup and action timestamps, qualifying events and benefit destinations. Minimize the data retained and restrict investigator access. You do not need to copy every available raw browser attribute into a support ticket.

Why are IP counts alone insufficient?

Public IP addresses represent network paths, not verified people. Ordinary users can share an address, and one operation can move among several addresses. Treat IP overlap as network context that strengthens or weakens a larger relationship hypothesis.

If a campaign produces many signups from one IP, compare that cohort with the offer's intended audience and expected timing. A campus promotion can produce dense legitimate activity; repeated identical benefit claims across linked accounts justify a different review. An address-based cutoff cannot explain that difference on its own.

Use residential proxy detection when masked network paths are relevant, and read those results with device and account context. A proxy or VPN signal does not by itself prove that an account is fake, nor does a direct connection establish entitlement to another reward.

How do you investigate a cluster before holding benefits?

Start with one suspicious action and expand only through relevant relationships. Check the qualifying account, its recent observations and other accounts associated with the same browser context. Then review whether the connected accounts repeated the same restricted action.

For example, an illustrative referral review might identify a referrer and three referred accounts linked through a returning browser context. The next step is to examine qualifying conversions and payout eligibility. It is not enough to conclude that all four belong to one person from a device association alone.

Use a pending reward state while the required qualification or review remains incomplete. Keep the hold reason and review deadline visible to operations. A permanent access restriction is a different action and needs its own evidence and account policy.

The referral fraud workflow provides a detailed payout process. Keep this investigation focused on coordination across accounts, then apply the existing reward workflow instead of creating an unrelated “farm score.”

How does ShieldLabs help detect web account farms?

ShieldLabs provides persistent device identification, named risk signals, browser automation detection and four ready-made High-Risk Events: Multi-accounting, Account sharing, Impossible travel and Account takeover. These support investigation of repeated web activity and account relationships.

By default, Multi-accounting starts from three accounts associated with one visitor; Account sharing uses four devices on one account. Each event has Medium or High confidence. That confidence is separate from the risk score of an individual identification and should be retained as its own field in an investigation.

Pass a hashed or pseudonymous User HID on signed-in pages so observations can relate to your application's accounts. Review linked activity in the analytics dashboard and consume verified results through API or webhooks. The High-Risk Events reference explains the available events.

This use case concerns fake web accounts and coordinated benefit claims. A Browser Automation result does not identify the physical equipment used, and the product should not be described as proving that an operation owns a particular device fleet. Use the detected relationships and your own confirmed outcomes to describe what happened.

How do you reduce abuse without making shared devices unusable?

Match the response to the benefit and the available evidence. Email or phone verification, limits on introductory credits, verified qualifying actions, rate limits and device/account review can all contribute. Each leaves gaps, so use them in a workflow that records why an account received extra friction.

Keep exceptions grounded in your business. A legitimate coworking customer or household may need several accounts; a partner's approved testing may create automated sessions. Maintain explicit test identities and authorization records rather than silently ignoring all activity from a broad network range.

Do not reward a cluster merely because it evades a single signal. Validate qualification at the operation where value is released. OWASP's sensitive business flow guidance is useful for deciding which repeated actions need product-level controls.

What should you measure after changing the workflow?

Track repeated benefit claims, confirmed eligibility violations, unresolved reviews and legitimate users affected by holds. Keep the number of detected account events alongside those outcomes, not in place of them.

Compare similar cohorts over time and annotate offer changes. A more popular promotion can increase both legitimate activity and review volume. Report the denominator, review completion rate and time to resolution before claiming that device-farm fraud increased or fell.

A cluster can evolve as more activity arrives. Preserve the observation sequence and the reasons behind each action, then record corrections when a case is resolved. The useful output of an investigation is an explainable account and benefit decision, not a dramatic label for the hardware you imagine behind it.

Ready to investigate linked web accounts?

ShieldLabs detects repeated account abuse with identification, risk signals and High-Risk Events. Start Free with 5,000 one-time identifications and review the relationships behind your product's signups.

Sources

• AWS Device Farm: legitimate device testing
• OWASP API Security: sensitive business flows
• ShieldLabs High-Risk Events
• ShieldLabs identification model
• Stripe: promo abuse prevention

Recommended

• Multi-accounting Prevention
• Referral Fraud Detection
• Free Trial Abuse Prevention
• Fraud Analytics