How to enforce multi-factor authentication on Microsoft 365 (Office 365) using Security Defaults
What is Security Defaults?
Security Defaults enables MFA for everyone. It's simple, quick and available to everyone regardless of license. However, it's inflexible, with no configuration options, and must be applied to all accounts.
Once enabled, Security Default makes following changes in your tenant:
All users must register for MFA within 2 weeks from their next interactive login - no users can be exempt from requiring MFA.
Only authenticator-style apps are permitted as MFA methods - this is a secure method and one we would recommend anyway.
Admins will always be prompted for MFA on login.
Users will be prompted for MFA "when necessary" (this is not strictly defined by Microsoft but includes when users show up on a new device or app, and for critical roles and tasks).
Access to Azure portal, Azure CLI or Azure PowerShell by anyone will always require MFA.
Legacy authentication is disabled because it doesn't support MFA. Security Defaults is all or nothing — there are no choices or configuration options. That said, it offers sensible options that suit most small teams.
To decide if Security Defaults is right for you, you should consider four things:
When Security Defaults is enabled, all accounts in Azure AD must use MFA. This includes unlicensed users, break-glass accounts, and service accounts.
Any accounts that login to Azure AD autonomously, such as service accounts, will stop working as they cannot use MFA - the only exception is the Azure AD Connect sync account.
If you have service accounts that only operate on-premise and never login to Azure AD, they will remain unaffected. Although they will be "required" to use MFA when logging into Azure AD, if they never do so then they are unaffected. If you have accounts like this, you might want to consider filtering them from your Azure AD sync.
If you have accounts which are affected by this and there is no alternate way of working, you may have to consider the Conditional Access approach - which allows for exceptions - or the legacy MFA approach - which allows for per-account configuration.
Once Security Defaults is turned on, users who haven't registered for MFA will be prompted to do so for two weeks. After this, if they still haven't registered for MFA they will be forced to do so before their next login.
If two weeks seems a bit tight, you can use Push to track progress in your own time and then turn on Security Defaults when you are ready. Users will not be prompted for MFA on login, even after registration, until you turn on Security Defaults - so your security posture will only minimally improve until then.
Don't discount the value of a hard deadline; if after two weeks users still don't register for MFA they won't be locked out, they will simply be forced to register before their next sign-in completes.
Security Defaults requires an authenticator app, which will send push notifications to a registered device, as your second factor of authentication. This is a secure MFA method but means everyone must have access to a device where they can receive notifications.
If any of your users don't have access to a smartphone or tablet (or aren't willing to install the Microsoft authenticator app), you will not be able use Security Defaults.
Want to learn more about MFA methods and choosing the right option for you? Read more on our blog.
Legacy authentication doesn't allow for MFA usage and it is therefore disabled with Security Defaults. Follow the steps in this guide to ensure you aren't using legacy authentication and that modern authentication is enabled on your tenant — it is critical you confirm both these steps to ensure nothing breaks when Security Defaults is enabled.
If you choose this option, we will guide you through preparing the necessary parts of your environment before turning it on.
Once you're ready, you've got two choices:
Turn it on immediately: Give your users 14 days to register and just get it done.
Encourage adoption first: For minimal disruption, you can use the Push platform to monitor and encourage user registration before turning it on when you know most users are already registered.
How to start
Configuring your environment
Security Defaults is designed to be simple so all you need to do beforehand is make sure you aren't using legacy authentication:
Stop using legacy authentication
Before you can block legacy authentication, you must make sure no one in your organisation is using it. For example, does anyone use Office 2010 or 2013 still? Office 2010 doesn't support modern authentication and Office 2013 doesn't use it by default. Blocking legacy authentication without first modernising any legitimate use will likely break things in your team.
Depending on the age of the your Azure AD tenant, you might need to also enable modern authentication.
Follow the official Microsoft documentation on blocking legacy authentication that includes steps to find accounts that still use legacy authentication, and instructions to enable modern authentication.
If you are curious about what legacy and modern authentication is and want more background, read this blog post by the Microsoft Identity team.
Get your users registered for MFA with minimal effort using the Push platform
Before enforcing MFA, you should aim to get most users registered for MFA to avoid disruption but figuring out who needs to register and engaging with each of them is a hugely time-consuming process.
Use the Push platform to quickly see who hasn't registered for MFA yet and use ChatOps to engage with them automatically to get it done with ease.