Azure AD Security Defaults (Microsoft Entra): What They Turn On and When to Move On

Azure AD Security Defaults (Microsoft Entra): What They Turn On and When to Move On

Originally published 4 October 2020 · Reviewed 5 November 2026

Security defaults are Microsoft's one-switch baseline for identity protection in Microsoft Entra ID, formerly Azure Active Directory. They exist because most tenant compromises start with a password, and a small organisation with no security staff should not have to design policy from scratch to get basic protection. This article explains what they enforce, who should rely on them, and when to leave them.

What they enforce

Microsoft documents the following behaviours when security defaults are on:

• Everyone registers for multifactor authentication. Users are given a period, 14 days when this feature was introduced, to register the Microsoft Authenticator app. After that, they cannot sign in until they register.
• Administrators must use MFA. Users in the administrator roles that Microsoft lists are challenged at every sign-in. Microsoft started with nine roles and has extended the list over time, so read the current page for the roles in scope.
• Users are challenged when needed. Microsoft Entra ID decides when to ask for MFA from ordinary users based on factors such as location and device.
• Legacy authentication is blocked. Older protocols, such as basic authentication for IMAP, POP and SMTP, cannot perform MFA, so security defaults block them.
• Privileged activities are protected. Access to the Azure portal, command line and similar management endpoints requires MFA for all users, because those actions can change cloud resources.

Who they suit

Security defaults suit small organisations on the free tier that have no Conditional Access policies and want a safe baseline immediately. Microsoft enables them by default for tenants created after a certain date, so you may already have them on without realising it. They cost nothing and need no extra licence.

They are not ideal when you need exceptions, such as a scanner that still uses a legacy protocol or a break-glass account that must be excluded. Security defaults offer no exclusions, so each exception means moving to a more flexible control.

When to move to Conditional Access

Move to Conditional Access, which requires Microsoft Entra ID P1, when any of these applies:

• you need to exclude emergency access accounts or service accounts;
• you want to require compliant or hybrid-joined devices;
• you need location-based rules, or different rules for different groups;
• you want stronger methods than the Authenticator app for some users, such as phishing-resistant authentication strength;
• you want report-only testing, which security defaults do not provide.

Microsoft 365 Business Premium and E3 include P1, so many small businesses can move up without buying anything. Security defaults and Conditional Access cannot be used together. The usual path is to build and test Conditional Access policies in report-only mode, then switch security defaults off and enforce the policies in the same change window, so there is no gap.

How to check your tenant

1. In the Microsoft Entra admin center, open the tenant properties and look for the security defaults setting.
2. If it is on, note which administrators and users have registered MFA, and which have not.
3. If it is off, check whether Conditional Access policies exist that cover administrators, all users and legacy authentication. If neither security defaults nor policies exist, treat that as an urgent gap.
4. Keep at least two emergency access accounts and decide how they will be protected before you change anything.

Things that surprise people

• Registration lockouts. A user who ignores the registration prompt for the allowed period is locked out until they register. Tell people before it happens.
• Legacy devices and apps. Old multifunction printers and line-of-business apps that send mail with basic authentication stop working. Find them first with the sign-in logs.
• Shared accounts. Shared mailboxes and generic accounts that people sign in to directly break the model; use shared mailboxes properly instead.
• Admin prompts at every sign-in. This is intended, and it is a reason to use separate administrator accounts, not daily-use accounts, for privileged work.

A practical next step

If security defaults are on today, do three things this week. First, export or screenshot the list of users who have not registered for multifactor authentication and chase them, because they are the ones who will be locked out. Second, find any service that still uses a legacy protocol by reading the sign-in logs, and plan to replace it before it breaks. Third, decide whether the organisation has outgrown the baseline: if you already hold Business Premium or E3 licences, a small set of Conditional Access policies gives you the same protection plus exceptions you can control, and the move is mostly a matter of testing. Record the decision and the date, so the next administrator knows why the tenant is configured as it is.

Why the baseline matters

Microsoft's own guidance treats a baseline like this as the minimum for any tenant, because the cost of an attack on an unprotected administrator account is far higher than the cost of a registration prompt. A tenant with no multifactor authentication and legacy protocols enabled is exposed to password spray and credential replay, which are cheap for attackers to run at scale. Security defaults close those routes for the price of some user inconvenience, and they remain a sensible choice for a very small team until policy becomes worth the effort.

Microsoft references

• Security defaults in Microsoft Entra ID, reviewed 5 November 2026.
• Microsoft Entra licensing, reviewed 5 November 2026.

This article was first published on 4 October 2020. It was rewritten on 5 November 2026 with current product names. Microsoft's live documentation takes precedence if it has changed, including the roles in scope and the registration period.