Teams should design fallback paths that preserve the assurance level required for the use case, not just user convenience. That means testing PIN, device-based, and recovery routes against the same risk threshold as the biometric path, so the wallet remains usable without weakening identity assurance.
How fallback paths should be designed when biometrics are restricted
When biometrics are unavailable or restricted, the fallback is not a convenience feature, it is part of the assurance model. Good design keeps the alternative path aligned with the same trust assumptions as the biometric path, so a user can recover access without silently reducing the security of the wallet, account, or transaction flow.
What a fallback path must preserve
The key design question is not whether the backup method works, but whether it proves enough about the same person, device, or entitlement context the biometric was meant to support. A PIN can be acceptable in some flows, but only when it is protected by strong retry limits, device binding, or other compensating controls that keep the overall assurance level acceptable.
A recovery route also needs a clear boundary between assurance level and convenience. If the fallback is easier to use than the biometric path, attackers will target it first, so the team should treat the backup as a formally assessed control, not a user-experience shortcut.
Which fallback patterns are usually safest
The safest fallback is usually the one that adds independent evidence rather than simply replacing the biometric with a weaker single factor. In practice that often means a device-based recovery route, a time-bound recovery code, or a step-up flow that combines possession of a trusted device with another factor before granting the same action set.
Where the wallet or application supports multiple recovery methods, each one should be tested for equivalence against the same threat model. The strongest option is usually the one that limits what the user can do until the system has enough confidence to restore full access, rather than immediately restoring every privileged function.
This is where GDPR becomes relevant if biometric data is being processed, because restricted biometric use often goes hand in hand with data minimisation, purpose limitation, and privacy-by-design choices that affect which backup route is acceptable. For EU digital identity wallets, eIDAS 2.0 also matters because fallback design must not undermine the trust expected of the wallet ecosystem.
Risk and Threat Considerations
Fallback paths are a common downgrade target because attackers prefer the easiest route around a stronger primary authenticator. If the alternative path is under-tested, over-permissive, or weakly rate-limited, it can become the real point of compromise even when the biometric control itself is sound.
Failure mechanism: The fallback grants access with lower assurance than the biometric path, or it restores high-value actions after only minimal verification. That creates an attack path through PIN guessing, device theft, account recovery abuse, or social engineering of support workflows.
Impact: The wallet or account may remain usable, but the assurance model is degraded, which can lead to unauthorised access, recovery abuse, and loss of trust in the original biometric control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022, GDPR and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Fallback access still must prove user identity to an acceptable assurance level. |
| IA-5 — Authenticator Management | Recovery codes, PINs, and device-bound secrets need lifecycle and protection controls. | |
| AC-6 — Least Privilege | Fallback routes should limit privileges when full biometric assurance is unavailable. | |
| Recommendation — Require the fallback path to authenticate users with controls that preserve the system's assurance target. Protect, rotate, and revoke recovery authenticators with the same discipline as primary credentials. Restrict fallback sessions to the minimum actions needed until stronger verification completes. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Assurance levels and step-up rules directly inform how strong a restricted biometric fallback must be. |
| Recommendation — Use assurance guidance to align fallback methods with the risk of the protected transaction. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Fallback paths are access-control decisions that must preserve authorised access boundaries. |
| Recommendation — Define and enforce fallback access rules that do not weaken the approved access model. | ||
| GDPR | Art.25 — Data protection by design and by default | Biometric restrictions and recovery design should reflect privacy-by-design choices. |
| Recommendation — Build fallback flows so they minimise biometric exposure and still meet security requirements. | ||
| EU AI Act | High-risk AI system governance | When biometric decisioning is part of an AI-enabled identity flow, fallback governance must preserve human oversight and reliability. |
| Recommendation — Document fallback behaviour and oversight where AI-assisted biometric decisions affect identity assurance. | ||
Practitioner Guidance
What to prioritise: Treat fallback design as a risk-equivalence problem. If the biometric path protects high-value actions, the fallback should either match that assurance or explicitly limit the actions available until stronger evidence is obtained.
What to verify: Test every recovery route against brute force, account takeover, device loss, and support escalation scenarios. Verify that retry limits, lockouts, step-up checks, and recovery approvals still hold under realistic attack pressure.
Decision rule: If the fallback cannot preserve the same risk threshold, narrow its scope rather than broadening it. Restrict what the user can do, shorten the recovery window, or require additional verification before restoring privileged access.
Practitioner takeaway: The right fallback is the one that preserves assurance under failure, not the one that merely gets users back in fastest.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org