What are Microsoft 365 security defaults, and how do they enforce MFA?

If your Microsoft 365 tenant doesn't have Conditional Access, security defaults are the switch that decides whether stolen passwords work. They're free, they take a minute to turn on, and they break a few old devices that still sign in with a password alone. This guide explains what they enforce, how to check them, what to fix first, and when to replace them, based on Microsoft's documentation at the time of writing (November 2026).

What are security defaults in Microsoft 365?

Security defaults are a fixed set of identity protections in Microsoft Entra ID, the sign-in service behind Microsoft 365. Microsoft describes them as preconfigured settings that give "all organizations" a basic level of security "at no extra cost" (Microsoft Learn). When they're on, Microsoft enforces six controls:

1. Every user must register for multifactor authentication (MFA).
2. Administrators must complete MFA.
3. Users must complete MFA "when necessary," which Microsoft decides based on factors such as location, device, role and task.
4. Legacy authentication protocols are blocked.
5. Device code flow is blocked.
6. Privileged activity, such as access to the Azure portal, Microsoft Entra admin center, Azure PowerShell and Azure CLI, requires MFA.

You can't change any of these. Security defaults are either on or off for the whole tenant.

MFA means signing in with a second proof besides the password, such as a prompt in an authenticator app. Legacy authentication means sign-ins from clients that can't do MFA, for example "an Office 2010 client" or "any client that uses older mail protocols such as IMAP, SMTP, or POP3," in Microsoft's words.

Are security defaults already turned on in my tenant?

Possibly. Microsoft says tenants created on or after October 22, 2019 may have security defaults on, and they're now enabled on all new tenants at creation, with a 24-hour grace period before enforcement. Microsoft also periodically notifies older tenants that it will turn them on automatically if the tenant has no Conditional Access policies, no premium licenses and isn't actively using legacy authentication clients.

To check:

• Portal: in the Microsoft Entra admin center, go to Entra ID > Overview > Properties and select Manage security defaults. The panel shows Enabled or Disabled.

• Microsoft Graph PowerShell:

  Connect-MgGraph -Scopes "Policy.Read.All"
  Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Format-List DisplayName,IsEnabled
  

• Graph API: GET https://graph.microsoft.com/v1.0/policies/identitySecurityDefaultsEnforcementPolicy returns "isEnabled": true when they're on (Microsoft Graph).

Don't use the per-user MFA page to judge this. Microsoft notes that Disabled is the normal per-user status for people protected by security defaults or Conditional Access.

How do you turn on security defaults?

You need at least the Conditional Access Administrator role.

1. Sign in to the Microsoft Entra admin center.
2. Go to Entra ID > Overview > Properties.
3. Select Manage security defaults.
4. Set Security defaults to Enabled.
5. Select Save.

To script it, set isEnabled to true with Update-MgPolicyIdentitySecurityDefaultEnforcementPolicy -BodyParameter @{ isEnabled = $true } or a PATCH to the same Graph endpoint. That needs the Policy.Read.All and Policy.ReadWrite.ConditionalAccess permissions (Microsoft Graph).

Then revoke existing sessions. Microsoft says admins "should revoke all existing tokens to require all users to register for multifactor authentication," using Revoke-MgUserSignInSession. Without that step, people who are already signed in may not be asked to register for a while.

What happens to users when security defaults are on?

Users are asked to register the Microsoft Authenticator app with notifications the next time they sign in. Since July 29, 2024 there's no 14-day grace period to put it off. Users can also use codes from any authenticator app that supports OATH TOTP (time-based one-time passcodes). Sign-in prompts show a number the user must type into the app, which Microsoft says "helps prevent users from falling for MFA fatigue attacks."

Administrators have a stricter rule. After registration, the following roles must complete MFA "every time they sign in": Global, Application, Authentication, Authentication Policy, Billing, Cloud Application, Conditional Access, Exchange, Helpdesk, Identity Governance, Password, Privileged Authentication, Privileged Role, Security, SharePoint and User Administrator.

Guest users from other organizations are treated the same as your own users.

Send users to https://myprofile.microsoft.com and its Security Info link before you switch on, so registration isn't a surprise. Microsoft also publishes communication templates for this.

