By NHI Mgmt Group Editorial TeamDomain: Governance & RiskSource: YotiPublished January 22, 2026

TL;DR: Liveness detection is presented as a way to prove a real person is present during selfie-based identity and age verification, blocking presentation and injection attacks while reducing fraud, account takeover, and false rejections, according to Yoti. The core issue is that digital identity flows now depend on proving human presence at runtime, not just matching a face to a record.


At a glance

What this is: This is an explainer on liveness checks and the finding that proving real-time human presence is now essential to reliable digital identity and age verification.

Why it matters: It matters because IAM, fraud, and onboarding teams need controls that distinguish real users from spoofed or injected inputs without creating excessive friction or privacy tradeoffs.

By the numbers:

👉 Read Yoti's article on how liveness checks work and why they matter


Context

Liveness checks are a human identity control that tries to answer a simple question: is a real person present right now, or is the system being spoofed? In identity and age verification journeys, that distinction matters because a face match alone does not prove presence, and modern fraud kits can reuse photos, video, masks, or synthetic faces.

The governance gap is that many digital onboarding flows were designed for static verification, then exposed to dynamic abuse. When human identity proofing moves into self-service channels, liveness becomes part of the trust boundary, alongside authentication, age assurance, and account recovery.

That makes liveness relevant to IAM and fraud teams rather than only to consumer app teams. It sits at the point where identity assurance, user experience, and privacy expectations intersect, which is why weak implementations create both security failure and customer friction.


Key questions

Q: How should security teams use liveness checks in high-risk identity journeys?

A: Security teams should reserve stronger liveness checks for account opening, recovery, and high-value transactions where impersonation would create material loss. The control should prove presence at the moment of verification, not just compare a face to an enrolment record. That makes liveness an assurance gate, not a cosmetic layer in the login flow.

Q: Why do liveness checks matter more as identity moves online?

A: They matter because digital journeys remove face-to-face confirmation, which used to provide a basic reality check. Once verification becomes remote, attackers can reuse photos, replay video, or inject fake media. Liveness restores part of that assurance by tying the decision to a live capture event.

Q: What do organisations get wrong about inclusive biometrics?

A: They often assume that a vendor’s accuracy claim is enough. In practice, inclusivity depends on how the system performs across real users, whether accessibility constraints are addressed, and whether bias is monitored after rollout. Without those controls, the organisation can ship a system that works for most users and still fails at the point of access for many others.

Q: How can teams balance security and user experience in age verification?

A: Use the least intrusive liveness method that still meets the risk level of the journey. Passive methods reduce friction for most users, while stronger challenge-based methods may be justified for higher-risk flows. The key is to align assurance level, accessibility, and privacy expectations.


Technical breakdown

Presentation attacks and injection attacks in liveness detection

Liveness detection is meant to separate a live capture from a replay or synthetic input. Presentation attacks use something shown to the camera, such as a photo, video, mask, or AI-generated face. Injection attacks bypass the camera path and feed fake media directly into the system. Both target the same weakness: verification workflows that assume the capture device is trustworthy by default. Stronger systems look for texture, depth, timing, and device-level capture signals to distinguish live presence from manipulation.

Practical implication: teams should test both camera-facing spoofing and direct feed injection, not just one attack path.

Passive liveness detection versus active challenge-response

Passive liveness detection analyses natural signals in the image or video without asking the user to move or speak. Active liveness detection asks the user to perform an action such as blinking, nodding, or repeating a phrase. Passive methods usually reduce friction and accessibility issues, but they must still resist high-quality spoofing. Active methods can raise the effort required for attackers, but they also create more failure points for legitimate users. The right choice depends on fraud risk, user population, and whether the journey is repeat verification or a high-assurance onboarding event.

Practical implication: choose the liveness mode based on risk and usability, not as a one-size-fits-all default.

Why NIST-style benchmarking matters for liveness quality

Liveness controls only help if they are independently testable against known spoofing conditions. Benchmarking gives practitioners a way to compare how a detector performs against 2D prints, 3D masks, replay media, and related attack classes. Without that evidence, teams are left trusting marketing claims rather than assurance data. In identity assurance terms, liveness is not a binary feature. It is a measurable control with thresholds, failure modes, and tradeoffs that need to be understood before deployment into regulated onboarding or age verification flows.

Practical implication: require benchmark evidence and define acceptable false reject and false accept rates before rollout.


Threat narrative

