Common signs include users bypassing approved workflows, relying on shadow IT, or facing inconsistent login experiences across platforms. Another warning sign is patchy adoption across the client portfolio, often caused by operating system gaps or poorly matched policy settings. If users cannot move through authentication cleanly, they will often look for less secure workarounds.
How poor MFA adoption shows up in real user behaviour
When MFA is undermined by friction, the warning signs are usually behavioural before they are technical. Users start looking for the shortest path through the login flow, which can mean repeated help desk resets, bypass requests, or informal workarounds. That matters because the control may still exist on paper while real sign-in behaviour shifts toward the path of least resistance.
One of the clearest indicators is that users are not treating the approved MFA path as the default. If people repeatedly avoid the intended flow, the control is no longer operating as designed, even if policy says it is mandatory.
That is why adoption issues should be read alongside login telemetry, support tickets, and exception handling. A low-friction control is one that users can complete consistently without needing special coaching, repeated retries, or ad hoc approval from support staff.
Where friction creates weak spots in the authentication journey
Poor adoption often appears as uneven coverage across apps, platforms, or device types. The problem is not only that some users have not enrolled, but that the experience changes enough between environments that users learn to avoid the harder path. In practice, inconsistent prompts, broken fallback flows, or platform gaps create a split between the policy and the user’s actual sign-in pattern.
That same friction can also push users toward lower-assurance alternatives. If the preferred method is unreliable, a user may fall back to a less secure option, seek a workaround, or delay enrolment altogether. This is especially common when policy settings do not match the client estate, so one group gets a smooth journey while another group gets repeated failures.
For a practical benchmark on what a robust sign-in design should support, see NIST SP 800-63 Digital Identity Guidelines, which helps frame assurance, authenticator strength, and usable authentication patterns.
What the organisation should infer from patchy adoption
Patchy adoption is usually a governance signal, not just a rollout problem. It suggests the MFA programme is not aligned with the operational reality of the client portfolio, the support model, or the user population. When that happens, the weakest group often defines the true security posture, because attackers will look for the least defended path rather than the average one.
Repeated inconsistency across devices or platforms also points to a lifecycle issue. If enrolment, recovery, and fallback are not designed as part of the same experience, users tend to accumulate exceptions that become the easy route around the intended control. Over time, those exceptions become hard to unwind.
Good identity programmes treat enrolment quality, recovery design, and platform support as security controls in their own right. For a broader view of how this plays out across workforce sign-in, recovery, and phishing-resistant options, see Workforce Identity Security Guide and Passwordless and Passkeys Guide.
Risk and Threat Considerations
Poor MFA adoption creates a measurable security gap because the organisation may believe it has strong second-factor protection while real users are still exposed to fallback paths, bypasses, or inconsistent enforcement. Attackers do not need every account to be weak, they only need the weaker segment, the easier recovery path, or the method users have learned to trust over the official one.
Failure mechanism: Friction pushes users into shadow IT, insecure recovery choices, exception requests, or alternate sign-in paths that reduce assurance and widen the practical attack surface.
Impact: The organisation gets the cost and complexity of MFA without full control benefit, while account takeover risk remains elevated through the weakest adoption points.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authenticator assurance and usable sign-in design for this MFA adoption problem. |
| Recommendation — Apply NIST 800-63 to align MFA strength with user-friendly authentication and recovery. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User MFA adoption is directly about authenticating workforce users. |
| IA-5 — Authenticator Management | Poor adoption often stems from weak authenticator lifecycle and recovery handling. | |
| Recommendation — Enforce IA-2 to require consistent multi-factor authentication for organizational users. Use IA-5 to manage MFA authenticators, rotation, and recovery securely. | ||
| CIS Controls v8 | CIS-5 — Account Management | Patchy adoption and bypasses often reflect weak account and authentication governance. |
| Recommendation — Use CIS-5 to standardize account authentication expectations and reduce exceptions. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | MFA friction and bypass risk are governed through protection of authentication information. |
| A.8.5 — Secure authentication | Directly addresses secure authentication design when MFA is undermined by usability gaps. | |
| Recommendation — Protect authentication information and related recovery paths under A.5.17. Implement secure authentication controls that users can complete consistently. | ||
Practitioner Guidance
What to prioritise: Treat repeated login failure, enrolment drop-off, and help-desk assisted bypass as security signals, not just UX noise. If users are abandoning the approved path, the control design needs attention before you assume the policy is working.
What to verify: Check whether adoption is consistent by platform, browser, operating system, and user group. A control that works well on one client type but fails on another is often creating exceptions faster than it is reducing risk.
Practitioner takeaway: The right question is not whether MFA is enabled, but whether users can complete it reliably enough that they do not seek a weaker path.
Related resources from NHI Mgmt Group
- How should security teams reduce phishing risk in MFA without creating more user friction?
- How should small businesses implement MFA without creating too much user friction?
- How should security teams implement MFA in regulated industries without creating audit gaps or user friction?
- How should SMBs implement MFA across cloud apps, VPNs, and on-prem systems without creating user friction?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
