Liveness detection gaps remain central to human verification risk

At a glance

What this is: This white paper argues that liveness detection is essential because verification systems must distinguish a real human from spoofing attempts such as masks, replays, deepfakes and injection attacks.

Why it matters: For IAM and identity verification teams, the issue is whether authentication and onboarding controls can reliably prove presence rather than simply accept a convincing image or video feed.

By the numbers:

• Yoti’s MyFace solution is iBeta Level 3 approved with 100% attack detection.

Context

Liveness detection sits inside human identity verification, where the control question is whether the subject is physically present at the point of capture. If that proof is weak, attackers can push through masks, screen replays, deepfake video, injection attacks or bot-driven spoofing without needing to break the surrounding identity stack.

The governance gap is simple: many verification flows still optimise for image quality or successful matching, not for proof of presence. That makes liveness a control boundary for onboarding, authentication and fraud prevention, especially where remote identity proofing feeds downstream access decisions.

Yoti’s white paper uses MyFace as the source example, but the underlying issue is broader than one product. Any identity programme that treats visual plausibility as sufficient verification leaves room for presentation attacks to pass as legitimate users.

Key questions

Q: How should security teams use liveness detection in biometric login flows?

A: Use liveness detection wherever a biometric result would unlock meaningful access, especially in onboarding, recovery, and step-up authentication. The control should confirm live presence before the system trusts the match. Teams get the best results when they combine it with device trust, risk scoring, and recovery controls instead of treating it as a standalone gate.

Q: When does passive liveness create more risk than it reduces?

A: Passive liveness becomes risky when the workflow faces replay, synthetic media or injection-style attacks and the organisation assumes friction reduction is the same as assurance. It can be the right control for lower-risk journeys, but only if the model has been tested against the local fraud and identity threat mix.

Q: What breaks when verification only checks image quality?

A: The control fails because a convincing static or replayed image can satisfy the system without proving a live human is present. That gap lets masks, screen captures, deepfakes and other presentation attacks pass as legitimate users, which weakens both onboarding trust and authentication decisions.

Q: What is the difference between active and passive liveness checks?

A: Active liveness checks ask the user to perform a task such as blinking, smiling, or turning the head. Passive liveness checks work in the background by analyzing facial texture, depth, light response, and micro-movements without explicit prompts. Active methods are generally stronger against spoofing, while passive methods are smoother for users and faster to complete.

Technical breakdown

Why presentation attacks bypass ordinary verification

Presentation attacks work by feeding the verifier a synthetic or replayed signal that looks legitimate enough to pass the capture step. Masks, screen images, video imagery and deepfake video exploit the fact that many systems assess appearance rather than evidence of a live, interacting person. Injection attacks are different: they bypass the sensor path and insert fabricated data directly into the pipeline. Bot attacks add scale, using automation to test or replay identity material until the system accepts it. The technical point is that liveness is not a cosmetic layer. It is a trust decision about the origin of the biometric signal itself.

Practical implication: Treat liveness as a control over signal origin, not a user-experience feature.

Active versus passive liveness in identity assurance

Active liveness requires the subject to perform a prompted action, such as a movement or response, while passive liveness infers presence from unprompted behavioural and physiological cues. Active methods can raise attacker effort because the spoof must respond in real time, but they also introduce more user friction and can be harder to scale cleanly. Passive methods reduce friction and fit mobile-first journeys, but they depend heavily on model quality and attack coverage. The right choice is not ideological. It depends on how much assurance the workflow needs, how tolerant the user journey is, and how well the system can resist replay or synthetic media.

Practical implication: Match liveness method to the assurance level and fraud tolerance of the specific workflow.

What iBeta Level 3 approval signals for verification risk

iBeta Level 3 approval is a test result that indicates a liveness solution has been evaluated against spoofing attempts under a defined testing regime. It does not eliminate risk everywhere, but it does show that a system has been assessed against concrete attack classes rather than assumed secure because it can match a face. For practitioners, the important question is not whether a vendor can name a certification. It is whether the evaluated attack model lines up with the threats present in their own onboarding or authentication flow, including replay, injection and synthetic media.

Practical implication: Validate liveness controls against the attack patterns in your own environment, not against certification claims alone.

NHI Mgmt Group analysis

