The selection of the “right” MFA solution can be tricky. First, because there’s a constant flow of innovation in the authentication industry, resulting in numerous and diverse technologies even for solutions supposedly following a standard. Second, because the applications and environments needing MFA are also very different (cloud vs. onprem, legacy vs. web, ldap vs. radius, SAML, or OIDC, etc.). Lastly because not all solutions have the same objectives or protect against the same risks.
Finding the right solution for your organization might therefore require some research. There’s no one-size-fits-all MFA solution. It doesn’t mean – as we often hear it – that you shouldn’t make choices on behalf of your end users and thus offer them a vast list of options for authentication. They might feel overwhelmed. On the contrary, you need to make most of the choices to keep the access to your applications secure, simple, and straightforward. Therefore, you’ll need a solution that is flexible enough to accommodate your choices, policies, security target, use cases, compliance requirements, etc.
The purpose of this article is to provide you with a map for this journey, highlighting the goals but also the pitfalls. I hope you’ll find it useful. I could have written 20 sections or more but preferred to limit it to 5 – constraints foster creativity. The sections are not ordered by importance or relevance. I’ve included a few links to other posts and inWebo tutorials for those who want to dig deeper.
By this, I mean “what the user has”. In MFA indeed, there’s a possession element, also referred to as an authentication device, or a “token”. It can be a physical device (a USB dongle, a smardcard and a reader, a device or credit card displaying one-time codes, etc.). It can be an App. It can also be an SDK for your Apps, web and mobile.
The choice matters for different reasons:
- Costs: Your users need that device, so if this is a physical device, you’ll need to buy and ship it in a secure manner, which can be pretty expensive as soon as you have more than a few tens of users. Also, users loose or forget these devices constantly, which will add up to the bill.
- Compatibility with user devices: if you’ve equipped your sales reps with tablets or smartphones (or if you know that a significant part of your users might prefer to use such devices to access your service), don’t pick USB dongles or smartcard readers, because users won’t be able to plug them. Choosing a soft-token (an App on a smartphone) seems to always work, but wait! Do all your users have a work phone or want to use their personal phone for security? It’s a question that many organizations answer with a “no”. The only form factor that creates no constraint is the in-App (SDK) approach, where the interface used to access your services (a mobile App, a client, a browser) is turned into an authentication device with no action on the user side. Here’s a short article about inWebo in-App MFA framework.
- User convenience: Carrying, plugging, and operating a smartcard reader to access your services requires a lot of motivation from the users. Copy-pasting a one-time code from an App or a client or a physical device used to be considered as “okay”. Validating a connection request with a swipe in an App is definitely easier, but your users might think differently if they’re required to do it constantly. It’s a UX trick: to evaluate user convenience, multiply the complexity of a single authentication with the frequency of such transactions for a user. Again, the in-App approach is the easiest one since it doesn’t require users to carry or operate a specific device – be it a phone -, or even to copy-paste codes. There’s more to read here on this topic.
Security & reliability
I will be short here because I’ve covered this topic in an other post; an MFA solution is a service, therefore its security and its availability matter. From both perspectives, MFA is a single point of failure in your architecture. Also, different MFA solutions protect against different risks. For this, I forward you to this article. Prior to making a choice, you need to know which risks you want to cover.
This criteria is never highlighted enough, because MFA vendors don’t want to scare you with how painful operating MFA in your organization will be. Well, the more the MFA solutions comes with automation and self-service options, the better your life as an administrator of this solution will be. Again, a short article about this topic.
This is an obvious criteria: the MFA solution should support or integrate with the applications that you want to protect. The questions to ask are different for onprem or cloud applications. Going forward, this is mostly about checking the protocol boxes (radius, SAML 2.0, OIDC) or the 3rd-party vendor boxes (VPN vendors, SSO/federation vendors, virtualization vendors, etc.).
Through acquisition or in-house developments, many IAM vendors are now offering MFA capabilities (Microsoft, Ping, Okta, Core among others). It’s therefore easy and tempting to have a one-stop-shop approach and get MFA bundled with IAM. It usually even makes sense financially. On the flip side, you would be in a vendor lock, should you decide to use applications outside the ecosystem of the IAM vendor. Also, from a product, innovation and security perspective, best-of-breed approaches could be much more advantageous. Remember that interfaces and protocols between IAM and MFA follow standards, so there’s actually no interoperability risk in taking a best-of-breed approach here, unless the IAM vendor intentionally limits the openness of its product – in which case you should question whether choosing this IAM vendor is a good idea in the long run.
Another question related to vendor strategy is whether you should only consider analysts-sponsored vendors. There are 2 situations here: either MFA is not an important topic at all for your organization, and you probably don’t need an analyst opinion. Or it is an important topic, and you should probably make your own opinion. Of course, listen to what your peers have to say about this or that vendor, and challenge their credentials.
Is compliance a selection criteria? Most regulations and supporting standards – HIPAA, PCI DSS, GDPR, PSD2, NIST, eIDAS, etc. – apply to organizations having to implement and enforce MFA rather than to MFA providers or solutions. Most regulations don’t actually mandate anything about the MFA solution itself. There are some exceptions, such as PSD2, eIDAS, or NIST. So, depending on your industry and what compliance obligations you have, and even if you must implement MFA, you might or might not have requirements extending to the MFA solution itself.
Are standards important?
- Yes, definitely for identity protocols that applications use to “talk” to authentication solutions. Most of these standards – such as SAML, OIDC – are community-driven.
- Yes, obviously for cryptographic standards. Run away from a vendor who would have built its solution on a proprietary implementation of cryptographic primitives. The problem is that it’s difficult to know how good or bad an implementation is. For this you need an independent security audit, or to rely on audits performed when vendors have their products pass a security certification such as FIPS, Common Criteria, etc. However, few MFA vendors have such certifications.
- Not really for authentication standards that authentication devices and validation servers use to “talk”. Most if not all such standards are vendor-driven. They can’t do any harm, but ask yourself what benefits you get from them.
A vendor-neutral conclusion would be: know your organization’s goals, do your research, and make your opinion.
A vendor-biased conclusion would be: include inWebo MFA in your research. We’re a focused yet successful vendor and a profitable company investing most of its revenues in innovating for its customers.