1:1 face match
Confirm the person requesting recovery matches the account’s enrolled face template.
Before resetting a password or approving a high-risk action, confirm it’s really the enrolled user asking – with a fast face-and-liveness check instead of a security question an attacker might already know the answer to.
Confirm the person requesting recovery matches the account’s enrolled face template.
Ensure a real, present person is completing the check, not a photo of the account owner.
Require this check only for high-risk actions, layered on top of existing authentication.
Account recovery is a favorite target for attackers precisely because it’s designed to be an exception path – a way back in when the normal credential is lost. Security questions and recovery emails are both commonly compromised or guessable, which is why step-up identity checks at this exact moment matter so much.
FacePlugin lets you require a face-and-liveness match against the user’s previously enrolled template before approving a password reset, a device change, or any other high-risk action – the same core capability used for everyday biometric sign-in, applied specifically to the recovery and step-up moment. See the biometric authentication page for the broader authentication use case this builds on.
Licensed once, run on infrastructure you control, with no per-check fees.
Confirm the person requesting recovery matches the account’s enrolled face template.
Ensure a real, present person is completing the check, not a photo of the account owner.
Require this check only for high-risk actions, layered on top of existing authentication.
A password reset, device change, or other high-risk action triggers the step-up check.
The user presents their face, which is matched against their enrolled template.
A passing match-and-liveness result lets your application proceed; a failed one can route to manual review.
This page focuses specifically on the recovery and step-up scenario; the biometric authentication page covers passwordless sign-in and multi-factor use more broadly.
That’s your application’s decision – FacePlugin returns a structured match-and-liveness result, and your own account-recovery policy decides whether a failed check blocks the request, requires a fallback method, or routes to manual support review.
Yes – this flow verifies a fresh capture against a previously stored template, so a face must have been enrolled at some earlier point, typically at account creation or first login.
Talk to our team about your workflow — we’ll point you to the right SDK combination and get a 15-day evaluation license started.