They should test whether the control rejects emulators, virtual camera feeds, replayed sessions, and injected synthetic video under realistic fraud tooling. A useful liveness control must fail closed when the capture path is manipulated, not just when the face is poor quality. Lab validation and red-team testing are stronger signals than vendor claims alone.
What “working” means for a liveness control
A liveness control is only useful if it detects presentation attacks against the capture path, not just bad image quality. For banks, that means the control has to distinguish a real live capture from manipulated inputs such as emulator output, virtual camera feeds, replayed sessions, and synthetic video injected into the pipeline.
The practical test is whether the control fails closed when the signal is being spoofed. A system that merely scores a face as clear, bright, or well framed can still accept fraud tooling if it does not verify the integrity of the capture channel itself.
How to validate it under fraud conditions
Validation should move beyond vendor demos and into controlled abuse testing. Banks should run the liveness flow with realistic fraud tooling that attempts to replay prior captures, present video through a virtual camera, or feed in generated footage while preserving the normal user journey as much as possible.
That test should include both lab validation and red-team style scenarios. The key question is not whether the model responds to obvious defects, but whether it rejects manipulated inputs while still allowing legitimate users through at an acceptable rate.
A useful validation program also checks the control boundary. If liveness only works in a clean lab app but fails when the browser, device stack, or camera source is mediated, then the control is weaker than the assurance claim suggests.
What banks should look for in the result
Strong evidence comes from repeatable negative cases: known emulators rejected, virtual camera paths blocked, replayed sessions detected, and synthetic video denied even when the face appears realistic. Banks should also watch for control drift after software updates, device changes, or vendor model refreshes, because those are common points where spoof resistance quietly degrades.
A control is not proven by one successful fraud attempt being stopped. It is proven when the same class of manipulation is consistently rejected across devices, channels, and operating conditions, and when exception handling does not create an easier fallback path.
Risk and Threat Considerations
Weak liveness controls create a direct onboarding and account takeover risk because they can be satisfied by manipulated media rather than a live person. Attackers do not need to defeat the face matcher if they can feed the system a trusted-looking stream that the control mistakenly treats as live.
Failure mechanism: The capture path is manipulated through replay, emulation, synthetic generation, or virtual camera injection, while the liveness check only evaluates visual plausibility and misses the spoofed source.
Impact: Fraudsters can pass remote identity checks, open accounts, take over sessions, or bypass step-up verification, which increases downstream fraud loss and weakens trust in the onboarding control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Liveness depends on resisting spoofed authenticator flows and capture-path abuse. |
| IA-2 — Identification and Authentication (Organizational Users) | Banks need assurance that remote identity proofing and authentication resist impostor submissions. | |
| SI-3 — Malicious Code Protection | Synthetic injection and manipulated media are abuse conditions that controls must detect or block. | |
| Recommendation — Test authenticator workflows against replay and injection abuse, then tighten lifecycle and verification checks. Verify identity flows under realistic spoofing attempts before trusting production enrollment. Add detection and blocking for manipulated inputs and validate it with adversarial testing. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Weak liveness can enable unauthorized access and account takeover through impersonation. |
| Recommendation — Validate that access decisions are not granted when the capture channel is spoofed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Liveness is part of access assurance when it gates account opening or step-up authentication. |
| Recommendation — Require spoof-resistant verification before granting high-trust access. | ||
Practitioner Guidance
What to verify: Test the liveness control against spoofing methods that reflect current fraud tooling, not just canned sample videos. Verify that rejection occurs because the input path is untrusted or manipulated, not merely because the image quality is poor.
What good looks like: Legitimate users pass consistently, but replayed, emulated, and injected streams fail with clear telemetry that helps distinguish genuine friction from an attack condition. Banks should be able to show that the control is anchored in capture integrity, not cosmetic image checks.
Practitioner takeaway: Treat liveness as a fraud-resistance control, not a visual quality filter; if you cannot demonstrate rejection under manipulated capture conditions, you do not yet have meaningful assurance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org