Wait….what? Did I just read that right? Why would using and enabling MFA be the downfall of security? Well, let me explain more.
But, before I go into that and setting the stage a bit, I caught a headline in one of my news feeds that said MFA usage was 99% effective at stopping attacks. On top of that, in the survey and details of the report, it said that enterprises are at about 57% implementation of MFA for their organizations. That sounds pretty good from a statistic standpoint. But, I also caught another breach notice in the same thread talking how remote access was compromised even though MFA was enabled for the user.
This got me thinking; if something is 99% effective, yet I see multiple articles of being compromised with it enabled, is it really that effective?
To answer this, lets go back to the title of this article, MFA being the downfall of security. The intent of MFA is to provide a second prompt or authentication to better assure the validity of the authentication request. Which, in theory is what we are striving to achieve. But, as an industry, we have implemented this in every application, transaction, indiscriminately and as such it has lost its intent with our users to a point they have become accustomed to just accepting the prompts and notifications when they receive them. In essence, over usage of MFA prompts has diluted the validity of the prompts thus training users to just accept without regard to activities. The security we put in place has become a false wall given users have become accustomed to just accepting the prompts regardless of usage.
If at 57% saturation of MFA (based on the survey) and we are already losing the value of MFA given the continued issues, how do we restore the security provided by MFA?
MFA, when used appropriately and with intent, is a strong means of authenticating a principal. But, we need to look at traditional ideas of MFA (SMS, Email, Push, etc) as more outcomes and factors beyond just enabling them. Using adaptive technologies that can identify common usage patterns, profiles, etc. as part of the authentication evaluation with an additional outcome to prompt the user when a change has been detected is more effective at providing security than continuously sending MFA prompts. Additionally, reducing the amount of prompts to the user will restore the awareness and intent of MFA to help identify possible misuse.
The main challenges of moving to this type of architecture will include:
- Licensing: This could be an additional ‘feature’ on top of existing MFA policies (e.g. Conditional Access Policies, Adaptive MFA License, etc.) which may not have been originally planned.
- Training: We need to train the risk engine and analysis to identify common patterns, device profiles, etc. which takes time. The initial rollout may not provide the intended outcome until this can be built into the patterns and responses.
- Audit / Compliance: Looking at Cyber Insurance, Regulatory, Statutory requirements, they are requiring MFA to be enabled for remote access and high risk. The original response (and point of this article) is to just enable MFA. But, we need to write our control documentation to make the adaptive authentication and outcomes the actual MFA, not so much the factor.
- Retraining Users: As we implement these to improve the user experience, we also need to retrain users to know that when they get a prompt, this is because something has changed in their normal usage patterns. As such, if they suspect nothing has changed, this should trigger a warning to 1) not accept the MFA request and 2) notify the security organization for investigation.
While not perfect moving to a more adaptive model for MFA, in the long run this will be more effective at authenticating users and allow us to get to 80% / 90% / 100% saturation of MFA without impacting user awareness and experience.
