Liveness detection
The control that determines whether there is a live person in front of the camera at the moment of capture. What it checks, how it differs from comparing faces, and how it's measured with an independent test.
In short
Liveness detection is the control that determines whether a biometric capture shows a real, present person, and not a photograph, a screen playing back a video, a mask, or a generated face. It doesn't answer who that person is: that question is resolved by the biometric comparison. It answers whether there is someone.
It's the control that separates an identity verification from a simple resemblance between two images, and the one whose weight changed once forging a face stopped being expensive.
Comparing faces and checking presence are two different questions
A biometric verification flow runs two checks that get confused often because they happen in the same second.
- Biometric comparison — answers whether the captured face matches the one on the document. It's a question of resemblance, resolved with a similarity score against a threshold.
- Liveness detection — answers whether that face belongs to a real person present at that moment. It's a question of presence, resolved with signals from the capture.
A well-built synthetic face passes the first and fails the second, as long as someone is actually asking the second question. An onboarding flow that reads the document and compares faces without checking presence accepts a reproduced image with the same criteria it uses to accept the actual holder.
The two checks also fail differently, which is why they're measured with separate metrics: comparison errors are FMR and FNMR, and liveness detection errors are the ones from the PAD test.
Passive and active liveness detection solve the same problem two ways
The difference between the two isn't one of quality. It's about what's asked of the user and what's gained in exchange.
- Passive — analyzes presence signals in the capture without asking the user to do anything. Skin texture, how light behaves on a real surface, screen-reproduction artifacts, depth. The user just looks at the camera.
- Active — challenges the user with instructions they can't anticipate (turn their head, follow a dot, read a sequence) and validates the response in real time. It adds unpredictability, at the cost of friction and time.
Passive holds conversion better because it adds no steps. Active adds a barrier against attack instruments prepared in advance, because the attacker doesn't know what will be asked. Many flows combine both and reserve the active one for cases the session's risk flags.
Neither is a stand-alone control. Both analyze what reaches the application from the camera, and that's why neither one, on its own, resolves a video injection attack, which replaces that flow before it ever arrives.
How liveness detection is measured
A claimed liveness detection and a measured one aren't comparable, and an independent test is what establishes the difference.
The ISO/IEC 30107-3 standard defines how to evaluate presentation attack detection: an accredited lab builds attack instruments, presents them against the system under controlled conditions, and reports error rates with defined metrics. The result is a reproducible number produced by someone who doesn't sell the product.
Two clarifications that almost always get lost:
- The standard doesn't define conformance levels. It defines the method, the metrics, and how the result is reported. The levels that appear alongside the standard belong to iBeta's testing program, which applies that methodology, and there are three: Level 1 uses low-cost, easy-to-build attack instruments, Level 2 incorporates instruments of greater sophistication and cost, and Level 3, which the lab added in 2025, tests highly prepared instruments such as custom-made hyper-realistic masks.
- The standard's scope is presentation attacks, the ones that happen in front of the capture device. Video injection falls outside it and is covered by a different control.
Where liveness detection is required
The control shows up wherever identity is verified remotely and the organization is accountable for the result.
- [KYC](/glosario/kyc) processes — the presence check is what separates a remote verification from a comparison between two images anyone could obtain.
- Financial services — account opening and access recovery, where an impersonated identity stays inside the system and gets used later.
- Betting and gaming — age and identity verification as a licensing requirement.
- Government — procedures and benefits requested in one's own name.
- Background screening — identity accreditation in hiring processes.
Each country resolves it through its own anti-money-laundering and data protection rules. In Colombia and Mexico the requirement comes through that route, not through a rule that names liveness detection specifically.
Frequently asked questions
It's the control that determines whether a biometric capture shows a real, present person, and not a photograph, a screen, a mask, or a generated face. It runs alongside the biometric comparison but answers a different question: the comparison establishes who the captured face resembles, and liveness detection establishes whether that face belongs to someone who was actually there. Without it, a verification flow accepts a reproduced image with the same criteria it uses to accept the actual holder.
Passive analyzes presence signals in the capture without asking the user to do anything: the user just looks at the camera. Active asks for a response the user can't anticipate, like turning their head or following a dot, and validates the reaction in real time. Passive holds conversion better because it adds no steps; active adds unpredictability against attack instruments prepared in advance, at the cost of friction. Many flows use passive by default and turn on the second one when the session's risk justifies it.
Not by default, and it's worth treating them as two separate controls. Liveness detection analyzes what arrives from the camera and determines whether it corresponds to a person who is present. A video injection attack shows nothing to the camera: it replaces the video feed before it reaches the application, using a virtual camera, an emulator, or device tampering. Detecting it requires verifying the origin of the feed and the integrity of the runtime environment, which is a different control. ISO/IEC 30107-3 certifications don't cover it either: their scope is presentation attacks.
With the result of an independent test, not with the product's description. Four pieces of data make a result comparable: which methodology it was tested against, which level of the testing program it passed, on what date, and against which version of the product. A result from two years ago was obtained against attack instruments from two years ago.