What breaks when you turn on security defaults?

Anything that signs in with only a username and password. Check these before you switch on:

Microsoft warns: "Before you enable security defaults, make sure your administrators aren't using older authentication protocols." One account type is excluded on purpose: Microsoft Entra Connect and Cloud Sync synchronization accounts (any principal with the Directory Synchronization Accounts role) aren't prompted for MFA.

Blocking device code flow is a security win. Attackers abuse it in device code phishing, and Microsoft says that starting July 1, 2026, all new Microsoft Entra tenants block it as part of security defaults.

Security defaults vs Conditional Access vs per-user MFA: which should you use?

Microsoft 365 has three ways to require MFA. This table combines Microsoft's Microsoft 365 MFA comparison and its security defaults guidance:

You can't run security defaults and Conditional Access together. Microsoft says that if one or more Conditional Access policies exist "in any state (Off, On, or Report only), you can't turn on security defaults," and organizations that move to Conditional Access "must disable security defaults." Per-user MFA, if someone turned it on years ago, overrides both and forces MFA at every sign-in for those users, so clean it up when you standardize.

The practical rule: on Microsoft 365 Business Basic or Business Standard without an Entra ID P1 add-on, use security defaults. On Business Premium, E3 or E5, use Conditional Access.

Can you exclude a break-glass account from security defaults?

No. Security defaults have no exclusions, so emergency access ("break-glass") accounts must do MFA too. Microsoft's mandatory MFA program goes the same way: break-glass accounts must sign in with MFA to the Azure portal, Microsoft Entra admin center and Intune admin center, and Microsoft suggests a passkey (FIDO2) or certificate-based authentication for them (Microsoft Learn).

That program also requires MFA for the Microsoft 365 admin center (enforcement began rolling out in February 2025) and, from October 1, 2025, for create, update and delete operations through Azure CLI, Azure PowerShell and other Azure management tools. Microsoft says there's no way to opt out, though tenants could postpone Phase 2 until July 1, 2026. Security defaults or Conditional Access make sure people have MFA registered before they hit those prompts.

Are security defaults enough to stop phishing?

They stop the most common takeover: a password stolen by phishing or reused from a breach, replayed from somewhere else. Microsoft says MFA "can block over 99.2% of identity-based attacks." CISA's position is that "any MFA is better than no MFA" (CISA).

They don't stop everything. Authenticator push notifications and codes can still be relayed by a proxy phishing site, an attack called adversary-in-the-middle phishing. The stronger answer is phishing-resistant MFA, such as passkeys or FIDO2 security keys, which you can only require with Conditional Access authentication strengths. Security defaults also don't stop a user from approving a malicious app; see OAuth consent phishing.

So treat security defaults as the floor. Keep filtering phishing before it reaches inboxes, and have a plan for the account that gets caught anyway: our compromised account remediation guide is that plan.

How do you move from security defaults to Conditional Access?

If you get Microsoft Entra ID P1, for example by moving to Microsoft 365 Business Premium:

1. Create emergency access accounts first. Microsoft recommends two cloud-only accounts with the Global Administrator role, reserved for emergencies.
2. Review Microsoft-managed Conditional Access policies. Microsoft provides managed policies that reproduce security defaults: block legacy authentication, require MFA for Azure management, require MFA for admins, and require MFA for all users.
3. Build or enable the policies in report-only mode and check the sign-in logs for users and apps that would fail.
4. Disable security defaults (Entra ID > Overview > Properties > Manage security defaults > Disabled (not recommended)), then turn the Conditional Access policies on straight away, so there's no gap.
5. Add stronger policies, such as phishing-resistant MFA for admins and finance staff.

Next steps

• Check the security defaults setting in your tenant today, and note whether Conditional Access policies exist.
• List every printer, app and mailbox that still uses SMTP AUTH, IMAP or POP3 before you switch on.
• Tell users when registration starts and how to reach https://myprofile.microsoft.com.
• Confirm your Microsoft 365 DNS records are in order with the free Microsoft 365 & Google Workspace DNS Setup Checker.
• MFA protects the sign-in; filtering reduces the phishing that targets it. See how iBlockSpam works with Microsoft 365.

Browse our other email setup guides.