Liveness Detection: How Systems Tell a Real Face From a Replay

A face match can show that a captured image resembles the portrait on an identity document or an enrolled account. It cannot, by itself, show that the account holder is present. That gap is the job of liveness detection, a set of techniques intended to determine whether a camera is seeing a real person at the time of a check rather than a photograph, screen replay, mask or synthetic image.

The distinction matters in remote account opening, age assurance, recovery and high risk transactions. Fraudsters can obtain face images from social media, breached databases and legitimate video calls. Generative AI has also made it easier to create convincing face video. But liveness is only one control in an identity verification workflow. It does not establish a person's legal identity, nor does it by itself secure the path between a user device and a verification service.

What liveness checks are looking for

The most familiar approach is active liveness. The application asks a user to perform an action, such as turning their head, blinking, smiling or following a moving dot. The system checks whether the face responds in the expected way and whether the response is synchronized with the prompt. A prerecorded video may contain a blink or head movement, but it is less likely to produce the requested action at the requested moment.

Passive liveness seeks to make that judgment without asking the user to do anything unusual. It analyzes a capture, or in some designs a brief capture sequence, for signs associated with a real face. Those may include three dimensional facial geometry, skin texture, lighting and reflections, image sharpness, camera noise, and artifacts created when a display or printed image is photographed. Some systems use infrared or depth-capable sensors when compatible hardware is available; others work with an ordinary phone camera.

Neither label describes a single method or guarantees a result. Active prompts can be defeated by sophisticated media and can be difficult for some users. Passive systems can reduce friction, but their assessment depends heavily on image quality, lighting, device cameras and the types of spoofs represented in their training and evaluation. A carefully made mask, high quality display replay or altered live video can challenge different systems in different ways.

Presentation attacks are not the same as injection attacks

Standards and testing programs commonly call a physical spoof shown to a camera a presentation attack. Examples include a printed portrait, a face displayed on another phone, a video replay, a three dimensional mask or a manipulated image presented through a camera. Presentation attack detection, often shortened to PAD, evaluates whether the capture appears to come from a genuine human presentation rather than such an artifact.

An injection attack occurs elsewhere in the chain. Instead of holding a replay in front of the camera, an attacker may try to feed a prerecorded video, a virtual camera output or digitally generated frames directly into an application or network session. Because the liveness engine may receive what looks like a clean camera image, visual spoof detection alone may not reveal how that image entered the system.

• Presentation attack controls examine what the camera appears to see, including prints, screens, masks and other physical artifacts.
• Injection defenses protect the capture path through measures such as app and device integrity checks, session binding, authenticated camera access, server-side validation and detection of tampering or virtual-camera behavior.
• Face matching, document verification, liveness and capture-path security address related but distinct risks. A strong result in one does not substitute for the others.

How performance is measured

Liveness claims are most useful when tied to transparent testing. ISO/IEC 30107-3 is a widely referenced framework for evaluating presentation attack detection. Evaluations typically report the share of attacks incorrectly accepted, often called the attack presentation classification error rate, and the share of genuine users incorrectly rejected, called the bona fide presentation classification error rate. The terms and exact protocols matter: an impressive result against printed photos may say little about masks, screen replays or a newly emerging attack type.

Independent testing should state the attack instruments used, image and sensor conditions, participant diversity, sample sizes and whether testing reflects deployment conditions. It should also separate presentation-attack results from injection resistance. Operational performance can differ from a laboratory result because real users have low light, older devices, unstable connections, glasses, face coverings or camera lenses affected by dirt and glare.

Security must not become an exclusion test

Prompted checks introduce particular accessibility concerns. A person may be unable to turn their head, blink on command, hold a device steady, follow a visual target or understand an instruction delivered in an unfamiliar language. Neurological conditions, tremors, vision differences and temporary injuries can also affect completion. Repeated failure can leave a legitimate customer without access to a bank, employer, public service or online marketplace.

Fairness requires measurement as well as intent. Developers and deploying organizations should examine false rejection rates across age groups, skin tones, genders, disabilities, devices and lighting conditions, while handling sensitive demographic data lawfully and carefully. Clear instructions, reasonable retry limits, accessible alternatives and trained human review can reduce harm. The central test is practical: a liveness system should make fraud materially harder without treating ordinary variation in human faces, movement or equipment as evidence of fraud.