Liveness detection gaps remain central to human verification risk

At a glance

What this is: This is a white paper on liveness detection for human verification, with a key finding that spoof attacks still demand stronger proof-of-presence controls.

Why it matters: It matters because verification and authentication programmes that cannot distinguish a real person from a synthetic or replayed input remain exposed to fraud and account takeover.

By the numbers:

• Yoti’s MyFace solution is iBeta Level 3 approved with 100% attack detection.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Yoti's liveness white paper on defeating presentation attacks

Context

Liveness detection is the part of identity verification that tries to prove a person is physically present at the point of capture, not just represented by a camera feed, replayed image, or synthetic video. For human identity programmes, that matters wherever selfie verification, remote onboarding, age assurance, or step-up authentication can be attacked with presentation fraud or deepfakes.

The governance gap is simple: if controls only judge whether an image looks plausible, they do not prove that the subject is live. That leaves verification and authentication programmes vulnerable to spoofing, especially where the attacker can iterate quickly across masks, screen replays, injected video, or bot-driven attempts.

This makes liveness a human identity control first, not an AI novelty. It belongs in the same operational conversation as fraud reduction, account recovery, and assurance level design, because the failure mode is not model sophistication alone, but weak proof that the person is real.

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: Why do deepfakes and replay attacks weaken remote identity checks?

A: They weaken remote checks because a verification system can be shown a convincing but non-live input that looks authentic enough to pass superficial inspection. If the workflow does not validate presence and the capture path, an attacker can turn synthetic media into trusted identity evidence and bypass controls that assume a real person is in front of the camera.

Q: What do organisations get wrong about liveness detection?

A: Organisations often treat liveness detection as proof of identity when it only addresses one part of the problem. A system can recognise a real face and still be fooled by injected video, tampered endpoints, or replayed streams. The mistake is assuming a single biometric check covers the whole assurance chain.

Q: Who is accountable when spoof attacks bypass human verification controls?

A: Accountability usually sits with the identity, fraud, and security owners who approved the assurance design, not with the liveness model alone. The relevant governance question is whether the organisation defined the right threat model, testing standard, and transaction thresholds before relying on the control in production.

Technical breakdown

Active versus passive liveness in identity verification

Active liveness asks a user to perform a challenge, such as movement or a prompt response, while passive liveness evaluates signals in the capture stream without extra user interaction. Both approaches try to separate live capture from presentation attacks, but they do so with different trade-offs in friction, usability, and attacker adaptability. Passive systems often reduce abandonment, while active systems can raise the cost of replay and mask attacks. In practice, the control is only as strong as the adversary model it is tested against.

Practical implication: Match the liveness method to the risk level of the transaction, not to convenience alone.

Presentation attacks, deepfake video, and injection attacks

Presentation attacks use a fake or manipulated input to convince a verification system that a subject is present. That can include masks, screen imagery, recorded video, deepfake video, or injection attacks where the feed itself is altered before the verification layer sees it. The important point for IAM teams is that the threat is not only visual deception. It is also pipeline compromise, where a bogus capture is supplied to the decision engine as if it were a live user.

Practical implication: Design controls that validate the capture path as well as the image content.

Why liveness belongs in assurance design

Liveness is not a standalone silver bullet. It is one control in an assurance stack that may also include document checks, device signals, behavioural analytics, and step-up authentication. The right question is whether the combined process produces enough confidence for the use case. High-risk onboarding and recovery flows need stronger assurance than low-risk account interactions, and remote identity proofing should be explicit about what liveness can and cannot prove.

Practical implication: Set assurance targets by use case and document what evidence liveness contributes to the overall decision.

Threat narrative

Attacker objective: The attacker wants to bypass human verification and obtain trusted access or approval without a real live subject present.

1. Entry occurs when an attacker submits a mask, replayed screen image, deepfake video, or injected feed into a verification flow.
2. Escalation follows when the system accepts the spoofed capture as live and grants a human identity decision based on the false signal.
3. Impact is account takeover, fraudulent onboarding, or unauthorised access that appears to come from a legitimate person.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human verification fails when organisations treat image quality as proof of identity. Liveness detection exists because a convincing frame is not the same thing as a real person. That distinction matters in onboarding, recovery, and step-up authentication, where presentation attacks can turn an apparently valid capture into fraudulent trust. Practitioners should treat proof-of-presence as a first-class assurance requirement, not a user-experience enhancement.

Active and passive liveness solve different parts of the same governance problem. Active checks raise attacker cost by forcing interaction, while passive checks reduce friction and can improve adoption. The real question is not which is superior in the abstract, but which control matches the threat model and transaction risk. Identity programmes that do not map liveness type to assurance level will either over-control low-risk flows or under-protect high-risk ones.

Proof-of-presence is now a fraud-control boundary, not just an authentication feature. Deepfake video, mask attacks, and injection attacks all exploit the same broken assumption, that a camera feed implies a live human. That assumption no longer holds on its own. The implication is that verification architectures must be designed around adversarial capture, not trustworthy capture.

Named concept: proof-of-presence gap. This is the gap between a system that can verify an image and a system that can verify a live human at the point of capture. It becomes visible when replay, synthetic media, or feed injection can satisfy the decision path. Practitioners should recognise that this is a human identity governance issue, not only a biometrics issue.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity blind spots become operational risk.
• For a broader governance lens, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that reduce identity exposure.

What this signals

Proof-of-presence gap: human identity programmes increasingly need a fraud boundary that sits between capture and authentication. As deepfake and replay techniques become easier to operationalise, teams should expect assurance design, not biometric accuracy alone, to become the deciding factor in remote verification resilience.

The right programme response is to align liveness strength with transaction risk, then verify the whole capture chain rather than the visible image. That will matter most in recovery and onboarding paths, where a weak control can turn a single spoof into durable account trust.

For practitioners

• Define assurance levels for each verification flow Map onboarding, account recovery, age assurance, and step-up authentication to explicit assurance thresholds so liveness is only used where it materially reduces fraud risk.
• Test the capture path, not only the model output Run adversarial testing for screen replay, mask presentation, deepfake video, and injection attack paths so the team can see where the pipeline accepts non-live inputs.
• Separate low-friction and high-risk journeys Use passive liveness where user friction must stay low, but require stronger proof-of-presence and additional checks for higher-risk identity events.
• Document what liveness does and does not prove State clearly whether the control is intended to support presence, anti-spoofing, or fraud reduction, and avoid overstating it as a complete identity proof.

Key takeaways

• Liveness detection is a human identity control for proving presence, not just image authenticity.
• Presentation attacks exploit the gap between a convincing capture and a live person, which makes assurance design more important than visual plausibility.
• Teams should map liveness strength to transaction risk and test the full capture path before trusting the result in production.

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.
• Proof of Presence: A verification approach that aims to establish that a real person is actively participating at the moment of authentication. It goes beyond matching a stored trait and instead looks for live, context-specific evidence that resists replay, cloning, and remote fabrication.

What's in the full article

Yoti's full white paper covers the operational detail this post intentionally leaves for the source:

• How MyFace is evaluated against presentation attacks across masks, screen imagery, video replay, and deepfake attempts.
• The distinction between active and passive liveness and how each changes user friction in production journeys.
• Why the paper positions liveness as part of verification and authentication rather than as a standalone fraud control.

👉 Yoti's full white paper covers the attack classes, liveness distinctions, and implementation context in more detail.

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.