# How is checking in from another phone kept under control? - Canonical: https://qrgate.az/en/blog/checking-in-from-another-phone - Markdown: https://qrgate.az/en/blog/checking-in-from-another-phone.md - Language: en - Date: 2026-07-17 Almost every company choosing a mobile attendance system asks the same question: is **checking in from another phone** possible, and how does the system see it? The question is fair. The answer has more layers than expected - and when those layers work together the picture looks quite different. ## The scenario behind the question The worry usually comes from one specific image: an employee opens their account on a colleague's phone, and that colleague checks in for them in the morning. The scenario is real and should be accounted for. But whether it is possible depends on how the system is built - the phrase "mobile check-in" says nothing on its own. The practical difference is this: does the system store only the fact of the record, or its *context* as well? ## Layer one: the device The device the record was made on is stored. For a single event that says little, but over time it builds a picture. Because device history exists, what shows later is: does this employee always check in from the same device, or does the device change often? A second detail is less well known: two devices of the same make and model can be identified as distinct devices. The argument "they're both the same phone" therefore does not hold in practice - devices are tracked as individual records, not by model name. ## Layer two: device changes An employee moving to another device is normal - phones get replaced, broken, lost. The system does not block that and should not. The difference is that the change **appears as a separate event** and the relevant people can be notified of it. That produces two practical results. The case does not stay hidden. And work does not stop - the employee carries on from their new phone while the event is recorded and reviewed if needed. ## Layer three: location matching The record is checked against the location of the entry point. This works independently of the device layer, and that is exactly why it is valuable. A practical scenario: the record was made away from the expected point *and* a device change was logged the same day. Individually each event has an ordinary explanation - a change of site and a phone upgrade. Arriving together, they become a case worth reviewing. More on this: [GPS attendance system](https://qrgate.az/en/gps-attendance-system). ## Layer four: the notification All the layers work on one condition: the event has to become visible *in time*. When a mismatch reaches the responsible person as a notification, the matter is discussed the same day. A case that surfaces at month end is practically unresolvable - twenty-six days later neither the employee nor the manager remembers the day precisely. That is an organisational difference rather than a technical one - and one of the biggest factors in the outcome. ## What not to promise Honesty matters here: no system rules out misuse of a record entirely. That is not fully true of fingerprints or facial recognition either - they too have condition-dependent exceptions. The practical goal is different: to make misuse *harder* and, when it happens, *visible in time*. Four layers working together achieve that. A single layer - whether the code or the device - does not. ## What to tell the team The most common mistake on this subject is silence. When device control is not explained, the team learns about it by accident - and that always leaves a bad impression. The explanation that works in practice is one sentence: *the system stores which device the record came from, and device changes appear separately - this is a measure applied to the record, not to the person.* To that, add the second side of transparency: employees can see their own records in the app too. One-sided control creates resistance; two-way transparency reduces it in practice. ## A worked example: two signals coinciding At a retail chain, one employee's records produced a mismatch signal three times over two months. Individually all three had an explanation. The first time their phone had been replaced. The second time the record was made at a neighbouring branch - they had genuinely worked there that day. The third time both happened on the same day: a new device and a record away from the expected point. The branch manager received a notification on the third and asked the same day. The answer turned out to be simple: the employee had been sent to help at another site that morning, and this had not been recorded in the system. Two steps followed. A separate record type was created for site changes - so similar cases no longer showed up as mismatches. And the company noted a lesson: the value of the signals lies not in each alone but in their coincidence. ## When it is worth looking closely The practical rule has three points and keeps notifications from turning into noise. **A single signal - not reviewed.** A device change on its own is ordinary; phones get replaced, broken, lost. **Two signals on the same day - reviewed.** When a device change and a location mismatch arrive together, the event is worth asking about. **A repeating pattern - investigated.** An employee who changes device several times a month and one who updates their phone once a year are different cases; only device history shows that. Built as a written rule, these three points reduce the number of notifications and get the remaining ones read. ## The next step Device control is not a system on its own - it is one of the layers that raise the reliability of a record. The best result comes together with the location and notification layers. [Read the full security discussion](https://qrgate.az/en/is-qr-check-in-system-secure), [look at what QRGate does](https://qrgate.az/en/advantages), or [calculate the price](https://qrgate.az/en). ## FAQ ### Is it a problem when an employee changes phone? No, this is a normal event and the system does not block it. The difference is that the change appears as a separate event and the relevant people can be notified. So the case does not stay hidden, but work does not stop either. ### What if two employees have the same phone model? Devices of the same make and model can be identified as distinct devices. The argument "they're both the same phone" therefore does not hold in practice - devices are tracked as individual records, not by model name. ### Why does device history matter? A single event says little; the picture builds over time. An employee who changes device several times a month and one who updates their phone once a year are different cases - without history, the two look identical. ### Is this enough on its own? No, and it should not be built that way. Device control is useful when it works alongside location matching and notifications. In practice, two independent signals coinciding on the same day make a case worth reviewing; a single signal usually has an ordinary explanation. ## Related pages - Schedules and attendance - [Markdown](https://qrgate.az/en/managing-schedules-and-attendance-together.md) | [HTML](https://qrgate.az/en/managing-schedules-and-attendance-together) - QR or turnstile - [Markdown](https://qrgate.az/en/qr-attendance-or-turnstile.md) | [HTML](https://qrgate.az/en/qr-attendance-or-turnstile) - QR system security - [Markdown](https://qrgate.az/en/is-qr-check-in-system-secure.md) | [HTML](https://qrgate.az/en/is-qr-check-in-system-secure) - Attendance for field teams - [Markdown](https://qrgate.az/en/attendance-for-field-teams.md) | [HTML](https://qrgate.az/en/attendance-for-field-teams) - Mobile attendance system - [Markdown](https://qrgate.az/en/mobile-attendance-system.md) | [HTML](https://qrgate.az/en/mobile-attendance-system) - Alternatives to a fingerprint system - [Markdown](https://qrgate.az/en/alternatives-to-fingerprint-attendance.md) | [HTML](https://qrgate.az/en/alternatives-to-fingerprint-attendance)