Security defaults: what they protect, and when to move to Conditional Access
Security defaults give a tenant baseline protection in a single click. That is far better than nothing, but it is a rigid baseline. Sooner or later an exception is needed, and the temptation is to turn them off without putting anything in their place.
What security defaults enforce
Security defaults are a set of protections preconfigured by Microsoft, available with no extra licence. They are enabled on recent tenants; on older tenants, their state depends on history. Once enabled, they enforce in particular:
- MFA registration for every user, within a limited period after first sign-in, mainly with the Microsoft Authenticator app;
- MFA at every sign-in for holders of the main administrator roles;
- MFA when deemed necessary for other users, based on criteria set by Microsoft;
- blocking of legacy authentication;
- MFA for privileged activities, such as access to Azure management tools.
The exact details change over time; check Microsoft's documentation for the current list of roles and behaviours covered.
Where they fall short
The all-or-nothing nature of security defaults creates limits that are quickly reached:
| Need | Security defaults | Conditional Access |
|---|---|---|
| Exclude emergency accounts | Not possible | Possible, through targeted exclusion |
| Require a phishing-resistant method | No | Yes, through authentication strengths |
| Require a compliant device | No | Yes |
| Take sign-in risk into account | Not configurable | Yes, with Entra ID Protection |
| Treat guests or locations differently | No | Yes |
Security defaults and Conditional Access policies cannot coexist: the former must be turned off before the latter can be enabled.
When to replace them
For a small organisation without Entra ID P1, security defaults remain the best option available: do not turn them off without an alternative. Replacing them makes sense once the organisation has the licences needed for Conditional Access and needs finer control. Check the required licences in the current documentation.
The most common trap. We regularly come across tenants where security defaults were turned off to fix a one-off problem, with no Conditional Access policy in place. The tenant is left with no enforced MFA and legacy authentication wide open.
Making the switch safely
- Create two cloud-only emergency access accounts, excluded from policies and monitored.
- Build equivalent policies in report-only mode: MFA for everyone, a phishing-resistant method for administrators, legacy authentication blocked, Azure management protected.
- Analyse the impact in sign-in logs and Conditional Access workbooks.
- Switch in a single change window: turn off security defaults, then immediately enable the policies, leaving no unprotected gap.
- Verify with test sign-ins, including a non-admin account and a legacy client.
Also look at any Microsoft-managed policies that may appear in your tenant: they are a starting point, not a complete policy set.
What an audit checks
- The state of security defaults and whether active Conditional Access policies exist.
- That no period or population is left without enforced MFA.
- That legacy authentication is actually blocked.
- That emergency accounts exist and are correctly excluded.
- That the chosen protection mechanism matches the licences available.