Liveness Detection

Liveness detection works by looking for signs that a camera is recording a living face, not a copy of one. The person holds a phone or sits at a computer. The system captures a selfie or a few seconds of video. Software analyses the capture before the face is compared with any identity document.

A copy gives itself away in small ways. A printed photo is flat, with no depth, on paper that reflects light differently from skin. A phone or tablet screen shows a pixel grid, a bright border, glare. A mask does not move like a face. Its edges show around the eyes or the mouth. A living face has depth. It changes with the light, with small movements nobody controls.

The check answers one question: is a real person here now? It does not say who that person is. Face comparison does that, by matching the captured face against the photo in a passport or an identity card. Remote identity verification uses both. A face comparison with no liveness check can be passed with a photo of the right person. A liveness check with no face comparison shows only that somebody is there.

The result is usually a score. The provider sets the point above which a capture passes. An unclear capture can go to a human reviewer, or the person can be asked to try again.

Active liveness detection asks the person to do something. Passive liveness detection asks for nothing beyond looking at the camera. In an active check the screen gives an instruction: turn your head, smile, follow a moving dot, read out some digits. The system checks that the response matches the instruction at the right moment. A photo cannot respond. A recording made earlier cannot know which instruction will come.

A passive check analyses the image or the short video as it is. It looks at texture, depth, reflections and the small movements of a living face. The person may not notice that a check took place. Some methods sit between the two. The screen flashes a sequence of colours, for example, while the software reads how the light reflects off the face. The person does nothing, yet the capture holds a response that could not have been prepared in advance.

The table shows where the two approaches differ. Neither is safer by definition. What counts is how a method performs when it is tested against real attacks.

The two can be combined. A method may run a passive check on every capture, then add an instruction only when the first result is unclear.

Liveness detection stops presentation attacks. A presentation attack shows the camera something other than the living face of the person being verified. ISO/IEC 30107, the international standard on the subject, uses that term. It calls the countermeasure presentation attack detection. Liveness detection is the everyday name for the same thing.

The attacks vary in effort. The simplest is a printed photo held up to the lens. Next comes a photo or a video played on a second phone, a tablet or a laptop. A printed face with the eyes cut out lets the attacker blink through the paper. At the costly end are three-dimensional masks, shaped to resemble one particular person. A deepfake played on a screen that is pointed at the camera is a presentation attack too, because the camera still records a physical object.

The raw material is easy to find. Photos of a person's face are often public, on social media or on an employer's website. A face comparison alone therefore proves little. The liveness step exists to close that gap.

Liveness detection cannot, by itself, detect an image that never passed through the camera. It judges the picture it receives. It assumes that the picture came from a real lens pointed at a real scene. An injection attack breaks that assumption. The attacker replaces the camera feed with a prepared file or a live deepfake, using virtual camera software, an emulator or a tampered app. The system then analyses a clean digital image with no screen glare, no paper edge, no mask.

A well-made deepfake delivered this way can show depth, blinking, natural movement. It may follow an instruction in real time. Analysis of the picture can still find traces of generation, but the stronger defence lies elsewhere. The method has to check that the device is genuine, that the app is unmodified, that the capture came from the physical camera. Liveness detection is one control. Injection attack detection is another. A sound method has both.

Two further limits apply. Liveness detection does not confirm identity. It also cannot tell whether a real person is acting freely. Somebody who has been tricked or pressured into completing a check will pass, because they are real, present, holding their own document.

No EU regulation names liveness detection. The law sets the result a method must achieve. The eIDAS Regulation asks a qualified trust service provider that relies on its own identification method to ensure the identification of the person with a high level of confidence, which a conformity assessment body must confirm (Article 24(1a)(c)). The Anti-Money Laundering Regulation, which applies from 10 July 2027, names the means of verifying a customer's identity without saying how a document is tied to the person who submits it (Article 22(6)). Both sets of rules are set out under remote identity verification.

A method that a photo could pass would not meet the eIDAS test. The technique is left to technical specifications. ETSI TS 119 461 is a technical specification of the European Telecommunications Standards Institute for identity proofing by trust service providers.

A firm that builds its own check from a passport photo with a selfie decides for itself how to tie the two together. It answers for that choice in its risk assessment, where Annex I lists the extent to which a relationship is conducted on a non-face-to-face basis as a risk variable.

Liveness detection is tested by attacking it. A laboratory prepares a set of attack objects: printed photos, screens, masks. It presents each one to the system many times, then records how often an attack is accepted. It also records how often a genuine person is rejected. ISO/IEC 30107 is the international standard that deals with such testing.

Both figures count. A system tuned to refuse every attack will turn away more real people, who then give up or need help. A system tuned for convenience lets more attacks through. One headline figure hides this trade-off, so a buyer should ask for both error rates from the same test.

The conditions of the test count as much. Results depend on the attack types included, the phones used, the lighting, the range of people who took part. A method should work as well for one person as for the next, whatever their age or skin tone, with or without glasses or a head covering. A report from an independent laboratory says more than a provider's own claim.

A firm that is choosing a provider can ask four things. Which laboratory tested the method, against which standard? Which attack types did the test include? What share of genuine users was rejected? Was the method also assessed for injected video?

In an identity check, the safe assumption is yes. The GDPR defines biometric data as personal data resulting from specific technical processing of a person's physical, physiological or behavioural characteristics, which allow or confirm the unique identification of that person. Facial images are named as an example (Article 4(14)). A liveness check taken alone decides whether a face is real, not whose it is. In an identity check, though, it runs on the same capture as the face comparison, which does confirm identity.

Processing biometric data for the purpose of uniquely identifying a person is prohibited unless an exception applies (Article 9(1)). Explicit consent is one exception. Others rest on Union or member state law. Member states may add conditions of their own for biometric data (Article 9(4)). A data protection impact assessment is required before processing that is likely to result in a high risk, in particular where new technologies are used (Article 35(1)).

Automatic rejection raises a further point. A person has the right not to be subject to a decision based solely on automated processing which produces legal effects for them or similarly significantly affects them (Article 22(1)). Such a decision may be based on special category data, which includes biometric data used to identify a person, only where the person has given explicit consent or a substantial public interest laid down in law applies, with suitable safeguards in place (Article 22(4)). Where an automated decision is allowed because it is necessary for a contract or rests on explicit consent, the person keeps the right to obtain human intervention (Article 22(3)). A failed liveness check that blocks access to a service, with no route to a human reviewer, should be measured against that rule.