Organisations should make MFA easy enough that users accept it, while still verifying more than one factor at login. The practical goal is to combine something known, something possessed, and context such as device or location when risk is higher. If the process is cumbersome, users work around it. Usable MFA and single sign-on improve adoption and reduce unsafe shortcuts.
Design MFA Around Friction That Users Will Accept
The main design problem is not proving that MFA works in the abstract, it is making the challenge fit real user behaviour. If enrolment, login prompts, recovery, and exception handling are slow or confusing, people bypass the control, hoard backup codes, or route around enforcement. Usability is therefore a security requirement, not a convenience feature.
Good MFA design starts with the most common paths: daily login, new device enrolment, step-up verification, and account recovery. The experience should be predictable, fast, and clearly explained, with the strongest friction reserved for higher-risk actions. That is why adaptive authentication and SSO are often paired, so users see fewer prompts while the control still becomes stricter when the context changes.
When MFA is difficult, organisations often create shadow exceptions for executives, shared break-glass accounts, or legacy apps. Those exceptions accumulate and weaken assurance more than a carefully tuned default flow. A usable design keeps the policy broad, the edge cases visible, and the recovery process strong enough that support staff do not become the easiest bypass path.
Choose Factors and Prompts That Match the Actual Threat Model
Not all MFA methods deliver the same resistance to phishing, push fatigue, token theft, or device compromise. A design that relies on one-time codes or repeated approvals can still be usable, but it may be weaker against modern attacks than phishing-resistant authenticators or device-bound credentials. The security goal is to match the factor to the likely failure mode, not just to check a box.
For most organisations, the strongest pattern is to combine something the user knows with something they possess, then add context when risk increases, such as unfamiliar device, impossible travel, or unusual transaction type. Step-up verification should be reserved for those moments, so users are not forced through the same heavy flow on every login. That balance preserves adoption while keeping the control sensitive to risk.
Recovery deserves the same design discipline as login. If password reset, lost-device recovery, or help desk overrides are weak, attackers will target those paths instead of the primary factor. The practical test is whether the recovery process is harder to abuse than the normal sign-in flow is to use.
Make the Control Durable Under Real-World Operations
Usable MFA fails when the organisation treats it as a front-end prompt rather than an operating model. You need clear ownership for enrollment policy, factor lifecycle, support escalation, logging, and exception review. If those pieces are fragmented, teams quietly create alternate access paths that are easier for staff but harder to defend.
Metrics should focus on both adoption and friction. Track enrollment completion, prompt frequency, failed sign-ins, recovery volume, and the number of users or systems that remain outside policy. High failure or exception rates usually signal a design issue, a broken rollout, or an access dependency that has not been fixed yet.
Evidence matters as much as the user experience. Organisations should be able to show which users are covered, which factors are permitted, which flows are exempted, and how quickly lost or changed devices are revoked. That is also where broader identity governance becomes relevant: strong MFA is easier to sustain when NHI governance and lifecycle controls are already well managed, because the same discipline that reduces secrets sprawl and overprivilege also reduces the pressure to invent risky access shortcuts. For implementation guidance, the identity control patterns in the Ultimate Guide to Non-Human Identities overview and the incident lessons in the Uber breach analysis show why weak exception handling and social engineering resistance have to be designed together.
Risk and Threat Considerations
MFA becomes risky when usability problems push users or administrators toward weaker paths, because attackers usually look for the path with the least resistance. The biggest failure modes are MFA fatigue, phishing of OTP-based flows, recovery abuse, and exception creep around privileged or legacy accounts.
Failure mechanism: Repeated prompts, confusing enrollment, or poor recovery design encourage users to approve blindly, reuse weaker fallback methods, or ask support for bypasses that are easier to phish or social-engineer than the primary sign-in flow.
Impact: An organisation can end up with an MFA programme that looks strong on paper but still allows account takeover, privilege abuse, and lateral movement through the weakest exception paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Identity and Access Abuse | MFA usability and abuse-resistant sign-in directly affect identity and access misuse. |
| Recommendation — Use abuse-resistant authentication to reduce phishing, fatigue, and unauthorized approval of sign-in requests. | ||
| CIS Controls v8 | 6 — Access Control Management | MFA design, exceptions, and recovery paths are access-control safeguards. |
| Recommendation — Enforce strong authentication and review exceptions so weaker access paths do not persist. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | The subject is about balancing authentication strength with practical access control. |
| PR.AA-03 — Least Privilege and Permission Management | Step-up access and exception handling should limit what authenticated users can do. | |
| Recommendation — Implement authentication controls that verify users while keeping access flows usable. Limit elevated access after authentication and remove standing exceptions where possible. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | MFA recovery and factor lifecycle depend on protecting credentials, tokens, and backup secrets. |
| NHI-04 — Authentication and Authorization | The question centers on authentication strength and authorization decisions during step-up checks. | |
| NHI-06 — Lifecycle and Offboarding | Usable MFA depends on removing stale devices, lost factors, and obsolete recovery paths. | |
| Recommendation — Protect backup codes, tokens, and recovery credentials with strict lifecycle controls. Require stronger authentication for risky actions and validate access before granting it. Revoke lost or obsolete authenticators quickly and keep recovery paths current. | ||
| MITRE ATT&CK | T1110 — Brute Force | Weak MFA recovery or login flows can be abused in credential and challenge attacks. |
| T1078 — Valid Accounts | MFA exists to protect accounts that attackers try to use after compromise or phishing. | |
| Recommendation — Monitor for repeated authentication attempts and strengthen sign-in throttling. Detect and respond to suspicious use of valid accounts across login and recovery flows. | ||
Practitioner Guidance
What to prioritise: Harden the flows people use most often, not the rarest edge case. If daily sign-in is smooth but recovery is weak, the recovery path will become the attacker’s target and the user’s workaround.
What to verify: Check whether the chosen factor is resistant to the attack you actually see, especially phishing, push fatigue, and help desk impersonation. If the factor can be replayed, approved by mistake, or reset through an informal process, treat it as lower assurance even if adoption is high.
Practitioner takeaway: Usable MFA is secure only when the easiest path for users is still harder to abuse than the easiest path for attackers.
Related resources from NHI Mgmt Group
- How should security teams choose between 2-factor authentication, multi-factor authentication, and adaptive MFA for remote and hybrid access?
- How should security teams automate 2-factor authentication without weakening assurance?
- How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
- How should security teams implement multi-factor authentication for sensitive access without creating user workarounds?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
