What do organisations get wrong about using fallback authentication with passwordless login?

A common mistake is treating passwordless deployment as secure even when weaker fallback paths remain enabled. If users can downgrade to SMS OTP or another phishable method, attackers will target that path and bypass the stronger control. Security teams should review Conditional Access policies, remove insecure fallbacks where possible, and test the full authentication journey, not just the preferred method.

Why This Matters for Security Teams

fallback authentication is where passwordless programmes often lose their security advantage. The preferred method may be phishing-resistant, but if users can still downgrade to SMS OTP, email links, or other weaker factors, attackers will target the easiest path instead of the strongest one. That turns “passwordless” into “passwordless unless bypassed,” which is a governance failure, not a feature gap. Current guidance in NIST SP 800-63 Digital Identity Guidelines is clear that authenticators are not interchangeable, and risk varies materially by method.

This matters because weak fallback paths are usually preserved for convenience, help desk recovery, or legacy compatibility, not because they are secure. Once attackers find that route, Conditional Access can be rendered irrelevant if policy only evaluates the primary login path. The same pattern appears in broader identity compromise cases, including the issues discussed in Twitter Source Code Breach, where access paths and trust assumptions mattered as much as the credentials themselves. In practice, many security teams discover the fallback problem only after an account takeover has already happened, rather than through intentional authentication testing.

How It Works in Practice

Secure passwordless design requires treating the entire authentication journey as one control surface. That means the primary authenticator, account recovery, step-up prompts, device re-enrolment, and help desk reset paths must all meet the same threat model. If one branch allows SMS OTP, knowledge-based verification, or a less protected email channel, the attacker simply shifts to that branch. The result is a policy gap, not a user error.

Practitioners should evaluate fallback paths against the security intent of the programme, then remove or harden anything that reintroduces phishing, SIM-swap, or social engineering risk. The baseline should align with NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement and recovery governance, while identity assurance choices should follow NIST SP 800-63 Digital Identity Guidelines. In practice, that usually means:

• Disabling insecure fallback methods where the business can tolerate stricter recovery.
• Requiring phishing-resistant recovery for privileged users and high-risk roles.
• Testing Conditional Access against every sign-in branch, not just the default path.
• Instrumenting help desk workflows so recovery events are logged, reviewed, and alertable.
• Using step-up checks that are equally strong across web, mobile, and support channels.

This is also where identity hygiene and breach lessons matter. NHIMG notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, which is a reminder that weak control paths are often the real attack surface. Passwordless only changes the outcome if the recovery and exception paths are equally disciplined. These controls tend to break down in hybrid estates where legacy directories, outsourced support, and multiple identity providers preserve inconsistent recovery rules.

Common Variations and Edge Cases

Tighter recovery controls often increase support burden, requiring organisations to balance user access continuity against phishing resistance and operational cost. That tradeoff is especially visible for executives, contractors, and remote workers who lose devices or cannot complete a high-friction recovery process. Current guidance suggests there is no universal standard for this yet, so the right answer depends on risk tolerance, assurance requirements, and business continuity needs.

One common edge case is allowing fallback for low-risk users while blocking it for privileged accounts. That can be reasonable if policy is explicit and monitored, but it becomes dangerous when exceptions spread informally. Another issue is mixing strong passwordless login with weak account recovery in a separate tenant, outsourced service desk, or legacy app that bypasses central policy. In those cases, the organisation may believe it has modern authentication while the actual break-glass path remains phishable. The lesson from NHIMG research and broader identity guidance is simple: if the fallback is weaker than the main control, attackers will eventually find it. The safest programmes remove fallback methods wherever possible and reserve exceptions for tightly governed, high-friction recovery only.

Related resources from NHI Mgmt Group

• What do organisations get wrong about using email authentication as a secure fallback?
• What do organisations get wrong about passwordless rollout in hybrid environments?
• What do security teams get wrong about passwordless authentication and AI risk?
• What do security teams get wrong about passwordless authentication?