TL;DR: Liveness detection is framed as a core defence against presentation attacks, including masks, screen replays, deepfake video, injection attacks and bot attacks, according to Yoti’s January 2026 white paper, which says its MyFace solution achieved iBeta Level 3 approval with 100% attack detection. The identity lesson is broader: verification controls must prove presence, not just image quality, or spoofing remains viable.
NHIMG editorial — based on content published by Yoti: Yoti MyFace liveness white paper
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Yoti's liveness white paper on defeating presentation attacks →
Liveness detection: are your verification controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Liveness detection gaps remain central to human verification risk