In a world where the majority of data breaches start with weak or stolen credentials, many businesses have added an extra layer of protection to employee accounts with Multi-Factor Authentication (MFA).
MFA, in a nutshell, requires users to go through multiple steps to ‘prove’ they are who they say they are. While there are multiple ways this can be done, it involves something the user knows (like a password), something they have (like a token or a phone), and something they are (like a fingerprint). If the response to all the different factors are correct, that user can most likely be trusted. There is no doubt that MFA is a far more robust authentication method than passwords alone, or even Two-Factor Authentication (2FA). It should be enabled on all services that support it.
With more authentication processes, however, comes wider implications when things go wrong, particularly when linked to the business’s wider infrastructure. Not for security reasons but instead for continuity, as users of Microsoft discovered when its Azure Active Directory MFA services went down for 14 hours in November. This is the service that Microsoft 365 and Dynamics users use to authenticate, meaning a number of customers were locked out of their accounts, which unsurprisingly resulted in a huge amount of frustration. There were a number of reasons the outage occurred, and Microsoft has taken steps to improve its MFA service, but that may not be much consolation to those who were unable to access critical business applications for a day.
While bundling business operational services and security services together into a suite of products seems like it’s a good idea for ease, integration and cost, short-term gain can result in long-term expensive pain.
What do users need from an authentication solution?
Other than for it to allow them to access what they need (which should really be the bare minimum), users need security tools that aren’t overly intrusive or complex – they need to not mind having to use it. That means ensuring an MFA solution is as low friction as possible and authentication is proportionate, with users only challenged when there is reason to believe risk, or level of assurance, has changed. For example, if an employee logs in from a different geolocation it makes sense for them to be challenged. If they’re logging in from home, where they regularly access applications or services from, it may not be necessary to require MFA. Teams need to work with MFA – not against it – and choosing a solution that is intelligent and adaptive (or context-based) will help in providing a positive user experience.
Of course, the primary function of MFA is security and so any solution needs to include extremely secure One Time Passcodes (OTPs) that are session specific to protect against phishing and other attacks. The way passcodes are delivered also needs to be flexible, offering a choice of delivery – whether that’s email, SMS, a mobile app, or voice. Critically, you’ll also want a solution that provides automatic failover between methods. The last thing the help desk needs is floods of calls from attendees at the annual sales kick-off informing them that they can’t access the CRM system as they don’t have a phone signal at the venue. Flexibility offers high delivery assurance, particularly to travelling users.
Considering whether or not to bundle MFA in with another suite of products is a worthwhile contemplation. While all your emails may well be delivered and sent by Microsoft 365, your applications will likely be from many different business software vendors and you need a solution that can work across multiple apps, systems and services for it to provide real value. Support for just one vendor’s suite of products isn’t really a robust solution.
Finally, and possibly most importantly given the subject of this post, any security solution should be kept separate from the rest of your Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) estate. Similarly, any identity assurance and authentication solutions should be kept separate from core services and critical business applications, including email. Doing so will mean that should one service go down, access to others isn’t prohibited – and the cascading effect will be limited.
