Security defaults give every Microsoft Entra tenant baseline MFA and legacy authentication blocking at no cost, but they are all or nothing, and the moment a tenant needs one exception, one stronger rule or one non-human identity handled properly, they become the thing standing in the way. The two cannot run together: Microsoft states that organisations implementing Conditional Access policies that replace security defaults must disable security defaults. This guide covers the decision and the cutover: what security defaults enforce and cannot exclude, the licence trigger, how to move without a gap, and how to handle break-glass accounts, sync accounts, service accounts and workload identities on the way. It is for Entra administrators and identity architects in small and mid-sized tenants. Product details are from Microsoft Learn as checked in November 2026.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- The licence is the usual trigger. Security defaults need no licence; Conditional Access needs at least Microsoft Entra ID P1 (included in Microsoft 365 Business Premium), and Microsoft says that with P1 or P2 security defaults are "probably not right for you".
- Security defaults have no per-account exceptions. The only documented exclusion is the directory synchronisation account; anything else that cannot do MFA either breaks or forces you to Conditional Access.
- Cut over in one change window. Build the replacement policies in report-only, check the sign-in logs, then disable security defaults and enable the policies immediately so the tenant is never unprotected.
- Break-glass accounts change status. Under security defaults they get MFA like any Global Administrator; under Conditional Access you exclude them from blocking policies and give them phishing-resistant credentials, because Azure mandatory MFA still applies.
- Service accounts need a real fix, not an exclusion. User accounts running automation should become managed identities or service principals, which you then govern with Conditional Access for workload identities where licensed.
The short answer
Keep security defaults if the tenant is on the free tier, has no premium licences, has no legacy clients and has no account that genuinely cannot do MFA. It is a sound baseline and far better than nothing. Move to Conditional Access as soon as any of these is true: you hold Entra ID P1 or P2 (directly or through Business Premium or an E3/E5 suite), you need a single exception, you want phishing-resistant MFA for admins, device compliance, location rules or risk-based policies, or you need to control service principals. When you move, replicate every protection security defaults gave you first, then add the rest.
For full policy design see the Conditional Access Guide. Tenants still using per-user MFA should also read Entra Per-User MFA to Conditional Access.
What security defaults actually enforce
| Protection | Security defaults behaviour | What you cannot change |
|---|---|---|
| MFA registration | All users must register; Microsoft removed the 14-day registration grace period from 29 July 2024 | Registration timing and allowed methods (Microsoft warns that disabling methods can lock you out) |
| MFA for administrators | MFA at every sign-in for a fixed list of roles including Global, Privileged Role, Security, Exchange, SharePoint, User, Helpdesk and Conditional Access Administrator | The role list, the method strength |
| MFA for users | "Microsoft decides when a user is prompted" based on location, device, role and task | When prompts happen; you cannot require MFA for a specific app |
| Legacy authentication | All requests using older protocols blocked, including Exchange ActiveSync basic authentication | No exception for a legacy device or app |
| Device code flow | Blocked when security defaults are on; Microsoft states all new tenants block it from 1 July 2026 | No exception for meeting room or shared devices |
| Azure management | MFA for Azure portal, Entra admin centre, Azure PowerShell and Azure CLI | Microsoft notes this does not include Entra ID or Microsoft Graph |
| Guests | B2B guest and direct connect users are treated the same as your own users | No separate guest policy |
Security defaults have been rolled out to tenants created on or after 22 October 2019, with a 24-hour grace period before enforcement, and Microsoft periodically notifies tenants for automatic enablement if they have no Conditional Access policies, no premium licences and no active legacy authentication clients.
What security defaults cannot do
- Exclude anyone: Microsoft's guidance is that "if your organization needs granular control and exceptions, you should consider Conditional Access." The directory synchronisation account (any principal with the Directory Synchronization Accounts role) is the only built-in exclusion.
- Choose method strength: no way to require phishing-resistant MFA (passkeys, Windows Hello for Business, certificate-based authentication) for admins.
- Use device state: no requirement for compliant or hybrid joined devices.
- Use location or risk: no named locations, no country blocks, no sign-in or user risk policies.
- Control sessions: no sign-in frequency, persistent browser or app-enforced restrictions.
- Govern non-human identities: nothing for service principals. Security defaults act on user sign-ins only.
- Stage changes: it is on or off for the whole tenant; there is no report-only mode or pilot group.
Licence tiers and the trigger point
| Capability | Licence stated by Microsoft | Notes |
|---|---|---|
| Security defaults | None | Available to all tenants |
| Conditional Access (user policies) | Microsoft Entra ID P1; Microsoft 365 Business Premium customers can also use it | If licences expire, policies stay in place and can be viewed or deleted but not updated |
| Risk-based policies (sign-in risk, user risk) | Microsoft Entra ID P2 (ID Protection) | See Microsoft Entra ID Protection |
| Conditional Access for workload identities | Workload Identities Premium | Without it, existing workload identity policies keep working but cannot be modified |
| Microsoft-managed policies | Deployed to eligible tenants by licence; several apply only where security defaults are off | Created in report-only and enabled no less than 30 days later unless you act |
The trigger: once a tenant holds P1, keeping security defaults means paying for controls you cannot use. A common pattern is a small business that buys Business Premium for Intune and Defender but never turns security defaults off, so device compliance and admin phishing resistance are never enforced. See the Microsoft 365 Business Premium security guide.
Threat model: staying on security defaults
Security defaults block the bulk of commodity attacks. Microsoft's own analysis, quoted in its legacy authentication guidance, is that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication. Blocking legacy protocols and requiring MFA stops most of T1110.003 Password Spraying against Entra.
What remains:
- Adversary-in-the-middle phishing: push and OTP MFA can be relayed. Security defaults cannot require phishing-resistant methods, even for Global Administrators.
- Token theft from unmanaged devices: without device conditions, a session from any device is accepted after MFA.
- Accounts that cannot do MFA: a shared mailbox account used by a scanner, a script running as a user. Under security defaults these break, so administrators are tempted to turn defaults off entirely and leave nothing in their place, which is worse than either option.
- Unattended test or secondary tenants: security defaults are per tenant. In the Microsoft Midnight Blizzard Breach, a password spray succeeded against a legacy, non-production test tenant account that did not have MFA. Every tenant you own needs a baseline, whichever model it uses.
Threat model: running Conditional Access
Conditional Access closes those gaps but introduces its own risk: a policy set that looks strong but has holes. Conditional Access is evaluated after first-factor authentication, and only for what is in scope.
- Exclusion sprawl: every exclusion group becomes a bypass. Excluded accounts are a favourite target. See How to Find Accounts Excluded From MFA and Conditional Access.
- Coverage gaps: policies scoped to selected apps rather than all resources, missing the non-interactive sign-in flows, or forgetting guests.
- Lost legacy blocking: security defaults blocked legacy authentication automatically; Conditional Access only does so if you build the policy.
- Lockout: a misconfigured block policy with no emergency exclusion can lock out every administrator.
- Service principals out of scope: Microsoft states that calls made by service principals are not blocked by Conditional Access policies scoped to users.
Side-by-side comparison
| Dimension | Security defaults | Conditional Access |
|---|---|---|
| Cost | Free | Entra ID P1 or above |
| Configuration effort | One toggle | Policy design, testing and ongoing review |
| Exceptions | Sync account only | Any user, group, role, app or location, by design |
| MFA strength | Microsoft-chosen methods | Authentication strengths, including phishing-resistant only |
| Device and location conditions | None | Compliant device, hybrid join, device filters, named locations |
| Risk response | None | Sign-in and user risk with P2 |
| Workload identities | None | Location and risk blocks for single-tenant service principals with Workload Identities Premium |
| Testing | None: on or off | Report-only mode, pilot groups, What If tool |
| Failure mode | Breaks accounts that cannot do MFA | Silent gaps from exclusions or scope mistakes |
Break-glass, sync and service account handling
| Account type | Under security defaults | Under Conditional Access |
|---|---|---|
| Emergency access (break-glass) | Treated as Global Administrators: MFA at every sign-in, no exclusion possible | Two or more cloud-only *.onmicrosoft.com accounts, excluded from policies that block or restrict sign-in via a dedicated group, using passkeys (FIDO2) or certificate-based authentication |
| Entra Connect or Cloud Sync account | Excluded automatically | Exclude from MFA policies; restrict by location where supported; never use it for anything else |
| User account running scripts | Breaks when MFA is required | Do not exclude permanently: migrate to a managed identity or service principal |
| Service principal (single tenant) | Not in scope | Conditional Access for workload identities: block outside named locations or on service principal risk; assign the principal directly, because group assignment is not enforced |
| Managed identity | Not in scope | Not covered by Conditional Access; Microsoft suggests access reviews instead |
| Multi-tenant and third-party SaaS apps | Not in scope | Not covered by workload identity policies; govern through consent and app permission review |
Azure mandatory MFA matters here. Microsoft enforces it in two phases: from October 2024 for sign-in to the Azure portal, Microsoft Entra admin centre and Microsoft Intune admin centre, and from 1 October 2025, gradually, for create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure as code tools and REST API endpoints. Microsoft states that break-glass accounts must sign in with MFA once enforcement begins and recommends passkeys (FIDO2) or certificate-based authentication for them, and that user identities used as service accounts for Azure automation also need MFA, while managed identities and service principals are not affected. So excluding a break-glass account from Conditional Access does not remove the need for a phishing-resistant credential. Microsoft also recommends alerting on every emergency account sign-in and validating the accounts at least every 90 days. See the Break-Glass Account Guide and Conditional Access for Workload Identities.
Where identity fits
The migration is often the first time a small tenant discovers its non-human identities: the user account a copier uses to send email, the "svc-backup" account with a password in a script, the app registration with a client secret nobody owns. Security defaults hid these by breaking or ignoring them. Inventory them before cutover, give each an owner, and move automation onto workload identities with certificates or federated credentials rather than secrets. See Machine Identity vs Workload Identity vs NHI.
Migration sequence
- Inventory: list licences, admins, guests, and accounts that sign in non-interactively. In Sign-in logs add the Client App column and filter for legacy protocols on both interactive and non-interactive tabs, or use the legacy authentication workbook.
- Fix or replace non-MFA accounts: move scripts to managed identities or service principals; retire legacy clients. See the Legacy Authentication and ROPC Retirement Guide, noting that ROPC flows fail once MFA applies.
- Prepare emergency access: create or verify two cloud-only break-glass accounts with passkeys or certificates, put them in an exclusion group, and set an alert on any sign-in.
- Build the four replacement policies in report-only: Microsoft's "upgrade from security defaults" set is Block legacy authentication, Require MFA for Azure management, Require MFA for admins and Require MFA for all users. Scope to all users and all resources, excluding only the emergency group (and the sync account where needed). For legacy blocking, set Client apps to Exchange ActiveSync clients and Other clients, grant Block access.
- Review report-only results: check which sign-ins would be blocked or challenged; fix each before going live. Report-only policies do not need emergency exclusions, but enforced ones do.
- Cut over in one window: disable security defaults (Entra ID, Overview, Properties, Manage security defaults) and switch the four policies to On immediately afterwards. Have the break-glass credential to hand.
- Verify: sign in as a test admin, a test user and a guest; confirm results in sign-in logs under the Conditional Access tab.
- Strengthen: add authentication strength for admins (phishing-resistant), device compliance, guest policies, risk policies with P2, and workload identity policies where licensed. Decide on each Microsoft-managed policy rather than letting it enable by default.
Rollback: if the new policies cause an outage you cannot fix quickly, switch the failing policy to report-only and use break-glass access to repair. Re-enabling security defaults is possible only after turning off or deleting the Conditional Access policies, so treat it as a last resort and record it as an incident.
Worked scenario
A 120-person professional services firm buys Microsoft 365 Business Premium. Security defaults are on. The office scanner sends email through a licensed user account with basic SMTP authentication, a finance script exports data nightly as a user, and two administrators use push notifications.
- Week 1: sign-in logs show the scanner on a legacy protocol and the script on a non-interactive sign-in. The scanner is moved to a supported relay method; the script is rewritten to use a service principal with a certificate, owned by the finance systems lead.
- Week 2: two break-glass accounts are created with FIDO2 keys stored in separate safes, with an alert on any sign-in. The four replacement policies go into report-only.
- Week 3: report-only shows no unexpected blocks. In an evening window security defaults are disabled and the policies enabled. A policy requiring phishing-resistant authentication strength for admin roles follows a week later, after both admins enrol passkeys.
- Result: the firm has the same baseline as before, no permanent user exclusions apart from break-glass, and a path to device compliance through Intune.
Detection and measurement
Stream Entra sign-in and audit logs to your SIEM or Azure Monitor. Alert on any break-glass sign-in, on changes to Conditional Access policies or named locations, on security defaults being toggled, and on new exclusions.
- Legacy authentication sign-ins: target zero successful sign-ins after cutover.
- Policy coverage: share of interactive sign-ins where at least one MFA policy applied; investigate any "not applied" result for a user.
- Excluded identities: count of accounts excluded from MFA policies, each with an owner and expiry; target only break-glass and sync.
- Phishing-resistant admin coverage: share of privileged role holders signing in with a phishing-resistant method.
- User accounts used for automation: count trending to zero as they move to workload identities.
- Break-glass test age: days since last validated sign-in, under 90.
Framework mapping
| Framework | Reference | How this decision maps |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2) | MFA for privileged and non-privileged accounts: both models; Conditional Access adds method strength |
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement | Conditional Access policies as the enforcement point |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Blocking legacy protocols and device code flow |
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Break-glass, sync and service account governance |
| NIST CSF 2.0 | PR.AA-03, PR.AA-05 | Authentication of users and services; access enforced by policy |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control; 8.5 Secure authentication | Policy-based access rules and authentication strength |
| MITRE ATT&CK v20 | T1110.003 Password Spraying; T1078.004 Cloud Accounts | Threats both models address; exclusions reopen them |
Common failure patterns
- Turning security defaults off with nothing ready: a broken scanner prompts an administrator to disable defaults, and the tenant runs with no MFA for months.
- Forgetting legacy blocking: the new policy set requires MFA but omits the legacy authentication block that defaults gave for free, reopening password spray.
- Permanent exclusions for "service accounts": user accounts excluded from MFA forever instead of migrated to workload identities.
- Break-glass accounts with weak or expired credentials: excluded from Conditional Access but protected only by a password, or with a FIDO2 key nobody has tested, which also fails Azure mandatory MFA.
- Ignoring other tenants: test, development or acquired tenants left with neither defaults nor policies, the pattern seen in the Midnight Blizzard breach.
- Letting managed policies decide: Microsoft-managed policies enable after the report-only period without anyone checking their exclusions.
Practitioner checklist
- Confirm licences: if any user holds Entra ID P1 or above, plan the move to Conditional Access.
- Query sign-in logs for legacy protocols and non-interactive user sign-ins before changing anything.
- Migrate user accounts that run automation to managed identities or service principals.
- Create two cloud-only break-glass accounts with phishing-resistant credentials and an alert on every sign-in.
- Build the four replacement policies in report-only, scoped to all users and all resources.
- Disable security defaults and enable the policies in the same change window.
- Require phishing-resistant authentication strength for admin roles once enrolled.
- Assign service principals directly to workload identity policies, not through groups.
- Review every exclusion quarterly and validate break-glass accounts at least every 90 days.
- Apply a baseline to every tenant you own, including test and development tenants.
Standards and references
- Microsoft Learn: Security defaults in Microsoft Entra ID
- Microsoft Learn: What is Conditional Access?
- Microsoft Learn: Microsoft-managed Conditional Access policies
- Microsoft Learn: Block legacy authentication with Conditional Access
- Microsoft Learn: Manage emergency access admin accounts
- Microsoft Learn: Conditional Access for workload identities
- Microsoft Learn: Mandatory multifactor authentication for Azure
- MITRE ATT&CK: T1110.003 Password Spraying
Related NHI Mgmt Group resources: Conditional Access Guide · Entra Per-User MFA to Conditional Access · Break-Glass Account Guide · Conditional Access for Workload Identities