Facial clocking and buddy clocking: an honest look for security companies.

Face recognition, used for facial clocking, makes buddy clocking harder and more traceable. It does not make it impossible, and a vendor who tells you otherwise is describing a product that does not exist.

That is the honest starting point, and everything useful about choosing a clock-in method follows from it.

What each method actually proves

Employee number. Proves somebody knew a number. Numbers are shared in a car park in four seconds.

NFC tag or card. Proves somebody held a tag. Tags are handed over just as easily, and a tag left with a colleague is the oldest arrangement in the industry.

Barcode. Same as a tag. It proves possession of a thing, not presence of a person.

Face recognition. Proves a face matched a stored template to within a confidence threshold. This is genuinely different in kind, because a face cannot be handed to somebody in a car park.

Only the last one is about identity. The first three are about possession, and that distinction is the entire argument.

Why we did not simply make facial clocking mandatory

Because it fails in exactly the conditions guarding happens in.

Poor light at 05:00. Rain on the lens. A guard wearing a beanie pulled low in winter. Dust. A cracked screen protector over the camera. A handset that has been in a pocket and is smeared.

A system that only accepts a face will, on a meaningful number of shifts, refuse to let a legitimate guard start work. What happens next is predictable: the guard phones the supervisor, the supervisor clocks them in manually, and within a month manual override is the normal path. You have then built a system whose main feature is routinely bypassed, and the bypass is undocumented.

Better to have several methods that work reliably and to be honest about what each one proves.

The role of the selfie

This is the compromise that does most of the work.

For the methods that prove possession rather than identity, the handset can require a photograph at the moment of clocking. It does not match anything automatically. It simply puts a picture of whoever was holding the phone into the timesheet row, where a supervisor, or a client, can look at it.

It is weaker than a face match and considerably stronger than nothing. It also has a property face matching lacks: a human can review it later and reach their own conclusion, rather than trusting a score.

The photographs are deleted on a schedule. In Sentry that is 120 days by default and configurable, which matters under POPIA, because a permanent archive of staff photographs is a liability that grows every month nobody looks at it.

The threshold nobody discusses

Face matching produces a confidence score, and somewhere there is a number above which a match is accepted.

Set it high and legitimate guards get rejected in bad light, which drives the manual-override problem above. Set it low and the system accepts matches it should not. There is no setting that eliminates both, and any vendor presenting this as solved has simply chosen a number and not told you.

What you should ask is whether the threshold can be tuned for your operation, and what the vendor's default is optimised for. An operation with well-lit gates and one with rural posts at 04:00 are not the same problem.

What to do about buddy clocking, realistically

The technology reduces it. The rest is operational:

Make the record visible. Buddy clocking survives where nobody looks. Photographs in the timesheet that a supervisor actually reviews change behaviour faster than any matching algorithm.

Pair it with position. A clock-in with a face match and a GPS fix at the right site is a much harder thing to arrange than either alone.

Watch the overrides. Manual clock-ins are where the problem migrates once the front door is harder. If your system does not log who overrode what and why, you have moved the problem rather than solved it.

Related: what a defensible attendance record contains when a client disputes a shift.