Security Defaults vs Conditional Access: which should your tenant use?

Every Microsoft Entra ID tenant has to answer one question early: how is sign-in protected? Microsoft offers two answers. Security defaults are a fixed, preconfigured set of protections that any tenant can switch on at no cost. Conditional Access is a policy engine where you decide what's required, for whom and when.

They're mutually exclusive, and choosing the wrong one (or neither) is one of the most common findings in Microsoft 365 assessments.

What security defaults do

With security defaults turned on, Microsoft Entra ID enforces a small set of protections for the whole tenant:

• All users must register for MFA, with a grace period to complete registration, using the Microsoft Authenticator app.
• Administrators must use MFA, for the directory roles Microsoft defines as privileged.
• Users are challenged for MFA when necessary, based on signals Microsoft evaluates, rather than on every sign-in.
• Legacy authentication is blocked, so older protocols can't be used to bypass MFA.
• Privileged activities such as access to the Azure portal require MFA.

That's the whole feature. There are no settings, no exclusions and no reports specific to it. Microsoft's documentation lists exactly which roles and actions are covered; check it when you're deciding, because the details are updated from time to time.

What Conditional Access adds

Conditional Access evaluates each sign-in against your policies, using conditions such as:

• Who: users, groups, directory roles, guests, and workload identities.
• What: all resources, or specific apps such as Office 365 or the Microsoft admin portals.
• Where and how: device platform, named locations, client apps, authentication flows, and (with P2) user and sign-in risk.
• Which controls: block, require MFA or an authentication strength, require a compliant or hybrid-joined device, require an app protection policy, or apply session controls such as sign-in frequency.

Crucially, it supports exclusions. You can exempt emergency access accounts from policies that could lock everyone out, and a service account that can't do MFA can be handled deliberately rather than blocking a whole project.

Side-by-side comparison

Which should you choose?

Use security defaults if…

• The tenant has no Microsoft Entra ID P1 licenses (for example, Microsoft 365 Business Basic or Business Standard only).
• There's no one to design, test and maintain Conditional Access policies, and the organization's needs are simple.
• The alternative is nothing. A tenant with neither security defaults nor Conditional Access has no tenant-wide MFA enforcement at all.

Use Conditional Access if…

• The tenant has P1 through Microsoft 365 Business Premium, E3, E5 or standalone licenses. You're already paying for it.
• You need exclusions: emergency access accounts, a service account, or a phased rollout by group.
• You want device-based access (compliant devices only), phishing-resistant MFA for admins, or risk-based policies.
• You need evidence for auditors or insurers of exactly which controls apply to whom.

If you can't license P1 for everyone, one common approach is to license the people who need the extra control and keep the rest of the design simple; check Microsoft's licensing terms for Conditional Access before relying on partial licensing. See our Business Premium vs E3 vs E5 comparison for which plans include P1.

What about per-user MFA?

Per-user MFA is the older way of turning on MFA account by account. Microsoft recommends Conditional Access instead, and running per-user MFA alongside Conditional Access produces confusing prompts and makes troubleshooting harder. If a tenant still has users set to "Enforced" or "Enabled" in the per-user MFA page, include moving them to Conditional Access in your migration plan. Methods themselves are managed in the Authentication methods policy.

Migrating from security defaults to Conditional Access

The risk in this migration is a gap: a window where security defaults are off and your policies aren't enforcing yet. Avoid it like this:

1. Create emergency access accounts and a group to exclude them. See manage emergency access accounts.

2. Build the equivalent policies in report-only mode: require MFA for all users, require MFA (ideally phishing-resistant) for admin roles, block legacy authentication, and protect security-info registration. Our Conditional Access baseline has the details.

3. Check MFA registration. Security defaults already required registration, so coverage is usually good, but confirm in Authentication methods › User registration details.

4. Review report-only results for a few days of normal sign-ins. Look for service accounts, shared devices and legacy clients that would be affected.

5. Make the switch in one change window: turn security defaults off (Microsoft Entra admin center › Overview › Properties › Manage security defaults), then immediately set your baseline policies to On.

6. Watch sign-in logs for the rest of the day and the next morning, when most people sign in.

Microsoft-managed policies

Microsoft now creates some Microsoft-managed Conditional Access policies in eligible tenants, starting in report-only mode and enforced after a notice period. They're a helpful safety net, not a replacement for your own baseline. Review them, decide whether to keep them on, and document the decision.

Quick decision checklist

• Does the tenant have Microsoft Entra ID P1? If not, security defaults should be on.
• If it has P1, are Conditional Access policies enforcing MFA for all users and blocking legacy authentication?
• Is exactly one of the two in place, and not neither?
• Are emergency access accounts in place and excluded from the right policies?
• Is per-user MFA retired in favor of Conditional Access?

Common questions

Can we turn security defaults on for some users only?

No. Security defaults apply to the whole tenant, with no exclusions. If you need to treat groups differently, that's what Conditional Access is for.

Do Microsoft-managed policies replace security defaults?

No. They're a separate set of Conditional Access policies Microsoft creates in eligible tenants. They don't cover everything security defaults do, and they're not a substitute for your own baseline.

We turned on security defaults and a service stopped working. What now?

Usually a legacy client or a service account signing in with a password. Find it in the sign-in logs, then either fix the client (see blocking legacy authentication) or, if the tenant has P1, move to Conditional Access where you can make a documented exception. Turning security defaults off again leaves every user unprotected.

How M365Assessments helps

Every M365Assessments run records whether security defaults are on, lists the tenant's Conditional Access policies and their state, and compares that with the tenant's licensing. It flags the common gaps: security defaults on while P1 is licensed and unused, security defaults off with no Conditional Access policies, or policies left in report-only. See what we assess.