The QR That Changes Every Thirty Seconds
The oldest trick in attendance is one person clocking in for another. Most of the defences sold against it are theatre. Here is what a tablet on a wall actually has to do, and the one honest sentence about what a photograph of it can still achieve.
Buddy punching is not a technology problem, which is why it survives so much technology. Somebody who is not at work asks somebody who is to mark them present. Every defence against it comes down to the same question — what can the system check that the absent person cannot supply from wherever they actually are.
That framing kills most of what gets sold in this area. A PIN can be shared. A card can be handed over. A code written on the wall can be photographed and sent. None of those check anything about where a person is; they check whether somebody knows a secret, and secrets travel by message in a second.
What follows is the shape of the problem and how a screen on a wall fits into it — including the part where the screen is the weakest of the three factors and is not doing the work people assume it is.
Three independent checks, not one clever one
The design principle worth taking away is that these are additive and independent. Each answers a different question, and none is a substitute for another.
| The check | The question it answers | How it is defeated |
|---|---|---|
| Distance from the site | Is this phone physically near the workplace? | Falsifying the phone's reported position — which is the serious attack, and the reason this is computed on the server rather than trusted from the device |
| The employee's own device | Is this the phone that was registered to this person? | Handing over the unlocked phone itself |
| The site QR code | Was somebody in front of the screen? | A photograph, sent to somebody elsewhere |
Read the third row honestly, because it is the one usually oversold. A QR code on a wall proves that a code was seen. It does not prove who saw it or where the scanner was standing. On its own it is close to worthless as an anti-fraud measure.
It becomes worth having because the other two do not care about it. Somebody who photographs the screen and sends it to a colleague at home has cleared the QR check and still has to defeat the distance check, on their colleague's registered phone, with the position calculated by the server rather than reported by the app.
The QR code is the weakest of the three factors, and it is still worth having — because the other two are unaffected by every way of beating it.
Why the code on the screen changes
The rotation exists to shorten the life of exactly that photograph. The code on the kiosk changes every thirty seconds, and a scan is accepted within one rotation either side of the current one to allow for clock drift and for the second it takes to lift a phone.
So the practical window on a photographed code is under a minute. Long enough to be usable by the person standing there. Short enough that forwarding it to somebody across town is a race they will usually lose, and one they have to re-run every single time.
A small thing worth knowing about how it rotates
The rotating code is derived from the site's secret and the current half-minute, not stored. Nothing is written to the database when it changes. A kiosk running for a year has not accumulated a million rows of expired codes, and the display can rotate as often as it likes without cost. This is the kind of detail nobody asks about and everybody feels later, when the tablet in reception is still working in month eleven.
The printed code, and what it gives up
Not every site should buy a tablet, and the system does not pretend otherwise. There is a second kind of code for the same site — fixed, non-expiring, made to be printed once and pinned to a wall.
This trades one thing away and it is worth stating precisely rather than in general terms. A printed code can be photographed and the photograph does not go stale. Anybody holding that image has cleared the QR factor permanently.
What it does not touch: the distance check still applies, calculated server-side from the submitted position. The employee's registered device is still required. So the printed sign moves you from three factors to two, and the two that remain are the two that were doing the real work.
If a printed code does leak, regenerating the site's secret invalidates it — along with the rotating codes for that site, which is the correct behaviour and worth knowing before you do it in the middle of a shift.
A screen at the door
- Code changes every thirty seconds
- A photograph is useful for under a minute
- Needs a tablet or monitor, power, and a network connection
- Runs unattended for months without a login
- Right for a main entrance with real footfall
A printed sign
- Code never changes
- A photograph works indefinitely until the secret is regenerated
- Costs the paper
- Nothing to break, no power, no network
- Right for a small site, a site office, or anywhere a tablet would not survive
The decision is per site rather than across the organisation, and requiring the code at all is a per-site setting too. A head office with a reception desk and a two-person branch upcountry do not need the same answer.
The screen has no login, deliberately
A kiosk display is opened by a link with a token in it and is not behind a login. That sounds like a shortcut and is the opposite of one — it is the only arrangement that survives contact with a device left running in a corridor for months.
A logged-in session on an unattended tablet dies for reasons that have nothing to do with attendance. The tablet reboots after an update. Somebody clears the browser. The account's password gets changed for an unrelated reason. Signing in somewhere else invalidates it. Each of those turns a working display into a login screen that nobody notices until people cannot clock in, usually at eight in the morning.
The security question this raises is fair and has a short answer: the display holds nothing worth protecting. It shows a code that is meant to be looked at by anyone who walks past, and it changes every thirty seconds. There is no employee list on it, no attendance history, no names.
The message that assumes the employee is honest
One behaviour in the verification is worth describing in detail, because it is the difference between a system people work with and one they work around.
Consider what happens when somebody scans the correct QR code at the correct site, and their phone reports a position four hundred metres away. Two explanations exist. Either they photographed the code from somewhere else, or their phone has a poor position fix — which is extremely common indoors, in a warehouse with a metal roof, or in a basement car park.
The system tells them the second one. The message says the device's location looks unreliable rather than that they are somewhere they should not be, tells them to turn on precise location and try again, and records the attempt for HR to look at.
Both things happen. The person who is genuinely standing in a metal-roofed warehouse is given a fix instead of an accusation, and the attempt is on record either way, so a pattern across a month is visible to somebody who can act on it. The system does not decide who was lying. It refuses the clock-in, explains the most likely cause, and leaves the judgement to a person with context.
And a related one — the accuracy floor
A position that the phone itself reports as accurate to worse than a hundred metres is rejected before the distance is even considered, with a message telling the employee to move outdoors or near a window. This matters because a bad fix can just as easily place somebody inside the radius as outside it. Accepting a vague position that happens to land in the right place is not a check passing — it is a check that did not run.
What a failed clock-in leaves behind
Every attempt is recorded, and the failures are recorded with the same detail as the successes — the position submitted, how accurate the phone said it was, the distance from the site, whether a valid code was scanned, and which registered device it came from.
This is what makes the whole arrangement supervisable rather than merely restrictive. The interesting patterns are not single events.
- One employee whose position is repeatedly rejected at the same site — usually a genuine coverage problem at a specific door, and a reason to adjust the radius rather than the person
- One device that consistently reports poor accuracy — an old phone, and a conversation about the phone
- A valid code scanned from consistently far away — the pattern the honest message was written to surface without pre-judging any single instance
- A site nobody ever fails at, which is worth checking too, because a radius set generously enough covers the car park and the road outside it
What AWRA OpsHub does today
- Server-side distance from the site, computed from the submitted coordinates rather than trusted from the app, against a per-site radius.
- A rotating QR code on the kiosk display, changing every thirty seconds, accepted within one rotation either side, derived rather than stored so nothing accumulates.
- A printable fixed code for sites where a screen is not sensible, with the trade-off documented rather than hidden.
- Per-site control of whether a code is required at all, and of the radius.
- The employee's own device as an independent factor, using the phone's own unlock, mandatory once registered.
- A hard block for anyone who has not registered a device, so the gate cannot be skipped by not setting it up.
- An accuracy floor — a position the phone reports as worse than a hundred metres is rejected before distance is considered.
- Every attempt recorded, pass or fail, with position, accuracy, distance, whether the code verified, and the device.
- A kiosk that survives unattended operation, with no login session to lose to a reboot or a password change.
What it does not do
- No facial recognition and no fingerprint reader. The device factor is the employee's own phone unlock. There is no biometric hardware to buy and none is supported.
- No badge, card or NFC reader path. If your building has card readers, they are a separate system and nothing reads them.
- A photographed printed code stays valid until the site secret is regenerated. That is the stated cost of choosing paper over a screen.
- No report of failed attempts. They are all recorded; reading them is a matter of looking rather than being shown, so the patterns above need somebody to go and check.
- Nothing detects a falsified position beyond the accuracy floor and the distance check. A determined attack on the phone's reported location is not defeated here by anything except the other two factors.
Not ours, by choice
- We will not accept a position the device itself describes as vague. A hundred-metre fix that happens to land inside the radius is not evidence of anything, and treating it as a pass would make the whole check decorative.
- We will not tell an employee they are lying on the strength of one reading. A metal roof and a bad afternoon produce the same data as a photographed code, and a system that accuses on ambiguous evidence gets ignored by everybody including the people it was right about.
A verification report — failures by site, by device and by employee over a period — is scope rather than a ceiling. Every attempt is already stored with everything such a report needs.
The most common mistake in setting this up is a generous radius. Two hundred metres feels safe and quietly includes the road, the car park and the building next door. Set it to the smallest circle that actually contains where people work, then watch the failures for a fortnight and adjust once, on evidence.
What to decide before you put a tablet on the wall
Six decisions, in order
- Which sites get a screen and which get a printed sign. Footfall and whether a tablet will survive there, not policy consistency.
- The radius per site — the smallest circle containing where people actually work, not a comfortable one.
- Whether a code is required at that site at all. A remote two-person office may be adequately covered by distance and device alone.
- That every employee registers a device before the day this goes live, because an unregistered employee cannot clock in at all.
- Who looks at failed attempts, and how often. Nothing will bring these to you.
- What you will do about the first genuine bad-signal case, because there will be one in the first week and how you handle it sets how the whole thing is received.
The wider HR picture is in HR software in Kenya, the working-week settings that interact with attendance in the working week and public holidays, and the device-side controls in the phone that left with the storekeeper.
Our take
Treat the QR code as the least important of the three factors and you will make good decisions about it — screen where there is footfall, printed sign where there is not, and no agonising over which. The two that matter are the server-side distance check and the registered device, and neither is affected by any way of beating the code. Set the radius tight, make sure everybody registers a phone before go-live, and give one person the job of reading failed attempts monthly, because that is where the useful information is and nothing will bring it to you.
See attendance verification
Server-side geofencing, a rotating kiosk code, the employee's own device as an independent factor, and every attempt recorded whether it passed or failed.
Explore attendanceFrequently asked questions
Can somebody clock in for a colleague?
They would have to defeat three separate checks. The distance from the site is calculated on the server from the submitted position rather than trusted from the app. The clock-in must come from the phone that colleague registered, unlocked by them. And where the site requires it, a valid site code must be scanned. Photographing the code and sending it defeats only the third, and on a screen that code is useful for under a minute. The realistic remaining route is handing over an unlocked phone, which is a management problem rather than a technical one.
Why does the code on the screen keep changing?
To shorten the life of a photograph. It changes every thirty seconds and a scan is accepted within one rotation either side, to allow for clock drift and for the moment it takes to raise a phone — so a photographed code is useful for under a minute, and has to be re-photographed every time. The code is derived from the site secret and the current half-minute rather than stored, so nothing accumulates in the database no matter how long the display runs.
Can we print the QR code instead of buying a tablet?
Yes, and for many sites you should. There is a fixed, non-expiring code for exactly this. The cost is stated plainly: a photograph of a printed code does not go stale, so anybody holding that image has cleared the code factor permanently. What is unaffected is the server-side distance check and the registered-device requirement — the two factors doing the real work. If a printed code leaks, regenerating the site secret invalidates it, along with that site's rotating codes.
Do we need a fingerprint or facial recognition device?
No, and none is supported. The device factor uses the employee's own phone and whatever unlock that phone already has. There is no biometric reader to buy, no enrolment hardware, and no card or NFC reader path — if your building has card readers they are a separate system and nothing here reads them. For most operations this is a saving rather than a limitation, because the phone is already in the pocket and already unlocked by its owner.
What if an employee genuinely cannot get a GPS signal?
It is anticipated. A position the phone reports as accurate to worse than a hundred metres is rejected before the distance is considered, with a message telling the employee to move outdoors or near a window — because a vague fix landing inside the radius is not a check passing. And if a valid site code is scanned while the device reports a distant position, the message says the device's location looks unreliable rather than accusing anybody, and logs the attempt for HR to review. Both the fix and the record happen.
Why is the kiosk screen not behind a login?
Because a login session cannot survive months of unattended operation. The tablet reboots after an update, somebody clears the browser, a password changes for an unrelated reason — each turns the display into a login screen, discovered at eight in the morning when nobody can clock in. It opens from a link with a token instead. The security question is fair and the answer is short: the display shows a code meant to be looked at by anyone walking past, changing every thirty seconds, with no names, no employee list and no history on it.
What should we set the radius to?
The smallest circle that actually contains where people work. Two hundred metres feels safe and quietly includes the road outside, the car park and the neighbouring building — at which point the distance check has stopped checking anything useful. Set it tight, watch failed attempts for a fortnight, and adjust once on the evidence. A site where nobody ever fails is worth investigating for the same reason a site with constant failures is.
