What do security teams get wrong about liveness detection in onboarding?

Why This Matters for Security Teams

liveness detection is often described as a fraud control, but onboarding teams sometimes overstate what it proves. It can help distinguish a live person from a static spoof, yet it does not automatically verify the device, capture stack, or network path delivering the biometric sample. That distinction matters because onboarding is where identity assurance decisions begin, and errors here can cascade into account takeover, synthetic identity creation, and downstream compliance exposure.

Security teams also tend to separate liveness from broader trust decisions, when it should be treated as one signal inside a layered control set. Current guidance suggests aligning biometric checks with device posture, session integrity, fraud monitoring, and step-up verification rather than using liveness as a stand-alone gate. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to manage identity-related risk as part of a wider control program, not as a single-point control. In practice, many security teams discover the weakness only after a fraudulent onboarding attempt has already bypassed the capture layer, rather than through intentional design of the trust boundary.

How It Works in Practice

Operationally, liveness detection tries to answer a narrow question: is the biometric sample coming from a real, present subject rather than a replay, mask, or injected stream? That may involve passive analysis of texture, motion, or sensor response, or active prompts that ask the subject to respond in real time. The problem is that these checks are only as trustworthy as the path feeding the biometric engine.

In a typical onboarding flow, the user submits an image or video, the app forwards it to a verification service, and the service returns a liveness score. If an attacker can inject media before the verification step, the engine may receive a valid-looking sample from an untrusted device or tampered application context. That is why practitioners should evaluate the entire chain:

• Device integrity and rooting or jailbreak signals
• Application tamper resistance and API request validation
• Transport security and certificate handling
• Risk scoring that combines liveness with fraud and velocity indicators
• Manual review or step-up controls for borderline cases

For identity programs that touch regulated onboarding, it is also important to map these checks to customer due diligence and fraud obligations. The FATF Recommendations — AML and KYC Framework provide the baseline expectation that firms understand who they are onboarding and can demonstrate controls proportionate to risk. Liveness helps support that objective, but it does not replace evidence of source integrity, binding, or anti-tamper controls. These controls tend to break down in mobile-first onboarding with legacy SDKs because the verification decision is made before the application can reliably attest to the capture environment.

Common Variations and Edge Cases

Tighter onboarding assurance often increases friction, so organisations have to balance fraud reduction against conversion loss and support overhead. That tradeoff becomes sharper when liveness is embedded in high-volume consumer flows, where small delays or extra prompts can materially affect completion rates.

There is no universal standard for how much liveness assurance is enough. Current guidance suggests adapting controls to the threat model: low-risk account creation may tolerate passive liveness plus fraud analytics, while regulated financial onboarding usually needs stronger evidence and clearer auditability. Edge cases include poor network conditions, accessibility constraints, and users with limited camera quality, all of which can produce false rejects and create pressure to loosen thresholds.

Another common mistake is assuming that stronger liveness thresholds solve deepfake or injection risk. They do not, especially when the attacker controls the endpoint or can proxy the session. The better pattern is to treat liveness as one input to an onboarding risk decision, then combine it with device binding, behavioural signals, and review workflows where the risk score or transaction context is unusual. For high-stakes identity journeys, best practice is evolving toward layered assurance rather than faith in a single biometric control.

Related resources from NHI Mgmt Group

• What do security teams get wrong about account-sharing detection?
• What do security teams get wrong about bot detection and fraud?
• What do security teams get wrong about kit-based phishing detection?
• What do security teams get wrong about threat detection in IAM?