Prioritise authenticator apps over SMS, because SMS is easier to intercept and is a weaker second factor. Enforce MFA on every internet-facing account that supports it, and treat accounts without MFA as likely compromised over time. Pair that with password managers so users can generate unique credentials without reusing passwords, which reduces password spray and breach replay risk.
Choose stronger sign-in methods without making every login painful
The main trade-off is between resistance to phishing and recovery convenience. For user-facing email and web accounts, the strongest low-friction option is usually phishing-resistant MFA such as passkeys or security keys, because it removes the need to type a one-time code and reduces push fatigue and OTP relay exposure. NIST’s Digital Identity Guidelines are a useful benchmark for deciding when to move beyond weaker second factors.
Where passkeys are not yet practical for every user or app, authenticator apps are a better default than SMS. SMS can be intercepted, redirected through SIM-swap abuse, or captured through phishing, while app-based codes are less exposed to telecom takeover. That is why many organisations phase in stronger MFA by account type, starting with admin, finance, and externally exposed accounts before broadening to the full population.
The best user experience is not “more prompts”, it is fewer risky prompts combined with stronger, reusable sign-in methods. Password managers help here because they let users keep unique passwords without memorising them, which reduces password reuse, credential stuffing, and spray success. In practice, stronger MFA and unique passwords work together: MFA limits the value of a stolen password, and a password manager reduces how often that password is reused elsewhere.
Where MFA programs usually fail in practice
Strong MFA can still be bypassed when the implementation or recovery path is weak. The most common failure points are SMS codes, MFA fatigue prompts, help-desk resets, legacy accounts without MFA, and sessions or tokens that remain valid after the login event. Accounts that do not support MFA should be treated as higher risk by default, because they are much more likely to become the easiest path into email, SSO portals, and downstream business systems.
For email specifically, account takeover matters more than many teams first assume, because email is often the recovery channel for everything else. If attackers get mailbox access, they can reset passwords, intercept alerts, approve sign-in prompts, or search for existing sessions and tokens. The result is that the practical control boundary is not just the login screen, but also recovery, token lifetime, and admin override paths.
Organisations should also be careful not to equate “MFA enabled” with “MFA resilient”. A push prompt can still be defeated by social engineering, and a code-based flow can still be phished in real time. That is why phishing-resistant methods are increasingly preferred for higher-value accounts, and why account recovery needs to be designed with the same discipline as initial authentication.
Rollout patterns that improve security without raising friction too far
Start by segmenting accounts by risk and business impact. Require the strongest available MFA for administrators, finance, support staff, and anyone with access to customer data or privileged systems, then extend the policy to all internet-facing accounts. Use step-up authentication only for sensitive actions when the business process allows it, so users are not re-challenged for every routine interaction.
Pair MFA rollout with a sign-in policy that is easy to understand and easy to support. Users need a small set of approved methods, clear recovery rules, and a default path that works across devices. NHIMG’s Workforce Identity Security Guide is a useful companion for deciding how phishing-resistant MFA, passkeys, recovery, and session theft controls fit together. For organisations evaluating platforms, the IAM and Identity Provider Buyer's Guide helps compare MFA and SSO options against the user experience you actually want to deliver.
Recovery deserves explicit design attention. If users can easily bypass MFA through weak self-service reset flows or unmanaged help-desk procedures, the organisation has only shifted the problem rather than solved it. The practical goal is to make the strong path the easiest path, while making recovery possible but well-verified.
Risk and Threat Considerations
Weak MFA choices create disproportionate exposure because email and web accounts are often the entry point to resets, SSO, and downstream systems. SMS, fatigue-based approvals, and weak recovery flows are especially attractive because they preserve the illusion of protection while still leaving a viable attack path.
Failure mechanism: Attackers intercept or socially engineer the second factor, then use mailbox or web access to pivot into password resets, session theft, or privileged actions. Where accounts do not support MFA, the failure mode is simply delayed compromise through password spraying, credential stuffing, or breach replay.
Impact: A single account takeover can cascade into wider compromise, especially when the mailbox or web account is tied to account recovery, customer data, or privileged administration. The operational cost is usually higher than the initial sign-in incident because response must cover sessions, tokens, resets, and related accounts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant MFA and authenticator choice directly shape sign-in assurance. |
| Recommendation — Use phishing-resistant authenticators and align assurance level to account risk. | ||
| CIS Controls v8 | 5 — Account Management | MFA rollout and account coverage depend on disciplined account lifecycle and access policy. |
| 6 — Access Control Management | Least-privilege access and recovery paths must support stronger authentication without excess friction. | |
| Recommendation — Enforce MFA coverage and remove accounts that cannot meet required access policy. Limit access paths and tighten recovery so MFA cannot be bypassed easily. | ||
Practitioner Guidance
What to prioritise: Move high-risk and externally exposed accounts to phishing-resistant MFA first, then standardise on authenticator apps or passkeys for the broader workforce. Treat SMS as a fallback, not a target state, and reserve exceptions for cases with a documented business constraint.
What to verify: Check whether recovery, help-desk resets, and legacy apps undermine the MFA policy. If users can regain access through weaker checks than the login flow itself, the control is not yet coherent.
Common mistake: Teams often focus on the second factor and ignore password quality and reuse. Password managers materially reduce friction, because they let you tighten MFA without forcing users back to memorable but weak passwords.
Practitioner takeaway: The best MFA program is the one users can actually complete every day, but attackers cannot realistically bypass through phishing, SMS interception, or recovery abuse.
Related resources from NHI Mgmt Group
- How should organisations use MFA within a Zero Trust model to protect remote access without creating too much user friction?
- How should small businesses implement MFA without creating too much user friction?
- How should organisations use active liveness detection to reduce biometric fraud without adding too much user friction?
- How should organisations build a cybersecurity-first culture without creating too much user friction?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
