ºÚÁϺ£½Ç91Èë¿Ú

Multi-factor authentication (MFA) is fast becoming the standard for businesses as they adopt Zero Trust security strategies to protect emerging cloud-based environments with remote and hybrid setups. Several methods of completing MFA have emerged to meet the needs of different users, use cases, devices, and environments, with the optimal MFA solution maximizing security without hindering productivity. 

Naturally, ease of use is critical to enabling productivity, so accessibility must be considered when configuring MFA solutions. Fortunately, a wide array of available MFA factors enable organizations to provide accessible options to users with different needs. In this article, we’ll explore different MFA factors in terms of their requirements of the user, which factors may be best suited for users with different accessibility needs, and other ways to reduce friction and enable users in the authentication process. 

MFA Accessibility by Factor

Like most accessibility matters, MFA factor accessibility can’t be measured against one master accessibility scale. Different methods will be more or less accessible to different users, depending on their needs and equipment. Often, MFA steps can be paired with other accessibility support initiatives like screen readers, custom keyboards, and other modifications that the user already has in place. 

It’s important to ensure users’ MFA technology works for them; it may be worth offering one-on-one support to ensure accessibility tools pair correctly with MFA factors and work for the user. If MFA technology is too cumbersome to the user or unsupported by necessary programs like screen readers, the user will likely find workarounds or use shadow IT to keep their productivity high, which can create significant security vulnerabilities. 

Further, whether or not accessibility regulations like and W3C’s apply to your organization or MFA instance, consider measuring against them anyway to establish a baseline of accessibility. Section 508, for example, outlines accessibility guidelines for information and communication technology within Federal agencies. 

With this in mind, let’s consider some of the main MFA factors, what abilities they require of users, and how IT admins can provide support or alternatives to MFA solutions that users find inaccessible. 

Biometrics

In general, biometrics provide an advantageous combination of high security and low friction. Because this method uses a factor that is inherent to the user, they can’t forget or lose it, and it’s difficult for malicious actors to phish, intercept, or fake. Biometrics also require little to no action on the user’s part, including tasks that accommodate sight, hearing, mobility, and cognitive impairments, making them a great candidate for many users with disabilities.

Often, the drawback to these methods ends up being cost and availability. Computers don’t universally include biometric scanners, and add-ons are available (see Hard Security Tokens), but they require an additional hardware investment. Companies may consider providing biometric capabilities only to those that request or need it and providing alternative, more readily available methods to other users. 

Further, biometrics are less universally functional than other MFA factors. In some setups, they can only grant access at the device level but not at the application level, or they only work when MFA is turned off; in others, they work with mobile applications but not websites. The FIDO Alliance, an industry association that aims to change the nature of authentication by reducing the world’s reliance on passwords, is working to solve some of these issues with hard or built-in security tokens that authenticate to web-based services with biometrics using WebAuthn.

Facial Recognition 

Requirements of the user: little to none.

Facial recognition is most widely used on smartphones, and is now available on most newer smartphone models. Some computers, including newer Microsoft machines, allow facial recognition as a login method. Typically, this biometric does not extend to third-party applications or websites, although and services are changing that. 

Facial recognition is relatively low demand in terms of requirements of the user. It does not require sight, hearing, or significant motor skills, making it ideal for many users. However, it’s not available on all work devices and applications. 

Fingerprint Recognition

Requirements of the user: scan fingerprint.

Similarly, fingerprint recognition does not require significant sight, hearing, or motor skills, but it isn’t a standard on all work devices. However, there are plug-in fingerprint scanners available to users that prefer this factor. Like facial recognition, FIDO-enabled browsers and services are beginning to enable wider use of fingerprint scanners for web-based work applications. 

TOTP

Time-based one-time passwords (TOTPs) authenticate a user’s identity by sending a randomized, unique, and temporary code to a separate account or device associated with the user. The user then inputs the code into the resource they are requesting access to. TOTPs are highly secure, because they would require a hacker to have possession of several of the user’s proprietary accounts — in close proximity, in the case of a smartphone or other device — in a short period of time. However, unlike biometrics, , and some sophisticated real-time attacks can intercept and reproduce them to gain access to accounts. 

