The fallback must not be weaker than the primary path
Aliases: biometric downgrade · fallback assurance · skip fingerprint
What it is
When the primary path uses biometrics at the assurance of device unlock or a platform authenticator, a neighbor that says “use an SMS code,” “just skip,” or “email OTP is enough” lets an attacker skip the sensor and shove the person into the fallback. Fallback must not be weaker means the substitute authenticator’s assurance is not below the action the primary path was guarding. This entry judges fallback strength. It does not argue whether a way out must exist after failure, and it does not discuss who cannot enroll.
Why it happens
Attackers pick the weakest open door. Biometric failure and lockout can be induced (occlusion, repeated fails); if the fallback is a short SMS code or “remembered device, come in,” inducing failure becomes a downgrade. Platform biometrics usually bind to a device passcode or secure hardware; an app’s homemade “face snapshot” plus email OTP looks advanced while assurance stops at the mailbox. Strength must align to the action: viewing a balance and moving funds are not the same demand. Allowing a biometric shortcut to view, while fallback can transfer, puts a weak door on a strong action. Backup factors in MFA are pre-enrolled second factors; fallback here is a substitute for the biometric door. They are not the same “anyway there is a backup.”
Studying it
Walk the threat: after inducing biometric failure, can fallback alone complete a high-consequence action.
Independent variables: fallback authenticator (device passcode, app password, SMS OTP, email link only, skip with no authentication), assurance the action needs. Dependent variables: whether transfer or password change still completes after induced failure, how often fallback is chosen, whether people judge “SMS is as safe as the fingerprint.”
Do not use completion rate as strength. A usable-security setup can give a second person the phone without the biometric template and watch whether fallback hands over the account. Talk assurance in NIST-style authenticator tiers (allowed / restricted); do not invent “how many percent weaker.”
Where it stops holding
A device passcode as the OS-designated fallback for platform biometrics is usually at the same level, because the template’s key is that passcode. If the app uses biometrics only as a local shortcut and a server session already exists, fallback strength should match session protection, not a fresh remote authentication. Accessibility requires a non-biometric path; that is not “skip authentication.” An app password, passkey, or hardware key can be reachable without downgrade. Emergency account recovery via human review is a third road: latency and review should exceed everyday fallback, not become a standing weak door for sign-in.
Applying it
- For each action guarded by biometrics, write acceptable fallback authenticators; SMS OTP, email-only, and skip must not alone cover password change, rebinding, or funds.
- Prefer the system device passcode or a platform passkey as fallback, rather than inventing a shorter in-app code.
- Avoid copy that sells downgrade as convenience (“failed? SMS is easier”).
- Verify by listing biometric-guarded actions and their fallbacks, and finding combinations that drop a tier. Walk “occlude the sensor → fallback” and check that high-consequence actions still demand proof at the primary path’s level. Let someone who holds the phone but not the biometric template try fallback, and record whether password change or transfer completes.