What should teams do when some users cannot use the primary MFA method?

When a Primary MFA Method Does Not Fit Every User

A primary MFA method should be the default, not the only path. If some users lack the device, connectivity, or environment needed to complete it, teams should design a narrow exception flow in advance so access stays available without weakening the control for everyone else.

The practical goal is to preserve continuity while keeping the exception visible, bounded, and reviewable. A good fallback is temporary, authenticated, and more closely governed than the standard path, so the organisation can support edge cases without turning them into a permanent back door.

What the Alternate Path Should Actually Cover

The fallback path should be built for genuine edge cases, such as users without smartphones, users in low-connectivity environments, or users whose role or location makes the primary factor impractical. The point is not to add convenience everywhere, but to make sure the authentication design reflects how people actually work.

A well-designed alternate path still preserves assurance. For example, it can require stronger identity verification, a second enrollment step, a limited-duration exception, or a different phishing-resistant factor where available. That keeps the control aligned to risk, rather than forcing teams to choose between security and usability.

Teams should also decide whether the fallback is only for initial enrollment, for recovery, or for ongoing use. Those are different operational problems, and mixing them often creates avoidable drift: a one-time exception becomes a standing authentication norm.

How to Govern Exceptions Without Normalising Them

Exception handling works best when ownership is clear. Security, IAM, help desk, and system owners should know who can approve the exception, who can issue it, and who can revoke it. If nobody owns the path, it usually expands quietly and becomes harder to audit.

The fallback should be documented in a way that makes review possible: who qualifies, what evidence is required, how long it lasts, and what triggers revalidation. That governance matters because exception paths are often the first place attackers or careless operations teams look for weaker access controls.

MFA Guide is useful here because it compares common MFA methods and explains where bypass and enrollment weaknesses tend to appear. For rollout planning, Passwordless and Passkeys Guide helps teams think through phishing-resistant options and recovery design, while Workforce Identity Security Guide connects fallback access to broader sign-in, recovery, and lifecycle controls.

Risk and Threat Considerations

A fallback MFA path is a security control, but it is also a risk concentration point. If the exception flow is too broad, too long-lived, or too easy to request, it becomes the weakest authentication route in the environment and can attract abuse through social engineering, help-desk manipulation, or simple policy drift.

Failure mechanism: The primary control fails operationally when users who cannot meet the default MFA prerequisite are routed into an exception path that is not tightly scoped, time-limited, and reviewed. In that case, the exception starts behaving like a permanent alternate login method rather than a controlled workaround.

Impact: The organisation can preserve access but lose assurance, because the fallback path may have lower resistance to phishing, account recovery abuse, or unauthorised enrolment. At scale, that creates a predictable weak point for attackers and an audit problem for defenders.

Practitioner Guidance

What to verify: Confirm that the exception path requires stronger verification than the default path, not just a different one. The useful test is whether the fallback still resists impersonation, replay, and unauthorised self-service enrolment.

Decision rule: If the user cannot satisfy the primary MFA method for a documented reason, grant only the smallest workable exception, with an expiry date and a review trigger. If the exception would become the user’s everyday access path, redesign the primary method instead of relying on the fallback.

What good looks like: The fallback is rare, logged, time-bounded, and periodically revalidated. Teams can explain who approved it, why it existed, and when it was removed.

Practitioner takeaway: The right fallback does not make MFA optional, it makes the security model usable enough that people can still authenticate without turning exceptions into the real standard.

Related resources from NHI Mgmt Group

• How should IT teams troubleshoot when some users cannot access an on-site server while others can?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams handle SaaS offboarding when users also use AI tools?