It’s well understood that implementing multifactor authentication (MFA) on user accounts significantly improves security. MFA is the practice of requiring users to provide ‘something’ in addition to their password before they can access their accounts. For example, it might be a code from a mobile authentication app or a biometric gesture like a fingerprint.
While MFA isn’t impossible for hackers to bypass, it’s extremely rare that accounts protected by MFA are compromised. So, if the security benefits are so high, why isn’t MFA more widely adopted? Microsoft has been using MFA on so called Microsoft Accounts (MSA), which are used by consumers for logging into services like Xbox and Hotmail, since 2012. As part of this program, metrics were used to establish the effectiveness of different protections and to establish a security minimum standard.
MSA users are required to register a second factor but aren’t challenged every time they log in. Microsoft only challenges MSA users when there is some indication of risk, like someone trying to brute force their way into an account. This led to a 6-fold decrease in compromised accounts.
In 2014 Microsoft launched MFA in Azure Active Directory (AAD), its identity management solution for cloud-born apps. AAD can also be connected to work with Windows Server Active Directory. Almost all compromises of organizational accounts can be stopped by MFA and the other protections that Microsoft has deployed for MSAs, like forcing users to change their password when a risk is detected.
But Microsoft admits that it hasn’t been entirely successful in persuading companies to enable MFA, regardless of marketing and pushing MFA as much as possible. And it makes sense that many businesses are simply looking for the easiest way to get started with AAD and aren’t concerned much about security. So, Microsoft has decided to take a different approach.
After testing different ways to better protect organizational accounts, like baseline settings protection, and liaising with partners and customers, Microsoft came up with Security Defaults. The idea is to provide a secure baseline for all customers from the get-go. And that means all users and administrators must register for MFA, challenging users with MFA when they sign in to new devices and more frequently for admins, and disabling legacy authentication protocols in legacy clients that don’t support MFA anyway.
Microsoft is planning to enable Security Defaults in full for all clients eventually. But as MFA prevents more than 99.9% of account compromises, Microsoft has decided that is the best place to start. Security Defaults isn’t designed to replace more advanced features of Azure AD, like Conditional Access. But it is intended to provide a safer baseline for all business. And especially those that don’t have the necessary resources to focus on security.
Initially, Microsoft has enabled Security Defaults only for new Azure AD tenants. But five thousand existing tenants have chosen to enable Security Defaults. Not all new tenants are getting Security Defaults from the get-go as Microsoft looks at success rates. But the idea is to make sure that in the future, all new tenants get Security Defaults enabled from the beginning. Then Microsoft will expand the program so that existing tenants not using Conditional Access get Security Defaults enabled.
For organizations that would like to enable Security Defaults without waiting for Microsoft, they can do so in the Azure management portal.
Don’t forget that changing security settings can impact functionality, so you should evaluate the changes made by enabling Security Defaults before taking any action in a production environment.