Why do inaccessible MFA flows increase security risk for organisations?

When MFA is too hard to use, people look for faster paths around it, including shadow IT, shared workarounds, or unsupported devices. That weakens the control the organisation thought it had in place. Accessibility is therefore a security issue, not just a usability issue, because friction can drive behaviour that creates new attack paths and undermines policy enforcement.

Why inaccessible MFA becomes a control failure, not just a user complaint

When MFA is difficult to complete, people do not stop work, they route around the control. The risk is not only weaker login assurance, but also the creation of informal exceptions such as shared devices, shared accounts, bypass approvals, alternate channels, or unsupported recovery paths that are harder to monitor and govern than the original MFA flow.

Accessibility issues become security issues because a control that cannot be used reliably at the point of access is not actually enforcing policy in the way designers intended. In practice, the organisation ends up with lower assurance, inconsistent enforcement, and a larger surface for workarounds that attackers can exploit once they learn the local exceptions.

Good MFA design therefore has to be judged against real operating conditions: device diversity, assistive technology compatibility, recovery scenarios, user stress, and time pressure. If the control only works for the ideal case, the business often pays for the gap in shadow processes rather than in formal risk acceptance.

How friction changes user behaviour and attacker opportunity

Frustrating MFA flows push users toward the fastest available path, especially when they are trying to meet a deadline or recover access. That behavioural shift can produce shared workarounds, repeated approval fatigue, or use of personal devices and unsanctioned tooling, all of which weaken visibility and make policy enforcement less consistent.

Attackers benefit when legitimate users have already normalised exceptions. If people are used to bypassing the preferred path, it becomes easier for an adversary to imitate that path, abuse recovery procedures, or target the weakest fallback rather than the primary factor. Friction also increases the chance that users will ignore warnings or approve prompts without careful review.

For organisations, the security consequence is not merely that MFA is bypassed sometimes, but that the exception becomes part of the operating model. At that point the control is no longer a clean gate, it is a negotiable process whose weakest branch may be the one most visible to an attacker.

What strong MFA accessibility means in practice

Accessible MFA should reduce the need for exception handling, not increase it. The better design question is whether users can complete the flow consistently across supported devices, whether recovery is secure but practical, and whether the organisation can still enforce policy without creating unofficial side channels.

That usually means balancing resistance to abuse with usability for legitimate users. Current guidance from identity and access practitioners increasingly treats phishing resistance, recovery hardening, and accessibility as linked outcomes, because a highly secure factor that people cannot complete reliably often shifts risk elsewhere rather than removing it.

Organisations should also pay attention to where the MFA journey breaks down: enrollment, step-up prompts, lost-device recovery, and cross-device login. Those are the places where workarounds are most likely to emerge and where monitoring should be strongest.

Risk and Threat Considerations

Inaccessible MFA increases the chance that users will create informal exceptions, and those exceptions often become the real control path. That creates governance risk, because the organisation may believe it has a standard assurance model when, in practice, it has multiple inconsistent authentication paths with different exposure.

Failure mechanism: users who cannot complete the approved MFA flow are more likely to adopt bypasses, shared workarounds, or weaker recovery paths; attackers then target the exception path, prompt-fatigue behaviour, or unsupported devices rather than the primary factor.

Impact: the result is reduced authentication assurance, weaker policy enforcement, more difficult monitoring, and a broader opportunity for account takeover or misuse of access paths that were never intended to be routine.

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	Accessibility and usable MFA are central to authenticator assurance and phishing-resistant login design.
Recommendation — Use NIST 800-63 to choose authenticators and recovery paths that users can complete reliably.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	MFA accessibility affects whether organizational user authentication is consistently enforced.
	IA-5 — Authenticator Management	Friction often shifts users into weaker recovery and fallback authenticator handling.
Recommendation — Implement IA-2 so authentication remains enforceable without relying on informal bypasses. Apply IA-5 to govern enrollment, rotation, replacement, and recovery of authenticators.
CIS Controls v8	CIS-6 — Access Control Management	Exception-heavy MFA flows weaken practical access control enforcement and governance.
Recommendation — Tighten access control so MFA exceptions stay rare, approved, and auditable.
ISO/IEC 27001:2022	A.5.15 — Access control	MFA accessibility affects whether access rules are actually applied as intended.
Recommendation — Design access control so users can follow the approved path instead of creating workarounds.

Practitioner Guidance

What to verify: test the full MFA journey, not just the happy path. Check enrollment, device change, lost-factor recovery, assistive technology compatibility, and whether users can complete the flow without relying on informal help from colleagues or service desks.

What good looks like: legitimate users can complete MFA consistently with minimal exception handling, while fallback methods remain tightly controlled, auditable, and rare. If you see recurring workarounds, treat that as a control design problem, not a training problem.

Decision rule: if the MFA flow requires users to choose between productivity and compliance, expect bypass behaviour. Fix the control path before expanding enforcement, because hardening a flow that is already unusable usually increases shadow IT rather than assurance.

Practitioner takeaway: MFA only reduces risk when it is usable enough that real users will keep using it, otherwise the organisation inherits the control on paper and the workaround in practice.