Enrolment: the system stores a descriptor, not your photograph

The first thing most HR managers get wrong about face attendance is what the system actually keeps. A well-designed face recognition attendance system does not compare today's selfie against a folder of employee photos. During enrolment, the software detects the face, aligns it (eyes level, nose centred), and passes the cropped image through a neural network that outputs a long list of numbers, usually 128 to 512 of them. That list is the face descriptor, also called an embedding or template.

The descriptor is a mathematical summary of the geometry and texture of the face. It cannot be reversed into a recognisable picture, and two descriptors of the same person taken on different days land close to each other in that number space while descriptors of different people land far apart. Good systems encrypt the descriptor at rest and discard the enrolment photo, or keep it only for a supervisor to confirm the enrolment was of the right person.

Enrolment quality decides everything downstream. If a supervisor enrols 40 housekeeping staff in a dim corridor with half of them wearing caps, the descriptors will be noisy and the system will reject those people at the gate for weeks. Enrol in even lighting, without headwear or sunglasses, and capture two or three angles where the app allows it. Record who performed the enrolment and when; that log is your evidence if a worker later claims someone else was enrolled under their name.

• Enrol in daylight or under even indoor light, face uncovered, no cap or dark glasses
• Confirm the employee's identity against a government ID before saving the descriptor
• Ask the vendor in writing whether photos are deleted after the descriptor is created
• Keep an enrolment log: who enrolled whom, on which device, at what time

Matching: similarity scores and the threshold you never see

When an employee marks attendance, the app computes a fresh descriptor from the live frame and measures its distance from the stored one. The result is a similarity score, often expressed as a percentage or a distance value. The system does not know for certain that it is the same person; it only knows the two descriptors are close enough to cross a threshold the vendor has set. Everything above the threshold is a match, everything below is a rejection.

There are two matching modes and they behave very differently at scale. Verification (1:1) asks 'is this person who they claim to be?' because the employee has already logged in on their own phone. Identification (1:N) asks 'who among the 300 enrolled people is this?' because a shared tablet at the gate has no idea who is standing in front of it. Identification gets harder as N grows, because more enrolled faces means more chances of two descriptors sitting close together, and that is why a factory gate terminal serving 1,500 workers needs a stricter threshold than a phone app used by one person.

For attendance purposes you rarely need to tune the threshold yourself, but you should know it exists. If your vendor allows a per-company setting, tighten it for kiosk mode and loosen it slightly for personal-phone selfie verification where the login already establishes identity. Read the face recognition attendance glossary entry for the terms vendors use in their specification sheets.

• 1:1 verification on a personal phone is more forgiving than 1:N identification on a shared kiosk
• The threshold is a business decision: stricter for high-value payroll, looser for convenience
• Ask whether the score for each punch is stored, so disputed punches can be reviewed

Liveness detection: why a printed photo fails

Matching alone would be trivially defeated by holding up a colleague's photograph or a video on a second phone. Liveness detection is the layer that decides whether a real, present human is in front of the camera. Passive liveness analyses the single frame for signs of a flat surface: printing dots, screen moire patterns, unnatural reflections, missing skin texture and the absence of micro-movement between consecutive frames. Active liveness asks the user to do something, such as blink, turn the head or follow a dot, and checks that the face responds in three dimensions.

A printed photo fails because it has no depth, does not blink and reflects light as one plane. A video on a phone fails because the screen produces a grid pattern under camera zoom and its brightness does not match the ambient light. A well-made 3D mask is much harder, which is why some hardware terminals add an infrared or structured-light depth sensor. For most Indian workplaces the realistic threat is the photo or video replay, not a Hollywood mask, and phone-based passive plus active liveness handles that threat well.

Liveness is what separates a face attendance app from a glorified selfie camera. If you are evaluating vendors, ask them to demonstrate a failed attempt with a printed photo and a phone video of an enrolled employee. If both are accepted, the product is not solving the proxy-attendance problem you bought it for. The liveness detection glossary entry covers the active and passive approaches in more detail.

• Test every vendor with a printed photo and a phone video replay before signing
• Prefer passive liveness for speed at a busy gate; add active checks for high-risk roles
• Understand that liveness adds a second or two per punch; plan gate throughput accordingly

On-device versus cloud matching

Where the matching happens affects speed, privacy and offline behaviour. On-device matching runs the neural network on the phone or terminal and only sends the result (matched, score, time, location) to the server. It works without internet, is fast, and means raw face frames never leave the device. Cloud matching uploads the frame or the freshly computed descriptor to a server that holds the enrolled templates and returns a verdict.

Cloud matching is easier to update and lets a company use one enrolment across every device. Its weakness is connectivity: a construction site or a basement security post with poor signal will queue punches or fail outright. Hybrid designs compute the descriptor on the device, compare against a cached copy of the relevant templates, and sync when the network returns. For a workforce spread across sites with unreliable data, insist on offline capture with later sync; a punch that cannot be made is a punch that becomes a regularization request and a payroll argument.

