Mock locations, emulators, rooted devices, jailbroken devices, and unapproved phones all need different operational responses.
Every workforce attendance system eventually meets the same set of adversaries. A mock-location app from the Play Store. An Android emulator running on someone's laptop. A rooted phone with developer tools that let the user override anything the app reports. A second handset that turns one employee into two check-ins.
The mistake teams make is treating all of these as the same problem. They are not. Some of them are deliberate fraud. Some are honest configuration choices that happen to break your assumptions. If you respond to every signal with a block, you push genuine workers out of the system. If you respond to none of them, you stop being able to defend any of the data you collect.
This is a guide to what each signal usually means, and how to respond proportionally.
Modern workforce SDKs expose a fairly standard set of device signals. The ones that matter most for attendance integrity are:
Collect all of them. Decide what to do with them based on operational context, not absolute rules.
A small number of signals are unambiguous enough to block at the gate — meaning the check-in never reaches your timesheets at all.
If isMockLocation is true at the precise moment of a check-in, the location data is unreliable by definition. Block the action and surface a clear message: "Location services are returning a simulated location. Disable mock locations under Developer options and try again."
This is the one signal where a hard block is almost always correct. There is no legitimate use of mock locations during a real check-in.
A real worker on a real shift is not checking in from BlueStacks. Block these unconditionally and treat the account as needing review.
If the device clock is more than five minutes off server time, your timestamps are not defensible. Reject the check-in and ask the user to enable automatic time sync.
The next tier of signals are not proof of fraud. They are reasons to look more carefully. The right response is to record the attendance and flag it, not to block.
A rooted Android phone or a jailbroken iPhone has bypassed OS-level controls. That does not mean the person holding it is committing fraud. Developers, hobbyists, and people who bought a second-hand phone all carry rooted devices. But the integrity guarantees you usually rely on (Keystore, Secure Enclave, package signature checks) are weaker on these devices.
Record the check-in. Tag the record with a device.root signal. Make it filterable in the exception report. Decide policy by role and risk — a logistics coordinator on a rooted device is a different concern from a security guard with cash-handling responsibilities.
The employee is checking in from a device that was not registered to them. The most common explanation is a new phone. The second most common is buddy punching.
Treat it as a device-registration event, not a fraud event:
A fresh install of the app on the same user account is sometimes legitimate (phone reset, OS upgrade) and sometimes a workaround for an earlier block. Flag it for the first few check-ins, then return to normal once the device signature stabilises.
Some signals look interesting but rarely add operational value.
Developer mode alone. Many engineers and power users have it enabled. By itself, it tells you almost nothing. Use it only in combination with other signals — for example, developer mode plus emulator plus reinstall is a much stronger pattern than developer mode by itself.
Foreign SIM / roaming. Field workers cross borders. Drivers visit warehouses across state lines. Roaming is not a fraud signal.
Battery saver / low-accuracy mode. This degrades GPS quality, but it is a configuration choice, not a fraud one. Surface it to the worker as a quality hint: "Your GPS is in battery-saving mode. Your check-in location may be less accurate."
The pattern that holds up across hundreds of rollouts looks like this:
The aim of device integrity is not to win an arms race with adversarial users. It is to make the records you produce defensible — to payroll, to HR, to auditors, and to the employees themselves. A worker whose check-in is wrongly blocked deserves to know why. A worker whose colleague is faking attendance deserves the system to notice. Both outcomes come from the same discipline: collect generously, block narrowly, review consistently.
Keep reading
Fingerprint readers and ID cards at the office entrance solved a 2005 problem. Hybrid schedules, client sites, and remote days have outgrown them. Here is what to use instead — and how to migrate without breaking trust.
Attendance trustA practical framework for combining selfie evidence, local biometric approval, approved devices, and manager review without slowing employees down.
Onsight can help you define geofences, trust controls, exception flows, and reporting rules around your real workforce.
Walk through your rollout
Bring your site structure, employee groups, and compliance concerns.
Book demo