Face attendance that runs on the device.
Employees enrol once, then punch with their face. Recognition happens in the browser — the photo becomes a mathematical descriptor before it goes anywhere — and the server decides whether the punch is allowed.
What you can do
Built for the way HR actually works.
Enrol once, punch with your face
A guided capture enrols an employee's face, and every later punch is matched against it. No card to lose and no shared PIN to pass around.
Matching runs in the browser
Detection, alignment and embedding all happen on the device. What travels is a numeric descriptor, not a face waiting to be matched somewhere else.
The server decides, not the client
In hard mode the descriptor is evaluated server-side and the punch is refused before it is ever created. The block is the source of truth; the browser only mirrors it.
Hard or soft, per configuration
Hard mode blocks a failed match. Soft mode records the result and lets the punch through, so you can roll it out and watch before you enforce it.
Selfies expire on a schedule
Stored face-check selfies are purged after a configurable retention window — 90 days by default — while the result metadata is kept.
Warmed up before the queue forms
The recognition models are pre-warmed, so the first punch of the morning is not the one that waits for a download.
ON-DEVICE
The face becomes a number before it travels
- Detection and 478-point landmarking run locally in the browser
- The aligned crop is embedded on-device into a 128-dimension descriptor
- Every descriptor is tagged with the model version that produced it, so only like is ever compared with like
ENFORCEMENT
Roll it out in soft mode, then turn it on
- Soft mode records the outcome and lets the punch proceed
- Hard mode refuses the punch server-side when the face does not match
- Devices that cannot do face capture are never blocked by the face rule
Who can see what
Activity log
Frequently Asked Questions
It is real recognition. An employee enrols their face once, and each later punch is converted into a numeric descriptor and matched against that enrolment. A selfie-only system stores a photo for someone to look at later; this one decides whether the punch is allowed.
The matching descriptor is computed in the browser — detection, alignment and embedding all run on the device — so what is sent for comparison is a 128-dimension vector rather than an image awaiting recognition.
No. There is no liveness or anti-spoofing check today, so face attendance verifies identity against an enrolment rather than proving a live person is present. Where that distinction matters, pair it with geofencing or an on-site device rather than relying on the face check alone.
It depends on the configured mode. In hard mode the punch is refused server-side before it is created. In soft mode the result is recorded and the punch proceeds, which is the sensible setting while you are rolling the feature out.
Stored face-check selfies are deleted after a configurable retention window, 90 days by default, by a scheduled purge. The result metadata — whether the check passed — is retained after the image itself is gone.
Yes. Face checking is part of the punch configuration rather than a company-wide switch, so it can be applied where it makes sense — a shop floor or a site entrance — while other teams punch normally.
Works with the rest of SignHR