Three examples of multifactor authentication use cases

Scenario 1: Enhance RADIUS or Active Directory identity stores

One reason to deploy multifactor authentication is to augment the security of traditional Remote Authentication Dial-In User Service (RADIUS) or Active Directory (AD) identity stores to better validate users and strengthen login capabilities. In this scenario, the identity request passes from AD or a VPN to the multifactor server for an additional authentication step before it allows the user to login to the network.

Because this was the original multifactor authentication use case for these tools, nearly all vendors support this operational method. Accordingly, if a user's password is compromised, additional factors can ensure a person is actually the user attempting to log in. If an enterprise already has AD and is fairly confident its directory information is accurate, adding multifactor authentication tools is often a relatively small and painless step toward better security.

In addition, many VPNs come with some kind of built-in support for multifactor authentication services, so the level of integration shouldn't be daunting in that regard. If companies are comfortable with handling various Lightweight Directory Access Protocol or RADIUS servers in their shops, it shouldn't be too hard to add additional authentication factors.

Scenario 2: Web services authentication

Another operational use for a multifactor authentication deployment is using it as the identity provider for a web service like Google Docs or Salesforce cloud apps. In this scenario, a login request uses the Security Assertion Markup Language (SAML) and trusted certificates between the app and the multifactor server for the additional authentication step. This is the method used by Google and Apple to add second-factor features to users' Google accounts and Apple IDs, respectively.

Additionally, if enterprises already use a variety of SaaS applications, they should consider adding multifactor authentication to better secure their cloud application data.

This method can also be used to secure logins as part of a bring-your own-identity (BYOI) policy that uses the cloud to federate and manage identities.

Federation refers to sharing a single authentication process across multiple servers or services. While BYOI makes it easier for users to log into multiple websites, it also makes it easier for exploits to propagate. With BYOI, a bad actor that breaches one login then gains access to the user's accounts on other federated sites. To address this issue, organizations need to deploy multifactor authentication tools.

Multifactor authentication is also important to consider when employing single sign-on (SSO) tools. For example, consumer packaged goods holding company Post Holdings Inc. uses Okta's SSO product. Post's portal page has connections to all of its SaaS services listed. New employees use an SSO tool that sets up their logins to all the appropriate services.

In this case, users don't even need to know their passwords. The tools create a complex and unique password, which -- when combined with multifactor authentication -- significantly strengthens login security.

The advantage to this method of authentication is that IT doesn't have to touch the apps sitting in the cloud to improve login security; once a user provides additional factor information, the user can then log into the web service directly.

The downside of this method is that not every web service provider or multifactor vendor supports SAML. Meanwhile, some vendors require separately purchased products to provide SAML authentications.

Scenario 3: Web server authentication

By adding code, such as Simple Object Access Protocol, Perl or JavaScript, to the pages of a web server, multifactor authentication secures logins to the server itself. The code makes the connection between the server and a multifactor vendor's services.

This can be relatively simple to enable, especially for on-premises web apps. Users can adjust pages quickly, provided they understand the nature and security implications of the code they are adding to the pages. On the other hand, it can be nearly impossible when a managed service doesn't allow users to touch the code.

This operational method can be a workable alternative in instances where a multifactor authentication product doesn't yet support SAML logins, or when customized web apps need just a few lines of code to make the login more secure.

Multifactor authentication preparation: Questions and obstacles

When evaluating multifactor authentication products, companies should carefully look at how each one differs subtly with regard to the three operational methods of deployment. Multifactor authentication methods vary, and not every vendor can handle all three use cases equally well. This reality often plays a factor in product selections. Companies should also focus on the three multifactor authentication use cases when shopping for a product.

Here are some things to consider when selecting a multifactor authentication approach/product:

• How sensitive is the information users are accessing? If the answer is, "not very," then a business can probably stick with its existing authentication methods. An enterprise that allows users to access sensitive information like its customer data should really employ multifactor authentication.
• Is compliance an issue? Government regulations require organizations in some sectors to implement stronger security measures to ensure the data is secure. These industries are mainly in finance and healthcare, with stricter standards placed on their data due to patient confidentiality. Many regulations, like HIPAA and the New York Department of Financial Services (NYDFS) for example, mandate companies implement multifactor authentication so only authorized individuals have access to sensitive information. HIPAA provides a compliance checklist to ensure multifactor authentication use. Enterprises must also be able to prove they comply with these regulations. Businesses should confirm each vendor under consideration provides an audit log (a record of system activities, for compliance purposes).

• Does the business require the ability to scale up deployment? While most multifactor authentication products handle tens of thousands of tokens and users, they also have the ability to serve smaller enterprises. Be sure to consider future licensing costs.
• Where is the workforce located? The location of a company's employees will likely influence which multifactor authentication approach it selects. For instance, an organization whose workforce spreads out around the world might opt for a mobile app rather than a physical device.
• Are employees already using the two-factor tools available with some consumer services? If not, enterprises should spread the word and get them to make use of the second-factor option on common cloud services like Google, Facebook, Twitter. After all, these services already utilize multifactor authentication, and it won't cost anything other than a small amount of training to try them. This is something enterprises can expand on should they deploy multifactor authentication internally.

Finally, before starting down the road toward picking a multifactor authentication vendor, carefully consider the following before deployment:

• If a company doesn't have its Active Directory act together, multifactor is a painful way to get there. Start by pruning the directory store to make sure it is accurate before beginning deployment. Every authentication approach requires up-to-date information on who should have access, so it's critical companies keep the directory updated when users leave the company or new users are given access.
• An organization needs to be sure the authentication tool it selects is able to connect to and work with its existing databases, including the database that contains employee data.
• A business with a mobile device management system has to be sure it is compatible with the authentication management system since many authentication approaches influence mobile devices.
• If a business mostly uses on-premises servers, it might be better off using Windows Server's built-in password-strengthening policies, at least to start. Monitor how much users push back when they have to regularly change passwords and make them more complex.

Making a business case for multifactor authentication clearly requires some forethought and planning. Companies can apply numerous multifactor authentication use cases for the technology in different ways to different parts of an IT infrastructure. Understanding how multifactor authentication operates ahead of time will be helpful when it comes time to select a provider.

Linda Rosencrance contributed to this report.