- Passive liveness detection validates presence signals without asking the user for gestures, movements, or explicit instructions.
- Its value lies in reducing friction during onboarding without lowering the level of control against presentation attacks.
- It should be evaluated alongside document detection, risk analysis, regulatory compliance, and conversion metrics.
- In regulated industries, technical evidence matters as much as user experience.
A user opens their bank app at eleven at night to finish opening an account. The app asks for a selfie. Then it asks them to turn their head. Then to blink. Then to retake the capture because there was not enough light. At some point in that sequence, the user closes the app. They were not an attacker. They were a customer who got tired of proving they exist.
That scene sums up the tension. Identity verification is no longer an administrative step. In banking, gaming, retail, or digital government, it is the moment when an organization decides whether it trusts the person on the other side of the screen. But that control competes with conversion. Every extra instruction, every requested gesture, every repeated capture, and every false rejection adds friction at a sensitive point in the journey. If the user is legitimate, the system should not make them feel suspicious.
Passive liveness detection sits at that intersection: validating real presence without turning onboarding, meaning a user’s digital account opening process, into a test of patience. It does not replace the full security stack, but it solves a specific tension. It detects presentation attacks, meaning attempts to deceive the camera with a printed photo, a screen, or a mask, without asking the user to act in order to prove they are alive.
At VU, we see this every day in identity verification implementations for financial services and other regulated markets. The question is no longer whether biometrics need to be validated. It is how to do it with the least possible friction and with enough technical evidence to defend the decision.
Passive liveness detection validates presence without asking for explicit actions
Liveness detection seeks to determine whether the captured biometric sample comes from a real person who is present at the moment of verification. The goal is to block what comes through the camera: printed photos, screens playing a video, masks, and deepfakes, meaning AI-generated videos or images of a face created to imitate a real person.
There is a boundary worth making clear here because it becomes costly later. Injection attacks, where the attacker bypasses the camera and introduces a video directly into the application flow, are not presentation attacks. Liveness detection does not cover them, and no presentation attack detection test evaluates them. They require another control, which we cover below.
The passive variant performs its analysis without asking the user to smile, turn their head, blink, or follow on-screen instructions. The system evaluates signals from the capture and the context to estimate whether there is real presence. For the user, the process feels more like taking a selfie than completing a challenge.
In practical terms, three families of controls usually coexist:
- Active liveness detection: asks for explicit actions, such as moving the head, reading numbers, or following randomized instructions.
- Passive liveness detection: analyzes presence signals during a natural capture, without visible instructions.
- Complementary controls: review capture-channel integrity, device manipulation, document consistency, and risk signals associated with the session. This is where injection is detected.
The difference is not cosmetic. In digital onboarding, every visible step changes user behavior. If the system can validate presence without adding instructions, it improves the experience and reduces drop-off points.
Onboarding friction is also a business risk
Many teams treat friction as a user experience problem. It is more than that. In a high-intent flow, such as opening a bank account or recovering access to a wallet, a slow or confusing verification can lose a legitimate user and leave a false signal in the system.
Active liveness detection makes sense in high-risk scenarios or when the model needs more evidence. But using it as a permanent control for every user can be expensive in conversion. It also creates more support, more retries, and more manual review.
In financial services, the balance is especially delicate. The fraud team wants more controls, product wants fewer steps, compliance wants evidence, and engineering wants a stable integration. Passive liveness detection organizes part of that tension because it moves the control behind the experience instead of placing it in front of the user.
That volume forces teams to think differently. It is not enough for a flow to be secure in a demo. It has to hold up with real users, real cameras, irregular connectivity, documents from different countries, and behaviors that do not always follow the perfect lab script.
Friction is measured in production, not in presentations. A flow that works in a meeting room can break with a low-end phone, a poorly lit kitchen, and a connection that drops halfway through the capture.
Passive liveness is not less secure because it is less visible
There is an assumption worth challenging: if the user does not receive a visible challenge, the control is weaker. Not necessarily. The security of a liveness check does not depend on how much discomfort it creates, but on what signals it analyzes, how it was evaluated, and which attacks it was tested against.
Standards exist precisely to organize that discussion, as long as they are cited accurately. ISO/IEC 30107-3 defines the testing method and metrics for measuring presentation attack detection: APCER, the percentage of attacks the system accepted as legitimate; BPCER, the percentage of legitimate users it rejected; and IAPMR, the percentage of attacks that managed to impersonate the identity holder. The standard does not evaluate whether an experience feels secure, and it does not define levels. Levels 1, 2, and 3 belong to iBeta’s testing program, the lab that runs the tests, and what iBeta issues at the end is a confirmation letter of conformity, not a certification.
It is worth repeating the boundary from the previous section because it is where the market gets confused most often: that test covers presentation attacks, the ones that enter through the camera. Video injection is outside its scope and requires its own controls, such as capture-channel integrity verification and device attestation.
Well-implemented passive liveness raises the cost of attack without raising the cost of use for legitimate people. That is the point. The attacker must overcome invisible controls, and the user should not have to carry the complexity of the system. Security, without friction.
This does not mean passive liveness is always the only answer. In high-risk sessions, a flow can escalate to additional controls. Good architecture does not choose between security and experience as if they were fixed opposites. It adjusts the level of control to the risk of the operation.
Technical evaluation must look at attacks, bias, and real-world operations
Choosing passive liveness detection should not depend on a commercial promise. If you are evaluating providers, there are concrete criteria to determine whether the technology is ready for a critical flow.
- Resistance to presentation attacks: the system must be tested against physical and digital artifacts, including screens, prints, masks, and videos played in front of the camera.
- Injection detection: a separate control from the previous one. The flow must review attempts to manipulate the capture channel, not just the final image.
- Legitimate rejection rate: a control that blocks real users generates operational cost and conversion loss.
- Regional coverage: LATAM has diverse documents, devices, lighting conditions, and connectivity. The model has to work outside the lab. A citizen procedure in a provincial office and a bank onboarding from a new phone are not the same capture scenario.
- Audited evidence: results must be supported by standards, lab conformity letters, and verifiable technical reports, with declared date and scope.
- Risk-based escalation: a suspicious session may require additional controls without forcing the same level of friction on everyone.
Bias also needs to be examined. Facial biometrics should be evaluated with diverse populations, real capture conditions, and metrics separated by groups when applicable. If the model only performs well with one type of camera, lighting, or user, the problem will surface in production.
The technical point is simple: passive liveness detection is not bought as an isolated feature. It is evaluated as part of an identity decisioning system.
VU integrates passive liveness detection into broader verification
Passive liveness detection has more value when it connects with the rest of the verification process. A selfie can say a lot, but it should not decide alone. The document, biometrics, device, session, and fraud signals build a more complete reading of risk.
At VU, Verify combines biometric onboarding, document validation, and liveness detection within a flow built for LATAM markets. For teams that also need recurring authentication and fraud prevention, VU ONE consolidates Verify, Authenticate, and Protect into a single SDK, meaning one integration kit that the development team adds once and uses for all three capabilities.
That approach matters because many organizations grew with separate tools: one for onboarding, another for authentication, another for fraud, another for manual review. The result is usually a fragmented identity map. Each team sees one part of the user, and nobody sees the complete session.
For financial services, that fragmentation is costly. Account opening, device change, access recovery, and a sensitive transaction are not isolated events. They are different moments in the same identity relationship.
Passive liveness detection adds value when it connects with that continuity. It verifies presence during onboarding, but it can also become part of a broader authentication and fraud prevention strategy.
The best liveness check is the one legitimate users barely notice
Biometric verification should not ask users to understand the risk model. That is the system’s job. When a legitimate person registers, recovers an account, or validates a transaction, the experience should be clear, brief, and proportional to the risk.
Passive liveness detection pushes the industry toward that criterion. It does not remove the need for strong controls. It moves them to the right place, behind a simpler experience, with escalation when the session justifies it.
To me, that is the discussion that matters most. This is not about making verification invisible at any cost. It is about making sure legitimate users do not pay with friction for fraud they did not commit.
Fraud should not design the experience of your good users.
Let’s talk.
