Security Defaults

Security defaults is a free, pre-configured security baseline available to every Microsoft Entra ID tenant. When enabled, it enforces MFA for all users, requires MFA for admin operations, blocks legacy authentication, and applies protections to privileged actions. Designed for tenants that haven't deployed Conditional Access — the customisable Entra ID P1 feature that replaces Security defaults. Security defaults are on by default for new tenants since 2019 and have raised the baseline meaningfully. Tenants outgrowing the all-or-nothing approach (need to exempt specific service accounts, need richer policies) move to Conditional Access; the two are mutually exclusive at any given time.

What "all or nothing" actually means

Security defaults is a single toggle with a fixed, non-configurable ruleset: every user must register for and use Microsoft Authenticator (or another supported method) for MFA, all users are challenged periodically, admins face MFA on every sign-in, legacy authentication protocols are blocked tenant-wide, and privileged actions like the Azure portal require re-authentication. There's no way to exempt one service account, adjust the challenge frequency, or scope the block to specific users — which is precisely the trade-off: it's a genuinely strong baseline that requires zero policy authoring, at the cost of zero flexibility. A tenant with even one legitimate reason to treat a specific account differently (a break-glass account, a legacy on-prem service account that can't do interactive MFA, a partner integration that needs SMTP AUTH) will find Security defaults either blocks that scenario or forces exempting it from MFA-and-legacy-auth entirely by way of workarounds Microsoft doesn't officially support.

Worked example

A five-person startup spins up a Microsoft 365 tenant with no dedicated IT admin. Security defaults is on from day one (the default for new tenants), so every user is already required to register MFA and legacy authentication protocols are already blocked — meaningful protection with literally no configuration. Eighteen months later, the company hires an IT consultant to set up a proper break-glass emergency-access account (which needs to be excluded from any MFA requirement, precisely because it's the fallback for when MFA itself is unavailable) and a finance system that only supports basic-auth SMTP for automated report emails. Neither scenario fits inside Security defaults' fixed rules, so the consultant's first move is licensing Entra ID P1 (included with Business Premium or E3) and replacing Security defaults with an equivalent — but now exception-capable — set of Conditional Access policies.

Migration path

Microsoft explicitly recommends against simply disabling Security defaults without a replacement — a tenant that turns it off and has no Conditional Access policies configured is left with no MFA enforcement at all. The supported path is: license Entra ID P1 (or move to a plan that includes it), author Conditional Access policies that at minimum replicate what Security defaults already provided (MFA for all users, block legacy auth), verify in report-only mode that the new policies actually cover every scenario Security defaults did, and only then disable Security defaults. The Entra admin center's Conditional Access section includes Microsoft-authored template policies specifically intended to ease this exact transition.

Common pitfall

The most common mistake is a tenant disabling Security defaults the moment it starts feeling restrictive, without first building the Conditional Access policies to replace it — leaving a gap with no MFA enforcement at all until someone circles back to finish the job, sometimes months later.