When to merge IAM and MFA

Among others, IAM policies define how users need to authenticate when they request authorization or access to resources. More and more organizations implement multi-factor authentication (MFA) to enforce secure yet frictionless authentication.

Historically, MFA solutions have been provided by specialized vendors such as inWebo, but now also increasingly by IAM vendors, as an option. In this post, we discuss the pros and cons of both models, i.e., when you should merge IAM and MFA.

IT vs. Cryptography

Before we tackle that question, let’s first understand the technologies employed by IAM and MFA vendors, i.e., the required skill set.

IAM is fundamentally and literally an identity application, built with directories and application servers running workflows as well as protocols such as oauth, Kerberos, or SAML.

On the other hand, MFA is a client-server application implementing cryptographic algorithms for proof generation and validation. So that it provides additional security compared to password-based authentication, MFA must implement a protection of user credentials both with the user authentication device (acting as the authentication client) and with the validation service or server. That protection can be in the form of a “secure element” or a strong mechanism (such as inWebo’s random dynamic keys) for the user authentication device, and in the form of Hardware Security Modules (HSMs) for the validation server.

MFA solutions – from IAM and MFA vendors alike – implement very different levels of protections and it can be tricky to understand from their marketing material how secure solutions actually are (this article explains inWebo’s security model).

In short, IAM requires primarily IT skills, MFA primarily cybersecurity and cryptography skills. These are 2 completely different skill sets.

Relations vs. User Experience

Another fundamental difference between IAM and MFA is how they impact end-users. IAM is a set of rules defining who has access to what. MFA (and authentication in general) is what users experience when requesting access or authorization.

IAM is the guest list for the party. MFA is the set of required credentials to show at the entrance in order to get admitted. Of course, as the organizer, you need both the guest list and the admission requirements in order to make sure that your party won’t be crashed by a stranger or this vague acquaintance whom you definitely didn’t invite. However, although rejecting unwanted strangers is the primarily objective of the set of required credentials, you don’t want to bother your guests with too much screening when they arrive, or even worse, that they get rejected by your bouncer just because they’re not able to pull out their invitation from their phone.

MFA walks the fine line between adding actual security – not just a sense of security – by blocking unauthorized users and maintaining a frictionless and ideally invisible check for legitimate users. There’s much more UX (user experience) design involved in MFA and security than you might have thought!

Since good UX is far from obvious, MFA solutions vary a lot in this respect too. Traditional (and expensive) hardware authentication keys have been replaced with smartphone Apps that are obviously cheaper but sometimes require employees to use a personal device to access their work environment or result in the same “authentication fatigue” for the users. Flexible MFA solutions such as inWebo offer more authentication options and therefore are more likely to reconcile the cost objectives of organizations with the end-user expectations about authentication.

Identity silos vs. Universality

Traditional IAM solutions record user profiles and authorizations in a directory such as AD, AAD or Google. Inevitably, this limits your flexibility; you’re only able to employ IAM with applications a/ that happen to have implemented the protocols that your IAM solution supports, and b/ for which all user profiles are held in a single directory. If for some reason – merger, acquisition, reorganization of previously independent divisions etc. – applications have users in different types of directories, you’re likely to be stuck. Indeed, most IAM solutions work in identity silos and unless you implement projects reducing these silos – that are among the most complex to manage IT projects -, it can be very hard to get the full benefits of IAM.

MFA solutions such as inWebo do not require identity silos to have been merged, thus resulting in more agility to implement security. Indeed, there’s usually no need for an MFA solution to know whether or not users JSmith for the VPN and JohnS for Office 365 are the same person or even if they belong to the same organization (and no need either to know their real login, MFA can work with privacy-respecting aliases). If this was the case, John Smith would see 2 identities and services attached to his authentication device(s) and he can definitely live with that for some time.

To merge or not to merge?

As you had probably already guessed it, there’s no single answer that works for every organization. However, the criterion that we’ve analysed in this post should help you determine what model fits you best.

As a rule of thumb, smaller IT organizations that have a unique and centralized directory architecture, use mostly cloud business applications, have limited security requirements, and prefer to limit the vendors ‘sandwich’ in their IT, are likely to prefer the integrated model, i.e., MFA provided as an option by their IAM vendor.

Whereas more complex IT organizations understanding the differences – in particular in terms of technology lifecycle – between IAM and MFA are more likely to keep them separate in order to get the best products in both categories but also to stay flexible and adaptable.

If your organization doesn’t easily identify with these over-simplified models, ask yourself what your requirements for MFA are – user experience, security, adaptation to a complex or likely to evolve directory architecture, etc. This will help you determine if you can live with the – usually simpler – 2FA option of your IAM solution vendor or if you better look for a specialized vendor meeting your more advanced needs.