Why I replace Security Defaults with Conditional Access in Microsoft 365

Security Defaults are useful when you first set up a Microsoft 365 tenant. They raise your posture quickly and easily, which is a good thing.

As the tenant grows, it’s not flexible enough.

This is usually the point where I recommend organisations move to Conditional Access. Not because Security Defaults is bad, but because it’s very limited once you need proper control.

Security Defaults: great starting point, limited control

Security Defaults help with basics like:

Requiring MFA for users
Helping block legacy authentication
Giving a simple security baseline with very low setup effort

For the majority of small tenants, that is still a great setup. However, you can and should do much more.

You might think one toggle for “super security” is a great idea, but the biggest trade-off is control. You do not get any flexibility in how access is handled across different users, apps, devices, or locations.

Why move to Conditional Access

Conditional Access lets you move from one broad rule for all to access rules based on your environment.

You can apply policy by:

User or group
App
Device state
Location
Client type

Real benefits you get straight away

1) Better protection for privileged accounts

Admin accounts are your highest-impact accounts. With Conditional Access, you can protect those accounts differently from standard users.

Example controls:

Require stronger authentication for admin roles
Restrict admin access to compliant/managed devices
Limit admin sign-ins from untrusted locations

In a later blog post, we will focus purely on securing admin accounts.

2) Better user experience for everyone else

Not every user needs the same level of pain every day. Conditional Access allows us to be flexible and adjust our policy to suit our organisation’s needs, which typically leads to:

Less MFA fatigue
Fewer support calls
Fewer blanket controls that annoy everyone

3) Cleaner control over who can access what (and from where)

This is the biggest win for me.

You can control access by:

User/group (not everyone gets identical policy)
App (target core M365 apps first)
Device (managed vs unmanaged)
Location (trusted vs untrusted)
Client type (block weak/legacy methods)

This gives you real-life guardrails instead of one broad default that doesn’t work.

How to migrate from Security Defaults to Conditional Access

Important: You need Microsoft Entra ID P1 (or higher) licensing to use Conditional Access.

If your tenant has Security Defaults enabled, you can use the guided Microsoft flow to migrate quickly as documented below.

Before you start

Confirm you can sign in to https://entra.microsoft.com/
Confirm at least one emergency/break-glass account exists
Make sure your team knows a policy change is being made

Phase 1: Open Security Defaults settings

Step 1. In Entra, go to Overview → Properties.

Step 2. Scroll to Security defaults and select Manage security defaults.

Phase 2: Disable Security Defaults

Step 3. Set Security defaults to Disabled.

Step 4. Select both options:

My organization is planning to use Conditional Access
Replace security defaults by enabling Conditional Access policies

Step 5. Confirm the prompt by selecting Disable.

Step 6. Wait a few minutes while Microsoft provisions the replacement Conditional Access policies.

Phase 3: Verify policy creation

Step 7. Go to Conditional Access → Policies.

Step 8. Confirm the replacement policies are present and enabled.

Roll Back

If you need to roll back:

Set each Conditional Access policy to Report-only.
Return to Security defaults settings.
Set Security defaults back to Enabled.

Final thought

Security Defaults are a strong first step. Conditional Access is how you scale with a greater level of control. The Security Defaults disablement flow creates what Security Defaults previously covered, so you’ll be in no worse position.

Look out for our next post where we focus on securing admin accounts. We will jump into building admin-based CA policies.