How should organisations choose an MFA method that improves security without creating excessive user friction?

Why This Matters for Security Teams

Choosing MFA is not just a login preference question. It is a control design decision that affects phishing resistance, help desk load, recovery complexity, and whether users can actually complete authentication under real operating conditions. NIST guidance on digital identity and control selection treats authenticator strength and usability as linked concerns, not separate ones, because a theoretically strong method that users abandon creates weak outcomes in practice. Security teams also have to think about enrolment, device loss, accessibility, and fallback paths, or MFA becomes a gate that people work around.

The real risk is over-optimising for one dimension. SMS may feel easy but is weaker against interception and social engineering; some hardware-bound methods are stronger but create friction if device coverage is uneven. The right choice depends on who is signing in, from where, on what devices, and what failure modes the organisation can support without lowering assurance. NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the broader control context, while the Astrix Security & CSA research shows how often identity controls fail when visibility and operational discipline are poor. In practice, many security teams discover MFA weakness only after users start bypassing it to get work done, rather than through an intentional authentication review.

How It Works in Practice

The best MFA method is usually the one that gives you the highest phishing resistance with the least disruption in the environments you actually support. In most cases, that means preferring methods that bind the authentication event to the legitimate service and the legitimate device, rather than relying on codes that can be intercepted or relayed. Organisations should evaluate MFA against three operational questions: can it resist common attacks, can most users complete it without training, and can support teams recover safely when it fails?

A practical selection process looks like this:

• Use the strongest method the user base can adopt at scale, not the strongest method available in theory.
• Prefer phishing-resistant authenticators where the threat model includes credential theft, session hijacking, or social engineering.
• Ensure fallback and recovery paths are as controlled as primary sign-in, because weak recovery often becomes the real bypass.
• Test the method on shared devices, mobile-only users, contractors, and users with accessibility needs before broad rollout.
• Measure completion rates, help desk contacts, and abandon rates alongside incident reduction.

For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it forces teams to think about identity proofing, access enforcement, and authentication in a broader control system rather than as a single product choice. The Microsoft Midnight Blizzard breach is a reminder that identity compromise rarely stays isolated when authentication and recovery are not tightly governed. Good MFA design also reduces the need for frequent resets and exceptions, which means fewer opportunities for attackers to exploit support processes. These controls tend to break down in frontline, contractor-heavy, and BYOD environments because device diversity and uneven recovery options make one-size-fits-all MFA impractical.

Common Variations and Edge Cases

Tighter MFA often increases deployment and support overhead, so organisations have to balance phishing resistance against adoption friction and operational cost. There is no universal standard for the single “best” method, and current guidance suggests the right answer changes with user population and risk tier. High-risk administrative access, remote access, and sensitive applications usually justify stronger methods than low-risk internal tools, while broad workforce access often needs a more usable default with layered protections.

Edge cases matter. Users without reliable smartphones, regulated environments with restricted devices, and high-turnover workforces may make app-based or hardware-based MFA harder to scale. In those settings, the question is not whether to weaken security, but how to preserve assurance while reducing friction through better enrollment, improved recovery, or step-up authentication only when risk rises. Organisations should also avoid confusing convenience with resilience: a method that is faster at sign-in but easier to phish may increase total risk even if user complaints fall. Where accessibility is a concern, the goal is inclusive design, not a downgrade in assurance. That balance is often missed until exceptions accumulate and the MFA policy quietly turns into a set of inconsistent workarounds.

Related resources from NHI Mgmt Group

• How should organisations implement online passport verification without creating excessive customer friction?
• How should security teams reduce phishing risk in MFA without creating more user friction?
• How can organisations reduce fraud without creating excessive user friction?
• How should security teams implement MFA in regulated industries without creating audit gaps or user friction?