The control becomes hard to trust because no one can tell whether spoof resistance was actually measured under defined conditions. In regulated onboarding, that means identity proofing may pass users without proving the system can resist presentation attacks. The result is assurance drift: security teams believe they have liveness coverage, but the evidence cannot support the trust decision.
Why marketing claims break assurance for biometric liveness
Biometric liveness is only useful when the claimed spoof resistance is tied to repeatable, accredited testing under defined attack conditions. Marketing language can describe intent, but it cannot tell you which presentation attacks were tested, what sensor setup was used, or whether the result holds across real onboarding devices and capture environments.
That gap matters because liveness is not a generic property, it is a measured control. If the evidence base is vague, teams may treat “liveness” as a binary feature when the real question is whether the specific implementation resists the attacks and operating conditions in scope for the onboarding decision.
What becomes unreliable in regulated identity proofing
In regulated onboarding, the failure is not just technical, it is decision quality. If the control is accepted on vendor claims alone, the identity proofing process may appear to satisfy an assurance requirement while never demonstrating that the system can resist presentation attacks at the assurance level being relied upon.
That creates a mismatch between control language and control evidence. Reviewers may sign off on a liveness capability, but the underlying proof may be no stronger than an unsupported product assertion. For programmes that must justify trust decisions later, that is a material weakness.
Accredited or otherwise independently verifiable testing gives practitioners a common basis to compare claims, but only if the test scope matches the real deployment. A model can be strong in a lab and still weak in the field if capture quality, camera diversity, lighting, latency, replay method, or operator workflow changes the attack surface.
Why assurance drift is the real operational failure
Assurance drift happens when a security label remains in place after the evidence behind it has decayed or was never strong enough to begin with. With biometric liveness, drift often starts when procurement accepts broad claims, operations inherit them, and no one revalidates the test basis against the current environment.
Once that happens, the organisation may keep relying on a control whose actual resistance is unknown. The practical result is false confidence: the control looks present in governance artefacts, but it cannot support a defensible trust decision when onboarding, audit, dispute handling, or fraud review depends on it.
One useful way to think about the problem is that liveness without accredited testing is a promise, not evidence. If the control is meant to reduce presentation-attack risk, then the proof must show what was tested, against which spoofing methods, under what conditions, and with what independent oversight.
Risk and Threat Considerations
When liveness claims are not backed by credible testing, the organisation may be exposed to spoofing, replay, and presentation attacks that slip through identity proofing. The immediate risk is control failure, but the larger risk is that downstream decisions are made on a trust assumption that cannot be defended.
Failure mechanism: The system is treated as spoof-resistant because of vendor messaging, while the actual evidence needed to confirm attack resistance, scope, and repeatability is missing or too weak to support the assurance claim.
Impact: Attackers can exploit that gap by submitting presentations that were never meaningfully evaluated, and the business can inherit onboarding, fraud, and audit exposure when a challenged identity decision cannot be shown to rest on tested control evidence.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Levels | Biometric liveness evidence affects the assurance used in identity proofing and onboarding. |
| Recommendation — Require tested evidence that the biometric control supports the assurance level being claimed. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Consumer or applicant onboarding depends on authenticating external users with reliable evidence. |
| IA-12 — Identity Proofing | Biometric liveness is part of proving a subject's identity during onboarding. | |
| Recommendation — Verify external-user authentication controls with evidence, not vendor assertions. Validate identity-proofing methods with independent testing and documented attack coverage. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Liveness claims rely on trustworthy authentication evidence and control verification. |
| Recommendation — Maintain evidence that authentication-related controls are tested and suitable for use. | ||
| GDPR | Art.9 — Processing of special categories of personal data | Biometrics used for unique identification fall under special-category data handling. |
| Recommendation — Assess biometric processing requirements and document lawful, proportionate safeguards. | ||
Practitioner Guidance
What to verify: Require the test basis, not just the marketing statement. You should be able to see the attack types covered, the capture conditions, the devices or sensors used, the decision thresholds, and whether testing was performed by an independent lab or other credible evaluator.
Decision rule: If a liveness product cannot show evidence of repeatable testing under conditions that resemble your onboarding flow, treat the claim as unverified and do not let it carry assurance on its own.
Practitioner takeaway: The right question is not whether a vendor says the liveness check works, it is whether the control has enough tested evidence to support the trust decision you are asking it to make.
Related resources from NHI Mgmt Group
- What breaks when autonomous vehicle testing relies on generic scenario generation instead of knowledge-based scenario mapping?
- Why do biometric systems that pass liveness testing still create risk?
- What breaks when compliance stays entity-based instead of activity-based?
- What breaks when password rotation is based on the calendar instead of risk events?