Liveness is a trust boundary, not a cosmetic check: Verification programmes fail when they confuse image quality with proof of presence. Presentation attacks exploit that assumption by making a synthetic signal look believable enough to be accepted as a real user. The practical consequence is that identity assurance has to be measured at the point where the system decides whether a human is actually present.

Presentation attack resistance belongs in human identity governance: Liveness detection is not a niche fraud feature. It is part of the control set that supports onboarding, authentication and age or identity verification, because those decisions often feed downstream access and eligibility checks. When that boundary is weak, spoofing becomes an access problem as much as a fraud problem.

Active and passive liveness answer different operational constraints: Active liveness raises attacker effort, while passive liveness lowers user friction and may fit higher-volume journeys. Neither is universally superior, because the control choice depends on the assurance level and the threat model. Practitioners should align the method to the risk of spoofing in the workflow, not to vendor preference or user convenience alone.

Verification controls must prove liveness under attack conditions: The relevant question is whether a control can withstand masks, replays, deepfakes, injection attacks and bot activity in the environment where it will be used. A system that succeeds in a lab but fails against the local threat mix does not close the governance gap. The implication is to treat liveness as an evidence-based control, not a trust assumption.

MyFace and similar products illustrate a broader programme requirement: identity teams need a consistent standard for what counts as acceptable proof of presence across verification journeys. That standard should be driven by threat exposure, user friction and downstream risk, not by the existence of a biometric step alone. The practitioner conclusion is to govern liveness as part of the identity control plane.

What this signals

Proof of presence is the real control objective: Identity programmes that rely on visual plausibility are vulnerable to spoofing because a convincing image is not the same as a live human. Liveness detection should therefore be governed as an assurance boundary inside the identity control plane, not as an isolated feature.

Verification journeys need threat-aligned liveness testing: Teams should validate their capture and authentication flows against the specific attack classes that matter to them, including replay, deepfake and injection paths. The control is only as strong as the attack model it was tested against.

Friction and assurance have to be balanced deliberately: Active and passive methods solve different operational problems, so the decision should be based on user tolerance, fraud exposure and downstream consequence. A low-friction journey that cannot prove presence is a weak identity decision, not a mature one.

For practitioners

• Define the required proof of presence Set explicit assurance thresholds for verification and authentication flows so teams know when liveness is mandatory rather than optional. The threshold should reflect the downstream consequence of spoofed enrolment or login, not just the convenience of the journey.
• Test against presentation attack classes Evaluate controls against masks, screen replays, deepfake video, injection attacks and bot-driven spoofing. The test set should mirror the attack patterns that matter in your environment, not a generic vendor demonstration.
• Choose active or passive liveness by risk Use active liveness where the workflow can absorb user prompts and needs stronger challenge-response evidence. Use passive liveness where friction must be lower, but only if the model is validated against realistic replay and synthetic-media threats.
• Tie verification to downstream access decisions Ensure the outcome of identity proofing influences authentication, onboarding and fraud controls consistently. A weak liveness step should not be allowed to feed a strong trust decision later in the flow without review.

Key takeaways

• Liveness detection matters because spoofing succeeds when verification systems mistake a convincing signal for a real person.
• The article’s central evidence is that Yoti says MyFace achieved iBeta Level 3 approval with 100% attack detection.
• Practitioners should treat proof of presence as a governed requirement and test liveness controls against real presentation attack classes.

Key terms

• Liveness Detection: Liveness detection is the mechanism that checks whether a biometric sample comes from a real, present person rather than a spoof such as a photo, screen, or mask. In identity programmes, it is a core defence against presentation attacks and should be tested under realistic operating conditions.
• Presentation Attack: A presentation attack is an attempt to fool a biometric system with a fake face, replayed video, mask, or other synthetic artefact. In practice, the control fails when it measures resemblance alone, because the attacker’s objective is to pass as the real user without actually being that person.
• Active Liveness Check: An active liveness check requires the user to complete a prompt during verification, such as blinking, smiling, or turning the head. The system uses the response to confirm presence and detect replay or spoofing attempts. It is stronger against fraud, but it adds friction and depends on user participation.
• Passive Liveness: Passive liveness is a verification method that checks whether a biometric sample appears to come from a live human without requiring the user to perform actions. It reduces friction, but it still depends on the integrity of the capture and analysis path. If that path is manipulated, passive liveness alone will not protect the decision.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.