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.

Want to learn more about Security Defaults? Check out the official documentation and read the original blog post from Microsoft which outlines the intention and design of Security Defaults.

Before you start

Get business buy-in

Big changes that people notice tend to benefit from an executive sponsor to lend weight behind the change - you'll know better than us whether that makes sense for your organisation. You can read this guide for some pointers.

Prepare your support team

When adopting MFA, some users may struggle with the process of enrolling for MFA, or need help if they lose their MFA token or device after setup. Users will have a much better experience of MFA, and work disruption kept to a minimum, if the IT support team (or person as the case may be) is prepared to support both enrolment and recovery, and can get them back on their feet quickly.

To make sure everything goes smoothly when something goes wrong, we recommend you make sure anyone responding to support requests tests or practices these processes using a test account.

Is this the right approach?

To decide if Security Defaults is right for you, you should consider four things:

  1. 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 are unsure if an account is actively logging into Azure AD, check the Azure AD sign-in logs.

    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.

  2. 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.

  3. 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.

  4. 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:

  1. Turn it on immediately: give your users 14 days to register and just get it done.

  2. 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.

Let's get started!

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.

Enforcing MFA

When you are ready to do so, enabling Security Defaults is quick and simple by following the steps below.

To follow this guide you will need:

  • The correct role: the

    Security Administrator
    ,
    Conditional Access Administrator
    , or
    Global Administrator
    roles are needed to perform these steps.

Step 1

Navigate to the Azure Active Directory blade in the Azure Active Directory admin center.

Step 2

From the side menu, select Properties:

M365: Azure AD, Properties

Step 3

At the bottom of the page, select "Manage Security Defaults":

M365-manage-security-defaults

Step 4

A side menu to "Enable Security Defaults" should appear with a single control to enable Security Defaults. Slide it over to Yes.

M365-enable-security-defaults