Presentation attacks exploit the fact that facial recognition often matches visible markers rather than proving a real person is present. A photo, screen replay, or mask can satisfy those markers and create a false identity. This increases fraud risk in onboarding because attackers can impersonate users before downstream controls detect the deception.
Why presentation attacks matter during facial onboarding
Presentation attacks matter because onboarding is the point where a system decides whether a face corresponds to a real, eligible person. If that decision is based only on visible facial markers, then the control is confirming resemblance rather than presence. That distinction is important in regulated onboarding, where the business outcome depends on trust in the person being enrolled, not just a successful match.
For facial recognition workflows, the risk is not limited to a bad match score. It is the possibility that the onboarding process accepts a camera-facing artefact as if it were a live human subject, allowing fraud, account takeovers at creation time, or synthetic identity construction to begin before stronger checks engage. The issue is especially acute when teams assume that face matching alone satisfies identity assurance without testing whether the capture path resists replay or impersonation. For the broader identity assurance context, NIST’s Digital Identity Guidelines are the clearest reference point for understanding why proofing and authentication are not the same control. In practice, many teams discover the weakness only after a fraud review reveals that a convincing image, video, or mask was enough to pass the front door.
How presentation attacks break the onboarding decision
Presentation attacks exploit the gap between facial similarity and liveness. A face verifier may compare geometry, texture, or embeddings against an enrolled reference, but a presentation attack aims to satisfy those checks with an artefact that is not a genuine live subject. Common examples include printed photos, screen replays, and 3D masks, but the control problem is broader than the object used. Any onboarding process that trusts the camera stream without proving freshness, context, or user presence can be manipulated.
In practice, the failure usually appears at one of three points. First, capture quality may be high enough for the image to look authentic to the algorithm. Second, the workflow may not bind the face check to a strong source of identity evidence, so the attacker only needs to defeat the biometric step. Third, operations teams may treat a biometric match as inherently proof-grade, even though biometric matching is best understood as one signal among several. Where the onboarding journey includes document review, device signals, or challenge steps, those controls need to be designed to make replay materially harder rather than simply adding friction after the fact.
Strong onboarding designs therefore focus on attack resistance, not just recognition accuracy. They ask whether the capture session is live, whether the sample is being reused, whether the process is vulnerable to presentation artefacts, and whether the business can still distinguish a real applicant from an impostor if the face check is bypassed. That is why liveness testing, fraud analytics, and proofing controls have to work together instead of being treated as separate compliance boxes. The operational lesson is that a facial match can support onboarding, but it cannot by itself establish identity assurance when the capture channel is adversarial.
- Use freshness and replay resistance to make reused images harder to submit.
- Bind facial capture to the wider proofing workflow so one biometric result cannot carry the decision alone.
- Treat false acceptance as an onboarding fraud condition, not just a model-performance issue.
Where the onboarding workflow has weak capture controls, no independent evidence, and high-value account creation, the guidance breaks down because the system is only verifying that something face-like appeared in front of a camera.
Where liveness checks help, and where they still fall short
Tighter onboarding controls often improve fraud resistance, but they also add friction, cost, and failure modes for legitimate users. That tradeoff matters because some anti-spoofing methods are strong against casual replay attacks yet weaker against better-resourced deception, while others are robust but produce more false rejections. There is no single consensus method that eliminates presentation attacks in all conditions, so practitioners should treat liveness as risk reduction rather than proof of authenticity.
Edge cases matter most when the capture environment is inconsistent. Low light, poor cameras, accessibility constraints, or remote onboarding at scale can all reduce signal quality and make the system more dependent on imperfect heuristics. This is where teams often overestimate what a score threshold can tell them. A high similarity score does not tell you whether the subject is present, and a low score does not necessarily prove fraud. The strongest programs separate the question of “does this face match?” from “is this a live person in front of the device?” and then decide how much residual risk they can accept for each onboarding tier.
If a workflow supports high-value financial access, regulated customer creation, or later step-up authentication, presentation attack resistance should be validated with the same seriousness as the proofing decision itself. If the process is used for low-risk enrolment, the control may be lighter, but only if the downstream impact of a false identity is also limited.
Risk and Threat Considerations
Presentation attacks create a direct fraud and identity assurance risk because they exploit the trust boundary at the point of enrolment. The attacker’s objective is to get a non-live or impersonated subject accepted as a legitimate applicant so the false identity can be used for account creation, mule activity, or future abuse.
Failure mechanism: The control fails when the onboarding system treats facial resemblance as sufficient evidence of presence or personhood, especially if the sample can be replayed, displayed, or physically replicated without freshness checks or independent proofing.
Impact: The organisation may onboard fraudulent accounts, weaken KYC confidence, create downstream recovery problems, and lose the ability to rely on facial recognition as a trust signal for later access decisions.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Onboarding risk hinges on proving a real person, not just matching a face. |
| AAL — Authenticator Assurance Level | Presentation attacks expose the gap between a biometric check and trustworthy authentication. | |
| Recommendation — Set the required identity assurance level before relying on facial evidence alone. Separate biometric matching from the assurance needed to trust the enrolment result. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Facial onboarding is an identity assurance control that affects access trust. |
| Recommendation — Use identity and access controls to prevent weak onboarding from becoming a standing trust path. | ||
| CIS Controls v8 | 5 — Account Management | Fraudulent onboarding creates untrusted accounts that must be governed from creation onward. |
| 6 — Access Control Management | Spoofed enrolment can grant access that should never have been issued. | |
| Recommendation — Require stronger review for account creation paths that can be abused by spoofed onboarding. Tighten access issuance so a failed proofing step cannot become authorised access. | ||
Practitioner Guidance
What to prioritise: Treat the onboarding decision as an assurance problem, not a model-accuracy problem. The key question is whether the process can distinguish a live applicant from a convincing artefact before any account is issued.
What to verify: Confirm that the biometric step is paired with independent identity evidence and replay-resistant capture, and that false accepts are reviewed as fraud events rather than only as system tuning issues.
What good looks like: A mature workflow uses face recognition as one input, not the deciding proof, and the residual risk is explicitly different for low-impact versus high-impact enrolments.
Practitioner takeaway: The main mistake is assuming facial recognition proves presence when it often proves only similarity; onboarding becomes safer only when the face check is embedded inside a broader proofing design that can absorb spoofing attempts.
Related resources from NHI Mgmt Group
- Why do browser-based attacks create extra risk for NHI and human identity programmes?
- Why do GitHub-based supply chain attacks create identity risk for cloud environments?
- Why do browser-based identity attacks create more risk than browser exploitation in many enterprises?
- Why do identity-based attacks create more risk than simple endpoint compromise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