In terms of demand on the user, TOTPs do require a bit more work than biometrics or push notifications, namely with viewing, remembering, and typing in a code. Despite this, many users find them convenient because they use their personal smartphone and only require a quick code input. 

This code input may hinder people with sight, cognitive, and motor skill impairments. For users with blindness, many authenticator applications and messaging apps are compatible with screen readers. 

Authenticator Applications

Requirements of the user: Read a code; type it quickly. Some authentication apps are compatible with screen readers.

Authenticator applications are user-friendly because they are easily accessible on the user’s smartphone and don’t disrupt their personal communications like a text would. Authenticator apps are also considered more secure than TOTP text messages, because bad actors could conceivably intercept, redirect, or gain access to text messages without phishing them or accessing the user’s physical phone. 

; for those using this method, make sure their screen reader is compatible with their authenticator app. Usability items to look for would be making sure the screen reader reads the time frame (usually seconds remaining), differentiates it from the TOTP, and speaks fast enough to give the user time to type it in.

For users with mobility impairments that make typing in the code difficult, dictation applications may provide adequate support. Again, test these solutions with the user to ensure the application receiving the code accepts text-to-speech input.

Text Messages

Requirements of the user: Read a code; type it quickly. Text apps are usually compatible with screen readers. 

Texted codes may be a bit less secure than authenticator apps, but they are a common solution for their ease of use and wide availability. Texted codes often have a longer time frame than TOTPs in authenticator apps, which lessens security but increases ease of use. This trade-off may be worth it for users with difficulties typing codes quickly. Further, screen readers and text-to-speech functions are more likely to work seamlessly with a native app like texting. This may be a helpful alternative to people with sight impairments. 

Push Notifications

Requirements of the user: Receive notification; tap button.

Push notifications provide the same high security and ease of use as TOTPs, but without the cumbersome step of receiving and typing in a time-sensitive code. This is significant for those with difficulties reading or inputting the code, providing a simpler way to complete secure MFA.

With push notifications, a notification is sent to the user’s phone asking them to tap a button to verify their identity and confirm their login attempt when they try to access an application or resource. For the user, this requires them to read the notification and tap a button. This removes much of the mobility demands of the TOTP without sacrificing security; threat actors would need to gain physical and timely access to the user’s device to compromise an account. 

Push notifications do typically require sight for the user to recognize and interact with them; however, screen readers, notification sounds, and haptics may provide assistance. Push notifications are ideal for users that face challenges inputting a code quickly and offer a lower-friction alternative to the TOTP, empowering users without requiring expensive hardware.

Hard Security Tokens

Unlike the software-based security tokens outlined above, hard security tokens require a piece of equipment, like a dongle or built-in fingerprint scanner, to complete MFA. Some still require users to input codes, and some remove this step by forming a secure connection between the hard token and the authenticating service. Physical MFA devices do not generally require hearing, and connected fobs that remove the need to manually input a code can be a beneficial MFA accessibility feature for users with motor and visual impairments. 

Connected Tokens

Requirements of the user: Plug in token; sometimes tap button or implement secondary step.

Connected tokens are assigned to a user, who physically plugs them into a device to complete MFA. The connected token can either act as a keyboard and transmit keystrokes to input a one-time password (OTP) or verify identity via a wide array of authentication protocols, including FIDO/FIDO2, PIV, OAUTH, and others by transmitting a unique code from the fob to the device. 

Connected tokens require users to plug a fob into their device, and may require a second step like pressing a button or completing a biometric challenge. However, they do not generally require users to input a code, making the MFA process more accessible for some users with motor, visual, and cognitive impairments.

Connected tokens have two commonly cited downsides: the expense and burden of hardware, and the likelihood of the user losing or forgetting their fob. Unlike software-based tokens, hard tokens require companies to purchase and distribute equipment to employees. Hardware also comes with the risk of obsolescence as devices upgrade and change: many use USB-A ports, for example, which Macs have replaced with USB-C ports. Adapters can fix this, but they add another expense and piece of equipment for organizations and users to track. 

