Should organisations prioritise accessibility in MFA design?

Yes, because accessibility is part of authentication reach, not an optional polish layer. If users cannot scan a QR code, read a screen clearly, or enter codes reliably, the factor does not protect the account population it was meant to cover.

Accessibility is part of authentication coverage, not a nice-to-have

MFA only improves security when the intended users can complete it consistently. If a person cannot scan a QR code, distinguish prompts on a low-vision device, reach a phone, or enter one-time codes without friction, the control excludes part of the account population and creates weak fallback paths that are often easier to attack.

That is why MFA design should treat accessibility as a core requirement alongside phishing resistance, recovery, and usability. A factor that is technically strong but practically unusable for a subset of users does not produce real authentication coverage.

Accessible design also improves operational resilience. The same accommodations that help disabled users, clearer prompts, alternate authenticators, recovery options, device-independent methods, reduce help desk escalations and lower the pressure to create ad hoc exceptions.

Which MFA methods are more accessible in practice?

The most accessible options tend to be those that reduce dependence on vision, fine motor control, a single device, or time-sensitive manual entry. Passkeys and security keys can work well because they remove code transcription, while well-designed push or number-matching flows can be acceptable when paired with clear prompts and reliable fallback paths.

By contrast, SMS codes, repeated CAPTCHA-style challenges, and short-lived codes typed from one device into another often create avoidable barriers. These methods can still be used in some environments, but they should not be the default answer if the organisation can deploy more inclusive options.

Accessibility also includes enrollment and recovery. An MFA method that is usable at sign-in but impossible to re-establish after device loss, phone change, or accessibility need change is only partially effective. NIST SP 800-63 Digital Identity Guidelines is useful here because it frames authenticator assurance, phishing resistance, and recovery as part of a complete identity experience rather than isolated login steps.

What breaks when accessibility is ignored?

When MFA is not accessible, users and administrators tend to route around it. That can mean disabled users getting exemptions, shared devices being used as workarounds, lower-assurance fallback methods being overused, or help desk processes becoming the real authentication layer. In practice, those workarounds often weaken security more than the original control would have.

Accessibility failures also create uneven protection. A policy that looks strong on paper but leaves a subset of users unable to authenticate reliably is not enforcing the same security standard across the population. That inconsistency is especially risky in high-value or regulated environments, where recovery channels and exceptions can become the easiest entry point for social engineering.

Good MFA design therefore has to account for the attacker as well as the user. If the fallback path is easier than the primary path, threat actors will target the fallback. Well-known patterns such as phishing, push fatigue, token theft, and account recovery abuse show why the usable path and the secure path need to be the same path wherever possible. CIS Controls v8 supports this thinking through account management, access control, and secure configuration priorities.

Risk and Threat Considerations

Inaccessible MFA creates a control gap: the organisation may believe it has strong second-factor coverage while part of its user base is forced into exceptions, help desk resets, or weaker fallback methods. Attackers often target exactly those weak edges because they are simpler than defeating the intended factor.

Failure mechanism: Users who cannot complete the primary MFA flow are redirected to alternate methods, recovery paths, or manual approval processes that are easier to social-engineer, bypass, or abuse.

Impact: The account population is no longer protected uniformly, and the organisation inherits both higher takeover risk and more operational friction from avoidable support interventions.

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	Authentication assurance and recovery shape MFA usability and coverage.
Recommendation — Use assurance and recovery guidance to choose authenticators users can complete consistently.
CIS Controls v8	CIS-5 — Account Management	Accessible MFA reduces exception-driven account and access workarounds.
Recommendation — Standardize account and access flows so fallback paths do not weaken MFA.

Practitioner Guidance

What to prioritise: Pick MFA methods that minimize visual, motor, and device dependency for the widest user set, then design recovery as carefully as sign-in. If a method cannot be used without workarounds by an important user group, it is not ready for broad deployment.

What to verify: Test enrollment, sign-in, step-up authentication, device loss recovery, and help desk reset flows with users who rely on screen readers, magnification, alternative input, or non-standard devices. Verify that the secure path is still the easiest supported path.

Practitioner takeaway: Accessibility is a security requirement because authentication only works when the control is usable at scale, for real users, under real conditions.