Liveness detection is one of those technologies that have accumulated more myths than precise definitions: it’s confused with face recognition, credited with one-hundred-percent protection against forgeries, and sometimes called a mandatory legal requirement, which it isn’t. Yet the technology itself is described precisely enough in an international standard to sort out these misconceptions without much debate.
What Liveness Detection Is, in Simple Terms
Liveness, or liveness detection (sometimes called a liveness check), is a technology that helps determine whether there’s a live person in front of the camera — rather than a photograph, a video recording, a mask, or some other means of imitation. The technology works at the moment of biometric capture: the system isn’t assessing who’s in front of the camera, but whether it’s a live person actually present at the point of capture, rather than a recording, a photograph, or a replay.
What the Standard Says: Liveness and Liveness Detection
The precise definitions come from ISO/IEC 30107-1:2023, the international standard that establishes the framework for presentation attack detection. The standard introduces two related but distinct concepts. Liveness — “quality or state of being alive, made evident by anatomical characteristics, involuntary reactions, physiological functions, voluntary reactions, subject behaviours, or any combination of these.” Liveness detection — “measurement and analysis of anatomical characteristics or involuntary or voluntary reactions in order to determine whether a biometric sample is being captured from a living subject present at the point of capture.”
Alongside these, the standard introduces two more terms needed further on: bona-fide presentation — biometric presentation without the goal of interfering with the operation of the biometric system, and biometric presentation attack — presentation with exactly the opposite goal.
Why Liveness Detection Is Part of a Broader Task
Note 1 to clause 3.3 of the standard states verbatim: “Liveness detection methods are a subset of presentation attack detection methods.” Liveness detection isn’t a synonym for presentation attack detection (PAD) — it’s a part of it: PAD is broader and also covers presentations that don’t reduce to the question “is the subject alive,” such as altered or artificially constructed biometric characteristics.
In most Russian-language materials, including vendor pages, “liveness” and “PAD” are used interchangeably. That’s a simplification rather than an error in everyday use, but the difference matters for a precise discussion of the technology: where the discussion is specifically about detecting live presence, it’s correct to talk about liveness detection; where it’s about detecting presentation attacks in general, including cases that don’t reduce to liveness, it’s PAD.
How Liveness Detection Differs From Face Recognition
This is the second distinction without which a discussion of liveness detection quickly turns into confusion. The tasks are different, though not independent of each other.
| Task | Answers the question | What it compares |
|---|---|---|
| Face detection | is there a face in the frame, and where | nothing — it only finds the region |
| Liveness detection | is there a live person in front of the camera, or an image of one | the sample itself, without reference to any stored reference |
| Face verification (1:1) | is this the same person as in the document or profile | two samples against each other |
| Face identification (1:N) | who is this person among many | the sample against a database |
The short formula: recognition answers the question “who is this,” liveness detection answers the question “is this a real person.” When confirming identity, these tasks usually complement each other: a face verification system without liveness detection or PAD mechanisms can be vulnerable to a photograph or other artifact being presented to it, while liveness detection without recognition will confirm a live person is present, but not that they are who they claim to be.
One caveat is important here, without which the formula would be inaccurate: in practice, both tasks are often handled by the same module on the same frame, and some signals — skin texture, depth, lighting — are used for both. Calling them completely independent technologies would be inaccurate. For a detailed look at how face recognition works, how it achieves accuracy, and the difference between verification and identification, see the article “Face Recognition System: How It Works, Its Accuracy, and Where It’s Used.”
How Liveness Detection Works: What Signals the System Analyzes
Based on the standard’s definition, liveness indicators fall into several categories:
- anatomical characteristics — skin texture, the reflection and absorption of light by skin and blood, facial volume and relief
- involuntary reactions and physiological functions — blinking, micro-movements of facial muscles, pupil response to light, signs of cardiac activity
- voluntary reactions and behavior — movement on the system’s request, if the scenario calls for one
- scene geometry and depth — a flat object in front of the camera behaves differently from a three-dimensional face; on an ordinary camera, depth is estimated indirectly, from parallax and lighting
- properties of the image itself — print artifacts, screen moiré, signs of video re-encoding
One clarification is worth making, since the wording otherwise looks contradictory: if a solution works in passive mode with no instructions to the user, that doesn’t mean it ignores blinking or head turns as signals — it analyzes them as natural micro-movements that happen on their own, not as actions performed on request. The difference between “the system watches for blinking” and “the system asks you to blink” is exactly the difference between passive and active mode, covered further in the article.
Active and Passive Liveness Detection
| Mode | What the user does | Typical scenario |
|---|---|---|
| Active (active liveness) | performs an action on request — turns their head, blinks, says numbers out loud, tracks a dot on the screen | challenge-response scenarios where the user performs a specific action per the system’s instruction |
| Passive (passive liveness) | does nothing in particular — looks at the camera as in an ordinary shot | fast onboarding, minimizing friction for the user |
The difference between the modes is primarily about user experience and the requirements of the capture scenario, not about which one is “stronger” against specific types of forgery: the resilience of active versus passive mode to particular attack types is a topic for a separate discussion, not this article.
What the User Sees in Each Mode
In active mode, the user receives an instruction and can see that the system is waiting for them to do something — this makes the process more visible, but adds a step and takes time. In passive mode, the process requires nothing from the user beyond looking at the camera, and it usually takes less time than active mode — the exact speed depends on the solution — which means less friction for the user, but they don’t see any explicit confirmation that a check is happening at all.
According to its product page and documentation, NeuroVision claims both a passive and an active scenario. In the passive one, it’s enough for the user to look at the camera. For the active one, the documentation describes three task modes: simple commands like turning the head or blinking, more complex combinations in quick succession, and a circular head movement — similar to the initial Face ID setup. Which scenario is enabled depends on how the check is configured.
Why the Standard Divides Methods Differently
It’s important not to confuse this industry classification with the structure of the standard itself. ISO/IEC 30107-1:2023 doesn’t divide liveness detection methods into active and passive: where the standard discusses the role of challenge-response (clause 5.2), it distinguishes between challenge-response-based liveness detection, non-challenge-response-based liveness detection, and challenge-response not itself related to biometrics. In the industry, these categories became the everyday split into active and passive liveness, but that’s a product classification, not the standard’s own wording.
Where Liveness Detection Fits in the Customer Verification Process
Liveness detection isn’t a standalone procedure — it’s one of the steps in the identity confirmation process, most often within the KYC chain: after the system has detected a face in the frame, but before the result of the capture is compared against a document or a database. According to its product page, liveness detection can be connected as a separate module — independent of document verification and data extraction — which makes it possible to build it into an already-existing process rather than restructuring it entirely. For a detailed look at how a full customer check works, from uploading a document to a decision, see the article “KYC Step by Step: How Comprehensive Client Verification Works in Online Services”.
How exactly this sequence is structured depends on the specific product. According to NeuroVision’s documentation, its customer-verification scenario looks like this: the user starts on an intro screen or by following a QR code, then photographs their document, takes a selfie, goes through liveness detection, after which the system compares the face against the photo in the document and issues a decision for the session. This is how the scenario is built specifically at NeuroVision, not a universal industry architecture — other vendors may order the steps differently.
This chain resolves different questions, and they shouldn’t be confused: liveness detection answers “is there a live person in front of the camera?”, face matching against a document answers “does the face match the photo in the document?”, document verification answers “is the document valid, and what was extracted from it?”, and anti-fraud checks answer “are there signs of manipulation or resubmission?” According to NeuroVision’s documentation, the face-matching task appears in a session only when both a document and a selfie are present.
What Attacks Liveness Detection Tries to Detect
The point of liveness detection is to tell a bona-fide presentation apart from a presentation attack: an attempt to present the system with an artifact instead of the actual person. A presentation attack can pursue one of two goals, which are rarely distinguished: impersonation — pretending to be someone else, the most obvious scenario — and evasion — avoiding being recognized as yourself, for example, to avoid being tied to an already-existing account when trying to open a second one. Both scenarios fall under the task of PAD, though usually only the first is discussed.
Presentation Attacks
A presentation attack is an attempt to show the system an artifact instead of a live person. In practice, this means: a printed photograph or other paper medium; an image shown on a monitor or other display; a photo or video on a smartphone screen; a replay — playing back a previously recorded video; masks, including three-dimensional and silicone ones; a photocopy or a cropped fragment of an image. This is exactly the class of attacks PAD — presentation attack detection — is designed for. The classes of presentation attacks, their difficulty levels, and the methods used to detect them are covered in detail in the article “How Liveness Detection Is Bypassed” — they aren’t repeated here.
Digital Forgeries: Deepfakes and Generative Editing
It’s worth separately distinguishing two concepts that are often confused with the presentation attack itself. A deepfake is a way of manufacturing an artifact, not a separate attack class: the same synthesized image can be shown to the camera from a screen (which makes it an ordinary presentation attack) or fed directly into the video stream, bypassing the camera (which makes it an injection attack — covered below). Also in this category are face swap — transferring another person’s face onto an image — and fully neural-network-generated faces. For how such forgeries are constructed and detected in the context of video verification, see the article “Deepfakes in KYC: Detecting Face Spoofing”.
Injection Attacks: A Separate Class Outside PAD
Feeding a pre-prepared video stream that bypasses the camera is no longer a presentation attack — it’s an injection attack: it substitutes the capture subsystem itself, or the channel between it and the algorithm, and it falls outside the scope of classical PAD, which only evaluates what’s presented to a properly functioning sensor. PAD testing under standards like ISO/IEC 30107-3 doesn’t confirm resilience to injection — that’s a separate task, requiring additional mechanisms to protect the capture channel and the video stream. For more, see the article “How Video Streams Are Spoofed in KYC”.
There are also adjacent scenarios that superficially look like fooling liveness detection but are handled by other mechanisms. If the face in the frame doesn’t match the photo in the document, if someone else’s document is presented, or if the gender or age in the selfie doesn’t match the document’s data — that’s no longer a liveness task, but a task for face matching against the document and other selfie anti-fraud checks. How these mechanisms work, and which of them NeuroVision has, is covered below.
What NeuroVision’s Liveness Detection Identifies
According to the product documentation, different types of forgery are handled by different verification mechanisms — not just by the liveness detection algorithm:
| Attack scenario | What the attacker is trying to do | Which NeuroVision verification layer |
|---|---|---|
| Photograph, screen, video recording (replay), mask | present an artifact instead of a live person | liveness check (Liveness Check) — code 44 “is not alive” |
| Deepfake, face swap, fully generated face | forge a facial image using a neural network | selfie check for signs of generation — flag isFaceDeepFake, code 43 |
| Image from a screen or mobile device, photocopy, cropped frame | substitute the original frame | selfie anti-fraud checks — isDisplaySelfie, isMobile, isXerocopy, isCropped |
| Someone else’s face in the selfie | impersonate another person | face matching against the document — code 19 “bad face matching” |
| Gender or age mismatch with the document | use someone else’s data | consistency checks — isGenderMismatch, isAgeMismatch |
At NeuroVision, these checks work as parts of a single verification process, but they solve different tasks. Liveness determines whether there’s a live person in front of the camera, the anti-fraud mechanisms analyze the selfie for signs of forgery or manipulation, and Face Matching compares the user’s face against the photo in the document. These are different layers of protection that complement each other: passing one check successfully doesn’t replace the others.
Below is what the liveness detection step looks like for the user in the NeuroVision interface.
[[INTERFACE SCREENSHOT SLIDER]]
How the Industry Verifies the Quality of Solutions
ISO/IEC 30107 and Independent Laboratories
The evaluation methodology comes from ISO/IEC 30107-3:2023, “Testing and reporting” — the part of the standard that establishes the principles and methods for testing PAD mechanisms, the reporting procedure, and the classification of known attack types. The metrics used to measure quality (APCER and BPCER), and the attack difficulty levels this methodology uses, are covered in detail in the article “How Liveness Detection Is Bypassed” — here it’s enough to know that such a methodology exists and is standardized.
The resilience of specific solutions to known attack types is confirmed by testing at independent accredited laboratories — for example, iBeta, Ingenium, BixeLab. Laboratory testing for compliance with ISO/IEC 30107-3 (which results in the lab issuing a letter confirming the results, not a certificate) shows resilience to known attack types under controlled conditions, but it doesn’t replace monitoring real-world data after deployment.
What NIST Tests, and Why It Isn’t FRTE
NIST has a separate track specifically for liveness detection — Face Analysis Technology Evaluation, FATE PAD. This isn’t the same track as FRTE, which is used to assess face recognition accuracy: on 18 August 2023, NIST split its former FRVT program into two independent tracks — FRTE for recognition and FATE for face analysis, including PAD.
As of September 2026, the track has temporarily suspended accepting submissions: NIST is not accepting algorithms for PAD evaluation, and will announce the track’s reopening on its website and through its mailing list. The track’s last public report — NISTIR 8491, “Face Analysis Technology Evaluation (FATE) Part 10: Performance of Passive, Software-based Presentation Attack Detection (PAD) Algorithms” — was published in September 2023 and covers 82 passive, software-based algorithms on ordinary two-dimensional images. The practical takeaway: there’s currently no standing public benchmark for liveness detection comparable to FRTE for face recognition, and a vendor’s reference to “NIST testing” needs clarifying — exactly which track, and which report year, is being referred to.
The Technology’s Limitations, and What to Look for When Choosing a Solution
The standard explicitly states the limits of what PAD can do: “PAD cannot infer the biometric capture subject’s intent” — the system doesn’t determine a person’s intent; it distinguishes a bona-fide presentation from an attack based on measurable signs, but it doesn’t read motive. A separate note to the standard points out that the system may be unable to distinguish an attack from a simply unsuccessful presentation. In practice, this means some rejections aren’t attempts at deception but the result of capture conditions: backlighting, glare on glasses, camera shake, a weak device sensor.
This leads to a practical trade-off: the stricter the verification threshold, the fewer attacks slip through, but the more real users get rejected — and vice versa. Performance quality depends on the device, lighting, and capture scenario. Liveness detection answers only the question of a live person’s presence and doesn’t confirm identity — a separate step of matching against a document or a database is needed for that. Methods resilient to the forgery types known today offer no guarantee against new methods that will appear later. And separately: liveness detection doesn’t close off the risk of the frame source itself being substituted — the camera or the channel between the camera and the algorithm — such as the video-stream spoofing covered in the article above.
When choosing a solution, it makes sense to look at several practical parameters:
- whether the mode — active or passive — fits the scenario and the expected user load
- what camera and device requirements the solution imposes — whether it works on an ordinary front-facing smartphone or laptop camera without special equipment
- how fast the result comes back, and how that compares with the rest of the verification time
- deployment options — cloud or on-premises infrastructure — and the availability of SDKs and APIs for the platforms you need
- the ability to connect liveness detection as a separate module to an already-existing document and data recognition process
- the presence of independent testing of resilience to known attack types, as a benchmark rather than a guarantee
According to its product page, NeuroVision’s liveness detection solution supports both a passive and an active scenario on an ordinary front-facing camera and returns a result through a REST API as a pass/fail decision. Server-side processing takes a fraction of a second, and the full scenario with active verification, per NeuroVision’s documentation, can take up to a minute. According to the product page, the solution is offered as an SDK for Web, iOS, and Android, and connects as a separate module to document recognition, face matching, and AML checks.
Passive and active scenarios, an ordinary smartphone camera, ready-made SDKs and a REST API — connects as a separate module to an existing customer verification process
Liveness detection is a concept defined by the ISO/IEC 30107 standard, describing a check of whether a biometric sample is being captured from a live person present at the point of capture. It’s a subset of the broader task of presentation attack detection, not a synonym for it, and it’s a separate task from face recognition — both answer different questions and together form a complete customer verification. The split into active and passive modes is an industry practice, not the structure of the standard itself, which uses the concept of challenge-response for liveness detection rather than “modes.” The technology has clearly described limits: it doesn’t read a person’s intent, it can be wrong on unsuccessful frames, and it doesn’t close off the risk of the video-stream source itself being substituted, bypassing the camera. The choice of mode and solution depends on the scenario: passive mode reduces friction during onboarding, active mode fits situations that call for a challenge-response with a specific user action, and independent testing helps assess resilience to known attack types without turning into a guarantee against new ones.
FAQ
