Implementing Azure Security Defaults for Enhanced Protection

Azure Security Defaults is a set of pre-configured security settings that provide enhanced protection for your Azure resources. It's designed to help prevent common security threats and reduce the attack surface.

MFA is enforced for all users, including global administrators, which adds an extra layer of security. This setting can be customized to exclude specific users or groups if needed.

Azure Security Defaults can be enabled in the Azure portal, under the Azure Active Directory (Azure AD) section. It's a simple process that only takes a few clicks.

By enabling Azure Security Defaults, you're automatically enforcing Conditional Access policies that require MFA for all users. This helps protect against credential theft and phishing attacks.

To enable Azure security defaults, you'll need to sign in to the Microsoft Entra admin center as at least a Security Administrator. This role is assigned to the first account in any directory by default.

You'll want to browse to Identity > Overview > Properties to find the Manage security defaults option. Selecting this option will allow you to enable security defaults.

To enable security defaults, you'll need to set Security defaults to Enabled and then select Save. This will apply the security defaults to all users in the organization.

If your tenant was created on or after October 22, 2019, security defaults might be enabled in your tenant. Security defaults are being rolled out to all new tenants at creation to protect users.

You'll need to have at least the Security Administrator role to configure security defaults in your directory. This role is also assigned to the first account in any directory by default.

To avoid confusion, refer to the email you received about the automatic enablement of the security defaults. Alternatively, you can disable security defaults after it's enabled.

If you don't have any Conditional Access policies, don't have premium licenses, and aren't actively using legacy authentication clients, you'll be periodically notified about the automatic enablement of security defaults.

Starting July 29, 2024, new tenants may not have the 14-day grace period for users to register for multifactor authentication, which can block over 99.2% of identity-based attacks.

All users have 14 days to register using the Microsoft Authenticator app or any app supporting OATH TOTP. After the 14 days pass, the user can't sign in until registration is completed.

A user's 14-day period begins after their first successful interactive sign-in after enabling security defaults. This measure helps prevent users from falling for MFA fatigue attacks.

To ensure all your admins sign in after enabling security defaults, have them register for authentication methods.

Here are the administrator roles that will be required to do multifactor authentication every time they sign in:

You should require multifactor authentication for all users, not just administrators, to protect against attacks that target end users.

With Azure Security Defaults, users are required to register for and use multifactor authentication using the Microsoft Authenticator app using notifications. This is a mandatory step for all users.

Users can also use third-party applications that support OATH TOTP to generate codes. This is a convenient option for those who prefer using a different authenticator app.

To avoid locking yourself out of your tenant, do not disable any authentication methods if you're using security defaults. This is a crucial step to ensure you can still access your account.

Here are the available authentication methods that can be used with security defaults:

Conditional Access and Policies are a crucial part of Azure Security Defaults. You can move from security defaults to Conditional Access policies, which provide a full range of customization that more complex organizations require.

To move from security defaults, you'll need at least Microsoft Entra ID P1 licenses, and you can customize policies fully. Security defaults are enabled by Microsoft or an administrator, while Conditional Access policies are enabled by an administrator only. This makes Conditional Access policies more complex to use, but also more customizable.

To replicate the policies created by Azure AD Security Defaults, you can use Conditional Access policies with Azure AD Premium P2 licenses. However, most policies can be accomplished using the Azure AD Premium P1 license.

If you're using Baseline policies, you'll need to remove or disable them before enabling security defaults. This is because Baseline policies conflict with security defaults.

Access to the Azure portal is a privileged activity that requires extra security measures.

The Azure portal, Microsoft Entra admin center, Azure PowerShell, and Azure CLI are all services that can be accessed with single-factor authentication, which is vulnerable to attacks like phishing and password spray.

To verify the identity of users accessing these services, multifactor authentication is required. This policy applies to all users, whether they're an administrator or a user, and includes Azure Resource Manager APIs such as accessing subscriptions, VMs, and storage accounts.

The Microsoft Entra Connect synchronization account is excluded from security defaults and won't be prompted to register for or perform multifactor authentication.

Security Defaults have replaced Baseline conditional access policies, and Microsoft will stop enforcing Baseline policies on February 29.

If you're using conditional access policies, you won't be able to enable Security Defaults until you remove or disable those policies. In my case, I had to disable Baseline policies for MFA Admins, MFA All users, and Disabling legacy authentication to enable Security Defaults.

To resolve this, you can click on the policy and change the enablement to "Do not use the policy."

Security defaults are a good baseline to start your security posture from, but they don't allow for the customization that many organizations require. Conditional Access policies provide a full range of customization that more complex organizations need.

To move from security defaults to Conditional Access, you need at least a Microsoft Entra ID P1 license. Security defaults are simple to use, but Conditional Access is fully customizable based on your requirements.

Recommended steps when moving from security defaults include immediately enabling Conditional Access policies to protect your organization. These policies should include at least those policies in the secure foundations category of Conditional Access templates.

Organizations with Microsoft Entra ID P2 licenses can expand on this list to include user and sign-in risk-based policies to further strengthen their posture. Microsoft recommends that organizations have two cloud-only emergency access accounts permanently assigned the Global Administrator role.

To replicate the policies created by Azure AD Security Defaults, your customer's tenant must be licensed with Azure AD Premium P2. However, the majority of policies can also be accomplished using the Azure AD Premium P1 license.

Here are some Microsoft documented guides on how to use Conditional Access to configure equivalent policies:

Note that the last policy requires Azure AD Identity Protection feature of Azure AD, which can be provided via Premium P2 license.

Legacy authentication is a major security risk, and Azure Security Defaults can help mitigate it.

Most compromising sign-in attempts come from legacy authentication, which doesn't support multifactor authentication. This means an attacker can bypass multifactor authentication by using an older protocol.

If you're using an older protocol like IMAP, SMTP, or POP3, you're at risk. Security Defaults will block these authentication requests, but only after you've enabled it in your tenant.

To avoid login loops while authenticating through pre-2017 Exchange Online tenants, you must enable modern authentication. This is because modern authentication is disabled by default in these tenants.

Security Defaults won't replace your Azure AD licenses. If you're already using P1 or P2 licenses, you can use conditional access instead.

Disabling legacy authentication is an essential step in securing your Microsoft environment. It's a common method to improve protection for all users.

To do this, you need to block clients that don't use modern authentication, such as an Office 2010 client. Any client that uses older mail protocols like IMAP, SMTP, or POP3 should also be blocked.

After security defaults are enabled in your tenant, all authentication requests made by an older protocol will be blocked. This includes Exchange Active Sync basic authentication.

Before you enable security defaults, make sure your administrators aren't using older authentication protocols. For more information, see How to move away from legacy authentication.

Pre-2017 Exchange Online tenants have modern authentication disabled by default. This can cause a login loop while authenticating, so you must enable modern authentication to avoid this issue.

Here are some examples of clients that should be blocked:

Security Defaults won't replace your Azure AD licenses.

Your Azure AD licenses provide more security protection services than Security Defaults, which is essentially a security design approach for users on a free Azure AD tier.

If you're already using P1 or P2 licenses, you'd be better off using conditional access to perform tasks rather than relying on Security Defaults.