With the landscape of technology today, data protection with multiple layers of security is a critical component of any business. One of the most important of those layers is the use of Multi-Factor Authentication (MFA). We’ve covered the importance of MFA in the past including its role in securing your remote workforce. But if you are administering a tenant at one of the million+ businesses that utilize Microsoft 365 for their needs, you may be wondering what the best method is for enforcing the use of MFA. Are Microsoft 365 Azure security defaults sufficient enough to protect your Microsoft tenant and user accounts? Let’s find out.
Microsoft provides three methods for enabling MFA within a Microsoft 365 tenant:
Per-User MFA and Conditional Access allow itemized and granular control over your deployment. Security Defaults, on the other hand, is a set of non-customizable baseline standards that are designed to provide your tenant with multiple layers of protection including Multi-Factor Authentication.
Since its inception, there have been many questions surrounding Microsoft’s Azure Security Defaults such as whether its policies are sufficient enough to protect all of your tenant’s accounts with MFA. We’ve put Security Defaults through the ringer in order to help answer that question. So is Azure Security Defaults a sufficient method for protecting your Microsoft 365 tenant? Continue on to find out.
What do Security Defaults actually do?
When you enable Security Defaults for a Microsoft 365 tenant, there are back-end security policies that take effect within the tenant. These policies are not directly visible nor can they be altered. They perform the following functions:
- Require all users to register for MFA.
- Require the use of MFA for all sign-ins performed by Administrators.
- Block legacy authentication protocols (IMAP, SMTP, POP3).
- Require users to perform multi-factor authentication when necessary.
- Protect priviliged activities like access to the Azure portal.
Sufficient for admins?
For those accounts within your Microsoft 365 tenant that have any level of administrative rights, Security Defaults will provide you with MFA enforcement for all of your sign-ins moving forward. This alone makes the use of Security Defaults sufficient for helping to protect your admin roles. The risk of compromise for accounts with admin roles assigned will decrease dramatically as a result.
Sufficient for end users?
When reviewing the list of functions that Security Defaults performs, the actions that apply to end users are a bit vague.
The first statement in the list performs as expected. After enabling Security Defaults, all end users will be required to enroll in MFA for their account. Users will be given a 14 day grace period to set it up starting from their next interactive sign-in. This task has been reliable for getting users enrolled with the MFA service.
The fourth statement in the list though leaves a lot of room for interpretation. “Require users to perform multi-factor authentication when necessary”. Microsoft has not officially published a definitive list of what “when necessary” truly means but has stated at times that it is dependent on the risk level auto-defined within Azure during account sign-in.
In our testing and experience, this method of enforcing MFA for end users is not sufficient due to sign-in risk not being accurately assessed. To determine this, we performed multiple rounds of sign-in testing with internal accounts.
Tests performed
If relying on artificial intelligence to detemine whether MFA should be used during an end user’s sign-in, we should assume that it can accurately detect when a sign-in attempt seems suspicious. One such example would be if an account attempts to sign in from a new geographical location.
To test whether that type of behavior would trigger MFA, we setup a test account with multiple internal tenants and performed sign-in attempts globally within a short time period. Each test was performed multiple times over the course of a few weeks.
Using managed infrastructure and proxied traffic, each test included sign-ins from at least three of the following geographical areas with at least one being outside of the United States of America:
- New York, USA
- Pennsylvania, USA
- California, USA
- The Bahamas
- Hong Kong, China
When performing these sign-in tests with a non-admin user account, there was no triggering of sign-in risk which resulted in no MFA being used. Azure sign-in logs confirmed that each sign-in was reported as “no risk” and that the sign-in completed successfully using single factor authentication.
At no time during these rounds of sign-in testing or other miscellaneous testing of Azure Security Defaults were we able to get MFA to be triggered for a non-admin account. Attempts to get this resolved with Microsoft has been unsuccessful. Instead, we have been told that this is expected behavior because Azure had not classified the sign-in attempts as high risk but could offer no further explanation as to why.
Is it worth enabling?
As a result of our internal testing and external research that matches our findings, we cannot recommend relying solely on Microsoft 365 Security Defaults as a sufficient method of enforcing the use of Multi-Factor Authentication for your Microsoft 365 tenant. It does, however, serve as a good baseline that should be enabled if you will not be using or do not have licensing that allows Conditional Access.
If you do enable Security Defaults as your general baseline protection, you should utilize Microsoft’s Per-User MFA enforcement method to effectively protect the accounts of your end users.
At Diligex, we specialize in Microsoft 365 security and management. If you are not currently a client and would like further information about how we can help protect you and your team, feel free to contact us and we will be in touch.