From a data-protection viewpoint, on-device or descriptor-only processing is the more defensible design because the least sensitive form of the data travels over the network. Whichever model your vendor uses, the contract should state where the templates are stored, whether they are encrypted, and who at the vendor can access them.

• Ask whether the app can capture attendance offline and sync later
• Prefer designs that transmit descriptors or verdicts rather than raw images
• Confirm server location and encryption of stored templates in the contract

Low light, masks, beards and ageing: when to re-enrol

Modern face models are robust to a lot: a new beard, spectacles, a haircut, and normal ageing over two or three years usually stay within the threshold. What breaks them is a combination of changes plus poor capture conditions. A guard enrolled clean-shaven in April who now has a full beard, is wearing a monsoon hood, and is standing under a sodium lamp at 21:00 will produce a descriptor far from the stored one. The system will reject him, and he will be marked late through no fault of his own.

Face masks hide the lower half of the face, which carries a large share of the distinguishing features. Some models are trained to match on the eye and forehead region, but accuracy drops noticeably. If your workplace requires masks (pharma clean rooms, food processing, hospital wards), either enrol with the mask on as a second template or place the attendance point before the mask-on zone. Turbans and hijabs are generally fine because the face itself is visible; only coverings that hide the nose or eyes create problems.

Set a re-enrolment rule instead of waiting for complaints. A practical policy is to allow any employee to request re-enrolment through their manager, and to prompt re-enrolment automatically when someone has three consecutive rejections or their average match score drifts downward over a month. Re-enrolment should be logged like the original enrolment and should replace, not accumulate, old templates.

• Allow employee-initiated re-enrolment via manager approval; do not make workers beg
• Trigger re-enrolment on repeated rejections or a falling average match score
• Improve lighting at the punch point before blaming the algorithm
• For mask-mandatory areas, enrol a masked template or move the punch point outside

Accuracy trade-offs: false accepts versus false rejects

Every face recognition attendance system balances two errors. A false accept lets the wrong person through, which in attendance terms means proxy punching and wage theft. A false reject blocks the right person, which means queues, angry workers and a flood of regularization requests. Tightening the threshold reduces false accepts and increases false rejects; loosening it does the opposite. There is no setting that eliminates both.

Think about what each error costs in your context. At a security agency, a false accept means a client is billed for a guard who was not at the post, which can cost the contract. At a small office, a false accept between two staff is unlikely and the bigger cost is the receptionist spending ten minutes daily fixing rejected punches. A garment unit with 800 workers and a 15-minute gate window cannot tolerate a 5% reject rate because that is 40 people queueing at the HR desk every morning.

Measure the reject rate for the first month and publish it internally. A healthy deployment in a phone-based 1:1 setup sees very few rejections once enrolment issues are fixed. If rejections cluster around one device, one lighting condition or one group of employees, the fix is operational, not algorithmic. The guide to stopping buddy punching explains how face verification fits alongside other anti-proxy controls rather than being the only one.

• Decide which error is more expensive for you before touching the threshold
• Track rejection rate by device, site and shift during the first month
• Treat clustered rejections as a lighting or enrolment problem, not a software failure

Privacy, DPDP, and choosing between terminals, phone apps and layered GPS

Under the Digital Personal Data Protection Act 2023, a face descriptor is personal data and its use for attendance requires a lawful basis, a clear notice, purpose limitation and reasonable security. In practice that means a written notice at enrolment stating that the descriptor will be used only to record attendance, how long it will be kept after the employee leaves, and who can access it. Keep templates encrypted, restrict access to named HR roles, and delete them within a defined period after exit. Do not reuse attendance templates for CCTV analytics or any other purpose without a separate notice. For the wider legal picture, including location data, see is employee GPS tracking legal in India.

Hardware face terminals suit a single gate with heavy footfall where workers do not carry smartphones: they are fast, wall-mounted, and can include depth sensors. Phone-based face apps suit distributed teams, field staff, security guards and contract labour across many sites, because there is no device to install per location. A face match on a phone proves who punched but not where; that is why field and multi-site deployments layer a GPS fix and a geofence on top, so the record reads 'this person, at this site, at this time'. The selfie attendance app approach is exactly this pairing.

Attend Mitra's face attendance stores encrypted face descriptors rather than photographs, runs a liveness check on each punch, and lets you combine face with GPS, geofencing per site and mock-location flagging on Android in a single policy. Rejections can be corrected through an approval-based regularization flow with a full audit trail. For a side-by-side of face against fingerprint and GPS-only approaches, read biometric, GPS and face attendance compared, and for the terminal-versus-app decision see attendance machine versus attendance app.

• Issue a written DPDP notice at enrolment: purpose, retention, access, deletion on exit
• Use terminals for single high-footfall gates; use phone apps for multi-site and field teams
• Layer GPS and geofencing on face for any role where location matters to pay or billing
• Never repurpose attendance templates for surveillance without a fresh notice and basis