Every biometric attendance vendor says their system has liveness detection. Almost none of them say what that means, how it was tested, or against what. There is an international standard that answers those questions — ISO/IEC 30107 — and knowing how to reference it turns a vague marketing claim into something you can actually evaluate.
This guide explains what presentation attack detection is, what the standard covers, and the questions that separate a tested system from an assertion.
The problem: a photo is not a person
A face recognition system without anti-spoofing will happily match a photograph held up to the camera. So will a phone screen showing a video, and in some cases a printed mask. For attendance this is not a theoretical vulnerability — it is buddy punching reinvented. If one employee can clock in a colleague with a photo on their phone, the biometric system has added cost without adding assurance.
The technical term for such an attempt is a presentation attack: presenting an artefact to the sensor to interfere with correct recognition. The countermeasure is presentation attack detection, or PAD — what the market usually calls liveness detection.
What ISO/IEC 30107 actually covers
The standard comes in parts. The two that matter to a buyer:
- Part 1 sets out the framework — terminology, the categories of attack, and where in the system detection can sit.
- Part 3 defines testing and reporting: how to evaluate a PAD mechanism and how to express the results so they can be compared.
Part 3 is the one to ask about. A vendor saying “we have liveness” is making a claim; a vendor saying “our PAD has been evaluated to ISO/IEC 30107-3 by an independent laboratory, and here is the report” is making a testable statement. The difference matters because PAD evaluation is genuinely difficult to self-assess — it depends entirely on which attack instruments were used.
The two error rates to ask for
PAD testing produces two figures that trade off against each other:
- APCER — attack presentation classification error rate. The proportion of attacks wrongly accepted as genuine. Lower is more secure.
- BPCER — bona fide presentation classification error rate. The proportion of genuine people wrongly rejected as attacks. Lower is more usable.
You cannot minimise both at once, and this is the crux of the buying decision. A system tuned for maximum security rejects tired employees in bad lighting at 6am; one tuned for convenience accepts a photograph. Ask where the operating point sits, and whether it is configurable per site — a bank’s headquarters and a farm’s field crew are not the same risk.
Also ask which attack instruments were tested: printed photographs at what resolution, phone and tablet screens, printed cut-out masks, silicone masks, video replay. A PAD result is meaningless without the list. Detecting printed photos is easy; detecting a high-quality replay on a bright OLED screen is not.
Active versus passive detection
Active PAD asks the user to do something: blink, turn their head, follow a dot. It is effective and easy to explain, but it adds seconds to every check-in and irritates people at shift change. Multiply three seconds by four hundred employees twice a day and it becomes an operational cost.
Passive PAD analyses the captured image for the signatures of a spoof — texture, reflection, depth cues, moiré patterns from screens — without asking anything of the user. Check-in stays a single glance. Most modern attendance deployments prefer passive detection for throughput, sometimes with active challenge as a fallback for borderline cases.
A third option, where hardware allows, is using additional sensing — infrared or depth cameras — which raises the bar considerably but constrains which devices can serve as check-in points.
Where detection runs matters
PAD that executes on the device rejects the spoof before any record is created, and keeps working when the network is down. Server-side detection can be more computationally generous but depends on connectivity and sends the capture off the device first.
For attendance, on-device detection is generally the better architecture: remote sites keep working offline, and nothing leaves the device unless it passed. See how the architecture fits together.
Testing it yourself in five minutes
You do not need a laboratory to catch the worst systems. During any demo or trial:
- Enrol yourself, then hold up a printed photograph of your face.
- Hold up your phone displaying that photograph at full brightness.
- Play a short video of yourself on the phone and present it.
- Try in poor lighting, then in direct sunlight — many systems fail bona fide users here rather than failing attacks.
- Try with a mask, safety glasses and a hard hat if your people wear them.
Steps one to three test security; steps four and five test whether your workforce will actually be able to clock in. Both failure modes end the same way — a supervisor keeping a paper override sheet.
Why algorithm provenance matters here
Many attendance applications license a recognition SDK and have limited visibility into its anti-spoofing behaviour. Vendors who develop their own algorithms can answer detailed questions about PAD design, testing and configuration, and can tune the operating point for your environment. Ask who wrote the engine — it is the shortest route to knowing whether the answers you are getting are informed. See why algorithm provenance matters.
Frequently asked questions
Is liveness detection the same as 3D face recognition?
No. Depth sensing is one technique that can support PAD, but passive PAD on a standard 2D camera is widely used and avoids constraining device choice.
Can PAD be defeated?
Any security control can be defeated with enough effort. The realistic question is whether it defeats the attacks your workforce would plausibly attempt — a colleague with a phone photo, not a funded adversary with a silicone mask.
Does anti-spoofing slow down check-in?
Passive detection adds negligible time. Active challenge-response adds seconds per person, which matters at shift change.
Should PAD settings differ by site?
Often yes. A secure vault and a canteen door justify different operating points. Ask whether the system allows per-site configuration — see access control.
Matching the operating point to the risk
Because APCER and BPCER trade off, the right setting is a policy decision rather than a technical default — and it should differ across a single organisation.
Low-risk, high-throughput points such as a canteen door or a general office entrance justify a setting that favours usability. A false rejection here is an inconvenience; the consequence of a rare successful spoof is an incorrect timesheet entry that other controls will catch.
High-assurance points — server rooms, vaults, controlled substance stores, restricted zones — justify the opposite. A false rejection is an inconvenience; a false acceptance is a security incident. Here a stricter threshold, or a second modality, is proportionate.
Payroll-critical points sit in between and are the most common case. The practical approach is to start moderately strict, measure the false rejection rate over two weeks, and relax only if genuine users are being rejected at a rate that generates manual overrides — because manual overrides are themselves a control failure.
Ask whether the product supports per-site or per-device configuration. A single global setting forces you to choose between frustrating the canteen queue and under-protecting the vault.
What to monitor after go-live
- Rejection rate by location. A single site with a much higher rate usually indicates lighting or camera placement, not a software problem — and it is fixable in an afternoon.
- Rejection rate by individual. A handful of people failing repeatedly suggests an enrolment quality issue. Re-enrol them rather than letting them default to manual entry permanently.
- Manual override volume. The clearest single health metric. Rising overrides mean people are routing around the system.
- Detected attack attempts. If the system logs them, review periodically. A cluster at one site is worth a conversation.
These four numbers, reviewed monthly for the first quarter, will tell you more about whether the deployment is working than any vendor report.
NCheck is a biometric attendance system by Neurotechnology that runs on-premises or in the cloud, supports face, fingerprint and iris recognition, and works on phones, tablets, IP cameras and biometric terminals. Free forever for up to 5 employees.
