Nobody Clocks In Until a Device Is Registered
Clocking in requires a registered device, and that is not a setting somebody forgot to make optional. An employee who has not enrolled one is refused with an instruction rather than let through with a warning — and the refusal is written down.
Our take
Attendance systems fail in one direction far more often than the other: they let a punch through when they should not, because refusing somebody who is standing in front of you is uncomfortable and letting them through costs nothing today. The position here is the opposite one. A clock-in with no registered device behind it is refused outright, with a message telling the person what to do about it, and the refused attempt is recorded. That is deliberately inconvenient on day one and quietly valuable for the following three years, because it means every hour in the register was claimed by a specific device that a specific person enrolled — and there is no path around it that leaves no trace.
Two people can share a password. Two people cannot share the fingerprint sensor on one of their phones without one of them being present.
What has to be true before an hour is recorded
Every clock-in and clock-out passes through one gate, and the gate asks its questions in a fixed order. The first three are about the device, and none of the location machinery is even reached until they pass.
-
Is verification enabled for this employee?
It becomes enabled automatically the moment they register their first device, and HR can switch it off for an individual. Anyone who has not enrolled, or who has been disabled, is stopped here with a message telling them to register a device from their attendance portal.
-
Did this attempt carry a device assertion?
The browser has to produce a signed response from a credential the employee enrolled. A request without one is refused as unregistered — including a request built by hand against the interface.
-
Does the assertion verify?
The signature is checked against the stored credential and the origin the request came from. Any failure ends the attempt with a message to try again or contact HR.
-
Only now: where are you?
Geofencing, accuracy and any required site code are evaluated after the device has proved itself, not instead of it.
One gate, two doors
There are two ways an employee reaches the clock: a public portal that needs no login, for the majority of staff who have no user account, and the signed-in attendance page for those who do. Both call the same verification, in the same order, with the same refusals. That is worth stating because a gate on one door and not the other is the usual shape of this failure — and it is invisible from either door.
Why a device rather than a password
The credential enrolled is a device-bound key, unlocked by whatever the phone or laptop uses to unlock itself — a fingerprint, a face, a device passcode. Three properties follow, and all three are the reason this is worth the enrolment friction.
- It cannot be typed, so it cannot be dictated over the phone. The single most common way a clock-in gets faked is a colleague reading out a code. There is nothing to read out.
- It never leaves the device. The private half of the credential stays in the phone's secure hardware; the server holds only the public half and a record of which employee enrolled it. A stolen database contains nothing that can clock anyone in.
- The biometric is never sent anywhere. The fingerprint or face unlocks the device, and the device signs. No image, template or measurement reaches the server, which is what keeps this out of the territory of biometric data collection entirely.
The server never learns what the phone asked for. Only that the phone was satisfied.
What a refusal costs, and why it is still right
The honest objection to this design is the new starter at six in the morning with a flat phone. They cannot clock in, and no supervisor can wave them through from the app. What happens instead is that the day gets recorded as a correction: the employee files a regularisation naming the times, and somebody with authority approves it. The hour is still paid. What changes is that there is now a named approver on the record rather than an unverified punch.
A new employee has not enrolled yet
Enrol on their first shift, not their first week
Enrolment takes under a minute on the employee's own phone and enables verification automatically. Make it part of the same conversation as the uniform and the locker key.
Somebody has lost or replaced their phone
They enrol the new one; the old credential is revoked
Credentials are per device, so a replaced phone is a new registration rather than a recovery. Revoking the old one is the step that matters and is worth doing the same day.
An employee genuinely has no smartphone
A shared kiosk at the site
A site can run a kiosk screen displaying a rotating code. The employee still needs a device to sign with, so where nobody has one, corrections are the honest route and the approval trail is the control.
Verification is causing more corrections than punches
Look at the refusal log before changing the policy
Every refused attempt is recorded with its reason, its distance from the site and the accuracy of the location reading. That log usually names the actual problem, and it is rarely the one people assume.
The part that is not negotiable by the client
Location is computed on the server from the coordinates submitted, and the distance from each assigned site is worked out there. Nothing that arrives from the browser saying "I am within range" is believed, because a value the client calculates is a value the client can choose. The device assertion and any site code are additional independent factors rather than substitutes for that calculation — passing one does not excuse another.
Five questions to ask any attendance vendor
Can an employee clock in without enrolling anything?
A good answer sounds like
No, and here is the refusal.
What ours actually is
No. Verification is mandatory, and an unenrolled employee is refused with an instruction rather than warned and let through.
Is the check the same on every route in?
A good answer sounds like
One implementation, named.
What ours actually is
One service, called by both the public no-login portal and the signed-in page, in the same order with the same refusals.
Where is the biometric stored?
A good answer sounds like
On the device, never sent.
What ours actually is
On the device. The server holds a public key and a link to the employee, and never sees a fingerprint or a face.
Who decides whether the employee is on site?
A good answer sounds like
The server.
What ours actually is
The server, from submitted coordinates, against the site's stored position and radius. A client-side verdict is never trusted.
What happens to a refused attempt?
A good answer sounds like
It is recorded.
What ours actually is
A row per attempt, pass or fail, carrying the employee, the event, the site, the coordinates, the accuracy, the distance, whether a code was scanned, which credential signed and the reason it failed.
Around the edges of enrolment
The gate itself is settled. What organisations ask for next is almost always about the people who cannot pass it easily, and those are contained pieces rather than changes to the model.
A supervised enrolment mode
A named supervisor enrolling a device on behalf of an employee, recorded as such, for onboarding sessions where a queue of new starters is being set up at once.
A shared site device
A tablet at the gate that identifies the employee first and asks their own credential second, for workforces where personal phones are rare.
Self-service credential replacement
A guarded path for an employee whose phone was lost, so a replacement enrolment does not need an administrator on a Sunday.
We publish scope, not dates.
Scope attendance enrolmentWhat AWRA OpsHub does today
- Mandatory device verification on every clock-in and clock-out, enabled automatically when an employee registers their first device and switchable off per employee by HR.
- One verification service in front of both the public no-login attendance portal and the signed-in attendance page, so the two routes cannot drift apart.
- Device-bound credentials whose private half never leaves the phone, with the server holding only a public key and the employee it belongs to.
- Server-side distance calculation from submitted coordinates against each assigned site's stored position and radius, with no client-supplied verdict trusted.
- A refusal that names what to do — register a device, move for a better signal, scan the site code — rather than a generic failure.
- A row written for every attempt, successful or refused, carrying the coordinates, the accuracy, the distance, the site, the credential and the reason.
- A correction path for the days a punch could not be made, with the employee stating the times and an approver deciding on them.
More we can add to your workspace
- A supervised enrolment flow, letting a named administrator enrol a device with the employee present and recording that it happened that way.
- A shared site device that identifies the employee first, for workforces where personal phones are not the norm.
- Self-service replacement of a lost credential, guarded well enough to run without an administrator being available.
- A revocation reminder when an employee leaves, so their enrolled credentials are retired alongside their other access.
- A view of enrolment coverage showing which employees have registered a device and which have never clocked in, before the first shift where it matters.
- Offline clock-in on a device with no signal, queued and verified when the connection returns.
Where we point you to a specialist
- We will not build a supervisor override that records a punch as though the employee made it. Where somebody could not clock in, the honest record is a correction with an approver's name on it, and collapsing that into an ordinary punch would remove the only evidence that a human made a judgement.
- Fingerprints and face data stay on the employee's device. We will not collect, transmit or store biometric templates on the server, and an organisation that requires central biometric enrolment is asking for a different category of system with a different set of obligations attached to it.
- Whether attendance may be geofenced at all, and what an employer may record about where staff are, is governed by employment and data protection law where you operate. We will configure the system to whatever your advisers say is permissible; we will not tell you where the line is.
Supervised enrolment and an enrolment coverage view are the two contained pieces, and they solve the same problem from opposite ends — one makes the first registration easier, the other tells you who has not done it yet.
The enrolment conversation is worth having early
Almost every difficulty with verified attendance is an enrolment problem wearing a disguise. If you can tell us the shape of your workforce and what they carry, we can tell you where the friction will land.
Talk through attendanceFrequently asked questions
What happens the first time an employee tries to clock in?
They are refused, with a message telling them to register a device from their attendance portal. Registering takes under a minute and enables verification automatically, so the second attempt succeeds. The refusal is recorded like any other attempt, which means a workspace can see exactly how many people met this wall in their first week.
Does this work on a phone with no fingerprint sensor?
Yes. The credential is unlocked by whatever the device uses to unlock itself, which on an older phone is a passcode or pattern. What matters is that the key is bound to that device and cannot be copied off it, not which unlock method the owner chose.
Can HR clock somebody in on their behalf?
Not as a punch. An administrator can record or amend an attendance day, and an employee can file a correction that an approver decides on — both leave a visible trail naming who did it. What does not exist is a way to produce an ordinary verified punch for somebody who was not there to make it, and that is the point.
What is stored about my staff's biometrics?
Nothing. The fingerprint or face unlocks the phone; the phone then signs a challenge with a key held in its own secure hardware. The server stores the public half of that key and the employee it belongs to. No image, template or measurement of a person is transmitted or held.
If the employee is signed in already, is the device check skipped?
No. Being signed in tells the system who is asking; the device assertion tells it that the person is present at this device now. Both paths into the clock — the public portal and the signed-in page — run the identical check in the identical order.
What if the whole thing is too strict for our situation?
Then start by reading the refusal log rather than by loosening the policy. Every failed attempt records its reason, the distance from the nearest assigned site and the accuracy of the location reading, and in practice the cause is usually one site with a radius set too tight or a group of staff who never enrolled. Both are fixed without weakening the gate.
