Start with the standard, then inspect the evidence. Require ISO/IEC 30107-3 testing, confirm the lab was independent and accredited, and review the reported APCER and BPCER values in the context of your risk tolerance and onboarding flow. That approach turns a vendor claim into an auditable control decision.
How to judge a liveness solution before you trust the result
For regulated identity proofing, the question is not whether a vendor says it has “liveness.” The real test is whether the evidence matches the assurance level you need, the attack model you expect, and the onboarding journey you actually run. A good evaluation starts with the standard, then verifies the lab, the test method, and the reported error rates.
A liveness claim only becomes useful when you can trace it to a recognised presentation attack detection test and understand what the score means for your population, device mix, and channel design. That is why the test context matters as much as the headline percentage.
Teams should ask whether the solution was evaluated against NIST SP 800-63 Digital Identity Guidelines aligned expectations and whether the vendor can point to the specific biometric presentation attack testing basis behind the claim. If the answer is vague, the metric is not ready for procurement or audit use.
What the test evidence should actually tell you
In practice, the most useful evidence is not a marketing summary but a structured test report that names the test standard, the sample conditions, the attack instruments or presentation types, and the operating point used to produce the published APCER and BPCER figures. Those values are only meaningful when you know whether they were measured on the same capture conditions, demographics, lighting, camera types, and user journey you intend to deploy.
Independent evaluation also matters. If the lab is not independent and accredited, you do not really know whether the results are reproducible, whether the protocol was followed strictly, or whether the test environment was designed to flatter the product. For regulated proofing, that independence is part of the assurance case, not a nice-to-have detail.
For a broader control view, teams can anchor this review to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the identification, authentication, audit, and control integrity expectations that make proofing evidence defensible. Where proofing is part of a cloud-hosted or outsourced identity stack, the same control logic should be reflected in supplier assurance and operational monitoring.
The key practical question is whether the lab result predicts your real onboarding risk. A low APCER is helpful only if the system still performs acceptably when the attack is delivered through your actual channel, not an idealized demo flow.
How to translate scores into an onboarding decision
APCER and BPCER should be treated as decision inputs, not absolute verdicts. APCER tells you how often attack presentations succeed, while BPCER tells you how often legitimate users are rejected. In a regulated environment, the right balance depends on what failure costs more in your flow: letting an impostor through, or creating enough friction that real applicants abandon the journey or fail out unfairly.
This is where onboarding design matters. A remote proofing step with human review, step-up controls, or fallback collection can absorb some false rejects. A fully automated straight-through journey cannot. The acceptable threshold is therefore not just a vendor property, it is a product and policy choice.
Teams evaluating identity proofing can also benefit from the practical evidence collected in Identity Proofing and KYC Guide, which maps liveness, document checks, and injection-style attacks to real account-opening fraud patterns. That makes it easier to judge whether a result is strong enough for a remote onboarding channel rather than only for a controlled lab benchmark.
Where onboarding is part of a wider regulated identity stack, Ultimate Guide to NHIs, Standards is also useful as a control-navigation reference for the surrounding identity security posture, but the liveness decision itself still rests on proofing evidence, not on adjacent identity controls.
Risk and Threat Considerations
Liveness is attractive to attackers because it sits at the point where a person becomes a trusted account holder. If the control is weak, a spoofed face, injected video, synthetic image, or replayed capture can turn a fake applicant into a verified identity with downstream access, payment, or compliance consequences.
Failure mechanism: the control fails when the test method does not reflect the attacker’s actual presentation technique, the capture environment is less constrained than the lab, or the score threshold is tuned too permissively for conversion pressure.
Impact: organisations may approve synthetic or impersonated identities, increase account-opening fraud exposure, and create audit findings if the proofing evidence cannot justify the assurance decision.
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 SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance expectations for regulated identity proofing and liveness evidence. |
| Recommendation — Use the relevant proofing and assurance guidance to set acceptance criteria for liveness evidence. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Applies when regulated identity proofing establishes external user identity for access decisions. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports retaining and reviewing proofing evidence for auditability and challenge. | |
| Recommendation — Require identity proofing evidence that supports external user authentication and onboarding controls. Retain liveness test evidence and review it as part of audit and control validation. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Applies when the liveness solution is a third-party service and its assurance must be governed. |
| Recommendation — Assess the provider’s testing, accreditation, and evidence obligations in supplier governance. | ||
| OWASP ASVS | V6 — Authentication | Authentication assurance depends on robust proofing and anti-spoofing evidence before login. |
| Recommendation — Verify that proofing strength matches the authentication assurance required by the application. | ||
Practitioner Guidance
What to verify: require the exact test standard, the lab’s independence and accreditation, the attack presentation types, and the operating threshold used to derive APCER and BPCER. Do not accept a summary slide without the underlying protocol and test scope.
Decision rule: if the evidence does not show how the published scores map to your channel, device mix, and onboarding flow, treat the result as exploratory only. If the vendor cannot explain the false-accept versus false-reject trade-off in business terms, the control is not ready for a regulated rollout.
Practitioner takeaway: a strong liveness decision is an assurance decision, not a product-feature decision, so the evidence must be specific enough to survive audit, challenge, and real-world attack conditions.
Related resources from NHI Mgmt Group
- How should regulated teams evaluate cloud-private identity governance platforms?
- How should security teams evaluate cloud identity tools in regulated environments?
- How should security teams evaluate an identity solution in a fast-changing cloud stack?
- Should financial teams treat liveness as part of identity proofing or fraud prevention?