An alternative path that lets a legitimate user complete an identity process when the primary control cannot be used. For biometric systems, fallback design is part of security and service continuity, not an exception to be solved later.
What a fallback journey is
A fallback journey is the designed alternate route a user can take when the primary identity or authentication control is unavailable, such as a failed biometric scan, an inaccessible device, or a temporarily degraded verification service. In mature systems, it is a normal part of the security design, not a shortcut added after launch.
Why fallback journeys matter in identity systems
Fallback journeys preserve continuity when the main path cannot be completed, but they also change the assurance profile of the process. The moment a user is routed away from the primary control, the system must still decide how to preserve confidence in the person, the session, and the transaction without creating an easier bypass.
This is especially important in biometric authentication, where the fallback must balance usability, fraud resistance, and accessibility. A good fallback journey keeps the experience usable for legitimate users while preventing the alternate route from becoming the weakest path in the whole identity flow.
Common fallback journey patterns
Fallback journeys usually include a smaller set of carefully chosen alternatives, such as a secondary factor, recovery code, help desk assisted verification, document-based recovery, or a controlled step-up process. The right pattern depends on the sensitivity of the transaction, the trust already established, and the consequences of an incorrect recovery decision.
Not every fallback should be equally powerful. For example, recovering a password is not the same as recovering access to a high-value account or re-enrolling a biometric factor. The more sensitive the identity event, the more important it is to make the alternate path specific, auditable, and resistant to social engineering.
Design principles for secure and usable fallback journeys
A secure fallback journey should be explicit, limited, and easy to understand. It should avoid ambiguous “try something else” behavior that leaves users and operators guessing which path is authoritative or which assurance level has been met.
Strong designs also treat fallback as part of the core service lifecycle. That means testing degraded conditions, defining who can approve exceptions, and ensuring the alternate route does not silently create weaker access than the primary journey would have allowed.
Risk and Threat Considerations
Fallback journeys create risk when the alternate route is easier to abuse than the primary control. Attackers often target recovery and exception paths because they may rely on weaker verification, operator discretion, or user confusion rather than the main authentication mechanism.
Failure mechanism: A fallback path can become a bypass if it is less stringent than the primary journey, if it is inconsistently applied, or if it allows an attacker to exploit support processes, recovery codes, or weak step-up checks.
Impact: Compromised fallback paths can lead to account takeover, fraudulent enrollment, unauthorized access, or loss of trust in the identity system, even when the primary control itself remains strong.
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 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Fallback journeys often depend on recovery authenticators and controlled reset of access material. |
| IA-2 — Identification and Authentication (Organizational Users) | Fallback journeys sit inside the authentication process for users who cannot complete the primary path. | |
| AC-2 — Account Management | Fallback journeys affect account recovery, exception handling, and access restoration decisions. | |
| Recommendation — Require controlled authenticator lifecycle handling so recovery paths do not weaken identity assurance. Define alternate authentication methods that preserve the required assurance level for user access. Govern recovery and restoration workflows so account access is re-established only through approved processes. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The guidelines address identity proofing, authentication, and recovery considerations for digital identity journeys. |
| Recommendation — Align recovery and fallback paths to the assurance level required for the identity event. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Fallback journeys often rely on recovery secrets, codes, or other authentication information. |
| A.5.15 — Access control | Fallback journeys are an access-control design choice that governs how alternate access is granted. | |
| Recommendation — Protect recovery materials so alternate access paths cannot be abused. Specify fallback access rules so exceptions remain controlled and reviewable. | ||
Practitioner Guidance
Why practitioners should care: Fallback journeys are part of the assurance boundary, so they need the same design attention as the primary control. If the alternate path is poorly defined, it can undermine the entire identity process.
Governance implication: Treat fallback as a documented control path with ownership, approval rules, and review criteria. The key question is not just whether users can recover, but whether recovery preserves the intended level of trust.
Practitioner takeaway: Design the fallback journey as a controlled security decision, not as an emergency convenience layer, and test it under real failure conditions before relying on it in production.