A face-matching model may correctly recognize the face printed on a photograph. That is not a flaw in the idea of recognition: it is an important reminder that identity similarity and evidence of a live, present person are different questions. In unattended onboarding, employee check-in, digital services and shared devices, a product often needs both.
Liveness detection is the industry-friendly phrase for evaluating whether a face capture appears to come from a live person. The more precise security discipline is presentation attack detection (PAD): identifying attempts to fool a biometric capture system with a presentation artifact or other attack presentation. The two terms overlap in product conversations, but neither should be sold as a guarantee against all spoofing.
Conceptual illustration, not a live SDK result or independent performance claim.
What a presentation attack looks like
A simple attack might present a printed portrait or another screen playing a person's video to a camera. More sophisticated attempts could involve masks or carefully controlled display and lighting conditions. Different attacks leave different artifacts; a PAD model that handles one instrument well may behave differently on another.
A separate class of attacks is digital injection, where an attacker attempts to bypass or replace the camera stream inside software. Presentation attack detection evaluated at the camera is not, by itself, a full defense against an injected feed. App integrity, trusted capture paths and API authentication need to be considered as separate system controls.
The ISO/IEC 30107 family provides terminology and evaluation principles for PAD. It does not define a single universal anti-spoofing algorithm or certify every possible application threat model.
Illustrative architecture; PAD and identity similarity are deliberately shown as distinct signals.
Passive versus active liveness checks
Passive PAD analyzes available image or video evidence without requiring a prescribed action from the user. Depending on the system, it may assess visual texture, material artifacts, temporal inconsistencies or other signals. Its attraction is a convenient capture flow: the person simply looks at the device.
Active or challenge-response PAD asks the user to perform an action or respond to a dynamic instruction. Head movement, orientation changes and other prompted interactions may supply additional evidence, although a blink or turn alone is not proof of liveness. Challenges also introduce accessibility considerations, extra latency and new replay or automation threats.
| Question | Passive PAD | Active challenge-response |
|---|---|---|
| Typical user experience | Little or no extra instruction | Explicit action or interaction |
| Common product advantage | Low-friction UX | Additional interaction evidence |
| Engineering risks | Capture quality, domain shift, unseen attacks | Replay resistance, accessibility, timeout handling |
| Good fit | Frequent approved authentication | Selected step-up or higher-risk flows |
Neither is always superior. Use the simplest design that meets the actual threat model and tested security requirements.
Five useful application patterns
1. Remote account onboarding. A face capture can be checked for presentation risk before or alongside a 1:1 comparison to an approved enrollment or ID portrait. PAD is only one component: document authenticity, legal identity checks and KYC decision-making belong to the wider onboarding platform.
2. Mobile employee check-in. A check-in app can evaluate whether the captured face is plausible as a live presentation rather than only similar to an enrolled employee. The experience should stay lightweight, and failures due to glare, darkness or low-quality cameras should have sensible retry guidance.
3. Self-service kiosks. A partner's tablet-based check-in or membership station may be unattended during busy hours. Passive capture and clear user positioning can help, while policies decide when a second factor or staff review is warranted. The kiosk can be an ordinary phone or tablet on a stand or wall mount; it need not be a bulky dedicated biometric terminal.
4. Sensitive account actions. A platform may add PAD to step-up face verification before changing payment details or recovering a high-value account. This must remain part of a broader security process; a face check is not a replacement for all authentication, authorization and transaction controls.
5. Remote exam identity checks. A consenting examinee may undergo an initial identity verification and occasional checks under published rules. Poor PAD confidence, camera outages or head movement must not by themselves be treated as misconduct. Human review and an accessible alternative are essential.
Avoid treating one score as the answer
A PAD risk score expresses the output of a particular model under its own testing conditions. A face similarity score expresses identity-related resemblance. Neither has an automatic shared scale. Combining them by simply averaging two floating-point values is usually not a meaningful policy.
Define separate quality gates, PAD thresholds and matching thresholds. Collect evidence of false rejection and false acceptance across the presentation attack instruments, devices and demographic or environmental conditions that matter to your deployment. Consider APCER and BPCER in PAD evaluation, and keep their test conditions attached to any reported results. Real-world acceptance decisions should allow an explicit uncertain state.
Engineering the flow for everyday users
Liveness quality depends on capture quality. Explain camera positioning in plain language, limit retries to prevent abuse, and avoid requesting needless movement when passive evidence is adequate. Test glasses, varied lighting, low-end devices, background screens and users who cannot complete a particular gesture.
If a model struggles, the host application should know whether to recapture, offer another verified method or enter manual review. Retain only the biometric material and audit records that are necessary for a defined purpose, with appropriate consent, access controls and deletion processes.
AttFace Core as a PAD building block
AttFace Core includes face-processing and liveness components that partners can integrate into their own applications, within the supported SDK and deployment scope. The partner must still select its threat model and validate the operating point. Describing anti-spoofing as an additional defensive layer is both technically stronger and more credible than calling it impossible to bypass.
Building a product where a photo or replay could defeat a basic face match? See AttFace Core and talk to AIPractix about evaluating liveness within your complete verification flow.