That brings us to the second downside: users relying on an additional piece of equipment to complete their work. Many users appreciate MFA applications they can download on their personal phones, because the modern user carries their phone with them everywhere and isn’t likely to lose it. By contrast, a security fob isn’t something users would naturally carry with them, so there’s a higher likelihood that they misplace it or leave it at home.

Disconnected Tokens 

Requirements of the user: Read a code; type it quickly. 

Disconnected tokens require users to carry a fob — like connected tokens — but they issue TOTPs, and the user experience is fairly similar to an authenticator app or text-based TOTP. With disconnected tokens, the fob doesn’t plug into the machine; rather, it displays a TOTP, which the user has to manually input into their computer or device to authenticate. Although secure, this method carries the cost and burden of hardware along with the friction of TOTP input, which can be difficult for users with sight or motor impairments. Additionally, security keys don’t typically have screen reading capabilities or other supports for sight impairments. 

Layering with Other Tools and Modifications

Because users’ abilities and challenges vary widely, making MFA accessible to all users sometimes requires more one-on-one support and customized solutions. Other than individual modifications, there are some tools that can be deployed universally to increase security while streamlining the MFA user experience. Consider implementing the following:

Conditional Access

Conditional access is a helpful tool for decreasing friction in the user experience without compromising security. Conditional access allows the system administrator to bypass or require MFA based on certain scenarios (or deny access altogether if minimum security requirements aren’t met). For example, the system could require MFA if the user signs on from an unrecognized network; however, if they’re logging on via their recognized device and network, the system administrator could configure the system to waive the MFA requirement and grant access. This way, the user doesn’t have to complete MFA more frequently than is necessary. 

This is especially useful for empowering productivity in users who experience difficulties completing MFA steps: IT admins may add their IP address to an allow list, for example, so they can bypass the MFA steps when working from home.

Single Sign-On 

Single sign-on (SSO) uses one secure set of credentials (ideally, verified through MFA) to grant a user access to all the IT resources they need via secure protocols like SAML, LDAP, RADIUS, and others. SSO significantly reduces friction by only requiring one login action per session. For users that experience difficulty completing MFA steps, it doesn’t eliminate them altogether, but it reduces the number of times they have to complete them, helping enable ongoing productivity after their initial MFA login.

Aim for MFA Factor Variety 

Because users’ abilities vary and one solution likely won’t work for everyone, an MFA solution that offers a variety of factors and options is ideal. Try to make sure you offer at least one option for users with sight, mobility, and cognitive impairments. For example, a security fob or fingerprint scanner may work for most users with sight-based disabilities, and push notifications would likely work for many users with mobility or cognitive impairments.

Try layering these options with conditional access and SSO, as described above, to maximize productivity and minimize MFA friction. Be sure to work with users that may need modifications or other solutions: consider any modifications or supports they have in place, like screen readers or text-to-speech, and make sure the MFA solutions you offer are compatible with them. 

Start with a Robust Core Directory

While MFA is only one element of identity and access management (IAM), it’s important to make sure your MFA solution integrates seamlessly with a comprehensive core IAM solution. 

Cloud directories, for example, are challenging Microsoft Active Directory, a Windows-based on-prem software directory model, with device agnosticism, Zero Trust security, MFA offerings, SSO to a broader range of resources, and other capabilities that reflect today’s modern business environment with varying user preferences and needs. 

ºÚÁϺ£½Ç91Èë¿Ú is a cloud directory platform that offers several MFA solutions, including TOTP, a push notification app, and optional integrations with other MFA tools like Duo, on top of its support of Macs, Windows, and Linux devices, so users can use the methods and devices they’re comfortable and productive with.

Further, ºÚÁϺ£½Ç91Èë¿Ú can moderate MFA steps with conditional access, facilitate access to virtually every resource a user needs (whether in the cloud or on-prem), and improve the user experience with SSO. 

Just as we recommend testing out MFA solutions to ensure they work for your users, we recommend trying our platform to assess whether it works for your organization. The entire ºÚÁϺ£½Ç91Èë¿Ú platform is free to try when you .Ìý