When do you need MFA? Balancing security, regulation, and business needs

When do you need MFA

According to analysts, IT-security spending is expected to grow at least twice faster than IT-spending this year (2019). This is both an acknowledgement that the environment is increasingly risky and a realization that investments in IT-security have been too weak until recently. If you’re an IT-security professional, this is certainly a good news since your organization acknowledges in its budget the importance of your work. But don’t dream too high, you will still need to prioritize security projects for the years to come.

Prioritizing MFA projects

For the sake of this blog post, let’s focus on authentication. Unless you’ve just waken up from a long coma, you know that password-based authentication is now considered as very weak and that it bothers both users and IT-support. Also, unless you don’t use email yet, tens of vendors (not counting analysts) must have made you aware of technology advances in authentication.

So, now you have a budget and valid technical options, but chances also are that password-based authentication is widespread in your organization.

If you start listing the instances, you will probably end up with a much longer list that you had thought: remote access & VPN, privileged access management for administrators, a ton of business and productivity applications (some in the cloud, some legacy onprem ones as well), the virtual desktop environment, the session logon on laptops and Active Directory, several web portals for your supply-chain partners and your auditors, a project management portal for your offshore teams… and, oh, of course, the customer authentication for your product / platform / portal / App / service. Finally, if you look far enough, you probably have a plan to get rid of the various badge systems that have flourished for the canteen, the buildings access, guest visitors, etc.

There’s a reason why passwords and badges are still so much in use: we have been letting them proliferate for ever. Now, they are everywhere. Assuming you work for a ‘normal’ organization – one with budget and resources constraints, what do you need to consider? How and where can you realistically achieve visible results?

Security requirements

This is the most obvious reason to replace password-based authentication with more advanced forms of authentication (MFA). Security (criticality) is also a criteria that can be objectively evaluated for the applications that compete for your authentication overhaul budget.

Which system(s) breach or abuse would you not want to have to report to the organization’s management in your worst nightmare? Probably those that would have the largest financial consequences and/or would stop the production and/or would expose the organization the most.

This is a simple way to sort and to decide where you want to start (or continue) your program. Privileged access management is most certainly in your top-5 priorities since an account takeover would have huge consequences. Session logon is probably too since most organizations use AD as their main directory. SSO/IAM for the same reason. VPN, still. The organization’s board meeting App. The application used by customer service agents to reimburse customers. The loan application workflow storing SSN and bank details. Etc.

Regulation constraints

Regulation is industry-specific and geography-dependent.

If you are a bank or a FinTech company offering payments in Europe, you must now enforce SCA (strong customer authentication) for a wide range of online payments. If you operate in Healthcare, in most geographies, you must take appropriate measures to protect access to patient and other healthcare data, which likely include reinforced authentication for certain user segments such as healthcare professionals and patients. If you operate an e-commerce platform and haven’t completely outsourced payment, you must protect back-end access to card data with MFA. If you are a DoD contractor in the US processing some types of data in your systems, you must take a whole series of measures – including MFA – to protect these data. Etc.

As a rule of thumb, what you must protect due to regulatory constraints probably does not overlap with what you have prioritized for security reasons. Regulation focuses on the potential impacts on the ecosystem, whereas your security-driven analysis probably focuses on risks immediately impacting your organization.

The good thing with regulation constraints one might say is that you don’t really have a choice to follow them or not, although you sometimes have some leeway in how quickly you need to comply. Therefore, the organization’s management is less likely to cut that budget.

Business needs

Although it’s unlikely that Product or Business leaders will spontaneously come to you (an IT-security professional) and ask for more security with the organization’s customer-facing applications, that aspect should not be underrated or dismissed.

Your B2B customers might have regulatory constraints that mandate MFA to access your application; or they might want this security as a consequence of their own risk analysis; customers might evaluate your trustworthiness as a partner or provider by how you handle privacy and security for these applications. The old claim that “we enforce enterprise-grade encryption” no longer fools anyone – if it ever has.

Let’s be honest, the real pressure is with B2B customers. Not with consumers who, simply put, don’t care. Google has given users the (entirely free) option to enable 2FA on their Gmail for almost 10 years now and only a few percents do it. Similarly, you might want to give B2B customers the possibility to enable MFA with your applications. After all, it’s their risk, not yours – assuming these applications don’t fall in the above categories where you will enforce MFA due to your risk analysis or regulatory constraints.

Also, consider that authentication is a user-centric topic. Therefore, the right way to offer MFA on your applications, for B2B customers at least, is to design these applications as SAML (or OpenID Connect) Relying Parties, not to tie them to an additional MFA method that end-users will need to add to their keychain or their smartphone. By doing so, you will give a full control to customers on how they want to manage the security of their data and their users. Put yourselves in their shoes, you would want that too.

Further considerations around MFA

Let’s assume here that business needs are out of the table – because they’re not important or because you’ve outsourced that question to your B2B customers as we’ve explained above. Therefore, you’re left with a list of applications or services or accesses where MFA is needed or mandated. The items on that list probably fall into 2 categories: internal applications (i.e., for users that you manage) and external ones.

Focusing on the users that you manage, think of MFA as a service that you need to enable for as many internal applications (the first category) as possible so that those users won’t have to deal with different forms of MFA for each access. This is the same idea as single sign-on (SSO), here with MFA instead of passwords but also with applications that might not support SSO.

Therefore, make sure that the MFA solution vendor you’re considering supports the various internal – at least – applications that you have included in your list, especially when that list is heterogeneous (e.g., VPN, session logon, PAM, cloud applications). There are other criterion to take into account when assessing an MFA solution (see this post), but universality is the single most important for that solution to be both future-proofed and well accepted by end-users.

Written by Didier Perrot