Attacker objective: The attacker wants to impersonate a real person well enough to pass identity or age verification and obtain trusted access.

  1. Entry occurs when an attacker presents a photo, replayed video, mask, or injected media to an identity verification flow.
  2. Escalation follows when the spoof passes face-based checks and the attacker inherits access intended for a real, present human user.
  3. Impact is account takeover, fraudulent onboarding, or underage access that the platform treats as legitimate identity proof.
  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
  • DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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


NHI Mgmt Group analysis

Liveness checks are a human identity assurance control, not a cosmetic anti-fraud feature. Their role is to prove presence at the point of verification, which means they sit inside the identity trust boundary rather than beside it. That matters because a face match without presence verification is only partial assurance. For practitioners, the control belongs in the same governance conversation as onboarding risk, recovery risk, and age assurance.

Presentation attacks and injection attacks expose different failure modes, so one test path is not enough. A camera-only spoof test does not prove resilience against media injection, and a device-injection test does not prove resilience against masks or replay. The real issue is whether the verification chain can distinguish a live human from a fabricated input stream. Practitioners should treat these as separate assurance problems, not one generic biometric risk.

Privacy-preserving identity proofing is now a design requirement, not a nice-to-have. The market pressure is toward stronger verification with less data retention, fewer manual reviews, and lower user friction. That combination only works if the control confirms presence without turning every verification into a surveillance event. For identity programmes, the challenge is to raise assurance without creating a new privacy liability.

Named concept: human presence assurance gap: liveness failures occur when a digital workflow treats image similarity as proof of a live person. That assumption breaks as soon as spoofing can mimic the capture event itself. The implication is that human identity assurance now depends on runtime presence evidence, not just enrollment evidence, and practitioners need to design their verification flows accordingly.

From our research:

  • 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity control breaks down before teams can even detect misuse.
  • For a deeper governance lens, the Ultimate Guide to NHIs , The NHI Market helps place assurance controls inside the broader identity security stack.

What this signals

Human presence assurance gap: as more onboarding and verification moves online, teams should expect spoof resistance to become a standard identity control rather than a specialist fraud add-on. The practical question is no longer whether a face matches, but whether the capture itself can be trusted at the point of decision.

The next programme-level decision is whether your verification flows can prove presence without over-collecting data. That requires tighter alignment between fraud operations, IAM governance, and privacy review, especially where age checks, recovery journeys, or regulated onboarding rely on biometric signals.

With NHIs outnumbering human identities by 25x to 50x in modern enterprises, identity teams are already living in a world where assurance must be contextual, not static. Human verification is moving in the same direction, which is why control design has to follow the transaction, not just the user record.


For practitioners

  • Test for both spoof classes Validate controls against presentation attacks and injection attacks separately, because each bypass path behaves differently in production journeys.
  • Define assurance thresholds before rollout Set acceptable false accept and false reject rates for onboarding, age verification, and recovery flows before exposing the process to customers.
  • Place liveness at the right trust boundary Use liveness where the workflow needs proof of real-time presence, especially in account opening, step-up verification, and age-gated access.
  • Review retention and privacy handling Confirm that the verification process can prove presence without storing unnecessary biometric data or extending retention beyond the transaction.

Key takeaways

  • Liveness checks exist to prove real-time human presence, not just biometric similarity, and that distinction now shapes trust in digital identity flows.
  • Fraud scale and spoofing methods have made presentation attacks and injection attacks operational risks, not theoretical edge cases.
  • Teams need benchmarked liveness controls, clear privacy handling, and risk-based assurance thresholds if they want verification that is both secure and usable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63AThe article is about identity proofing and presence verification during onboarding.
NIST CSF 2.0PR.AC-1Liveness checks support identity verification at the access boundary.
NIST SP 800-53 Rev 5IA-2The control relates to identification and authentication of users in verification flows.

Tie liveness controls to access assurance, then review false accept and reject outcomes regularly.


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.
  • Injection attack: An attack that inserts synthetic or manipulated data directly into the verification flow rather than fooling the sensor itself. For identity programmes, this is a control-path problem, because the attacker may bypass the visible presentation layer and exploit the software decision point.

What's in the full article

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

  • The article walks through how passive liveness detection differs from active challenge-response in everyday verification journeys.
  • It explains the difference between presentation attacks and injection attacks in plain language.
  • It describes why benchmarked liveness performance matters for lower friction onboarding and age assurance.
  • It outlines the privacy-preserving model that confirms presence without retaining biometric data indefinitely.

👉 Yoti's full article covers passive detection, attack types, and the privacy tradeoffs 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 identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org