Straight answer: yes, an employee can refuse biometric attendance in India. Under the DPDP Act, biometric data needs informed consent, so an employer cannot make fingerprint or face enrolment the only way to be marked present. A lawful fallback — a card, a PIN, or a supervised manual entry — has to exist, and refusal should never itself be treated as misconduct.
This comes up more often than most HR teams expect. Someone objects to fingerprint scanning on religious or personal grounds. A new joiner asks what happens to their face data if they leave. A union raises it during a rollout. The instinct is to treat it as a discipline problem. It isn't.
Why can an employee say no?
Biometric identifiers — fingerprints, face templates, iris scans — are classified as personal data requiring consent under the DPDP Act, 2023. Consent has to be free, meaning it can't be a condition of continuing employment when a reasonable alternative exists. If your attendance policy has no fallback, the "consent" you're collecting isn't really consent — it's compliance under threat of being marked absent, and that's the version that creates legal exposure, not the refusal itself.
This is a general description of how consent works under the Act; rules and enforcement practice can differ by sector and state, and this isn't legal advice — check the specifics with a compliance advisor before writing policy.
What should the fallback actually look like?
Keep it boring and equivalent, not punitive:
- A physical card or fob tapped at the same gate reader. No biometric captured, same timestamp granularity.
- A PIN entered at the terminal, tied to the employee's ID rather than a shared code.
- A supervisor-witnessed manual entry, logged in the same system so it shows up in the same reports rather than a separate paper trail nobody reconciles.
The test for whether a fallback is genuine: does it produce a comparable, auditable record, and is it available to anyone who asks — not just the one person who complained? A fallback that's harder to use than the biometric system, or that visibly singles someone out, defeats the point.
Why is forcing it the wrong fight?
Two reasons, and neither is really about legal risk.
First, coerced enrolment produces bad data. Someone who resents scanning their finger will find ways to make the scan fail, badly angle their face at the camera, or simply stop cooperating — and now you have a data quality problem layered on top of the original objection.
Second, the actual goal was never "everyone must be biometrically enrolled." It was "we need to know who's on site and when." A fallback that answers that question honestly gets you the outcome without the standoff. Spending management time arguing about the credential, instead of the underlying attendance number, is a fight you don't need to have.
Does this undermine the whole system?
Not if refusals stay rare, which they usually do once people see the fallback works the same way for everyone. If refusals become common at a site, that's worth investigating as a trust problem — people are often reacting to how enrolment data is stored and who can see it, not to biometrics as a concept. Being specific about retention (see our companion post on what to keep and delete) tends to resolve more objections than any policy memo does.
Where does face recognition fit into this?
We build face-recognition attendance systems, so weigh the following with that in mind. Face recognition on entrance cameras is enrolment the same way a fingerprint scanner is — it needs the same consent step and the same fallback. Where it differs from a fingerprint reader is that a poorly explained camera rollout tends to generate more anxiety than a scanner does, purely because people can see the camera all day, not just at the gate. A short, plain-language notice at enrolment — what's captured, what it's used for, how long it's kept — heads off most of the objections before they start.
The honest limitation: no attendance system, biometric or not, eliminates the need for a human process when someone genuinely can't or won't use the primary method. Budget for that from day one rather than treating it as an edge case discovered mid-rollout.