Biometric failure needs a non-biometric fallback
Aliases: fingerprint fail · Face ID fallback · sensor error
What it is
Sensors fail: wet fingers, bad light, a mask, a system timeout, hardware briefly gone. A non-biometric fallback means that after this failure, the person can still finish the same action with a device passcode, app password, passkey, or an already-signed-in session, and is not left in a “try the fingerprint again” loop. This entry is about a way out of this attempt. It is not about people who cannot enroll a biometric at all, and it does not judge whether the fallback is weaker than the primary path.
Why it happens
Biometrics treat “present a body” as a fast path, but matching is probabilistic; environment swings false negatives. If the UI only offers retry, people read failure as their fault, mash the sensor, and burn tries until the system locks them into a longer cooldown. Failure is not “never enrolled”: a template is assumed to exist and this attempt did not match. Fallback must be reachable as soon as failure is observable, and must be another authenticator for the same intent—not Cancel back to home with the task gone. Mobile platforms usually treat biometrics as a proxy for device unlock; if the app swallows the system failure and shows only a custom retry, it has turned off the device-passcode exit the OS already offered.
Studying it
In environments that induce failure (wet hands, dark, occlusion), compare “retry only” with “fallback after failure,” and see whether the task still completes.
Independent variables: when fallback appears after failure (immediately, after N fails, after cooldown lock), fallback type, whether custom UI covers the system fallback. Dependent variables: task completion after biometric failure, wasted retries, support contacts caused by lockout.
Lab fingers and lighting are often ideal; scripts must force failure. Biometric success rate is the sensor, not the fallback. Human studies should record whether people can find the fallback, not whether they “like fingerprints.”
Where it stops holding
Payments and high-assurance actions may force a stronger check after several failures; a fallback must still exist, even if it is longer. If the device has no non-biometric credential enrolled, the app cannot invent one; it can only send the person to system settings to add one, and allow deferring the current action. Offline, a fallback that needs a network password is less available than the biometric; prefer the local device passcode. “Maybe later” is delay, not authentication.
Applying it
- After a biometric failure, offer a non-biometric entry on the same screen (“use device passcode / use sign-in password”); do not show retry alone.
- Honor the system’s failure and fallback; do not cover “enter passcode” with a full-screen custom animation.
- When consecutive failures enter cooldown, put the fallback beside the cooldown copy: biometrics are briefly unavailable, the other path is still open.
- Verify by forcing failure with wet hands or occlusion: someone uninvolved in the design should finish the original action without reinstalling or killing the process. Check that custom UI does not cover the system fallback. Report eventual completion among biometric-failed sessions, not one-shot biometric pass rate.