Dev.to Security 🔐 Cybersecurity 👁 0 📖 10 min read

Security Defaults vs Conditional Access: Which One Fits Your Small Business

Use security defaults if your Microsoft 365 tenant has no premium Microsoft Entra ID licenses and you want a sensible baseline with no configuration. Use Conditional Access if you have Microsoft Entra ID P1 or P2 (Micros

Use security defaults if your Microsoft 365 tenant has no premium Microsoft Entra ID licenses and you want a sensible baseline with no configuration. Use Conditional Access if you have Microsoft Entra ID P1 or P2 (Microsoft 365 Business Premium includes Conditional Access features) and you need exceptions, device rules or location rules. The two cannot be combined, so the real decision is when to move from the first to the second.

Who this is for and what you will have at the end

This guide is for owners and IT generalists of small organizations that run Microsoft 365 and manage sign-in security themselves. You do not need prior Conditional Access experience.

By the end you will know what security defaults actually enforce, what Conditional Access adds, how to see which one your tenant is using today, and how to switch from security defaults to Conditional Access without locking yourself out. Everything here is based on Microsoft Learn documentation, last checked on 2026-11-03.

What security defaults enforce

Security defaults are a bundle of preconfigured settings that Microsoft makes available to every organization at no extra cost. Per Microsoft Learn, they include:

  • Requiring all users to register for multifactor authentication (MFA).
  • Requiring administrators to do MFA.
  • Requiring users to do MFA when necessary.
  • Blocking legacy authentication protocols.
  • Blocking device code flow.
  • Protecting privileged activities such as access to the Azure portal.

MFA for all users

Users are asked to register for MFA at sign-in. When they are prompted, they see a screen with a number to enter in the Microsoft Authenticator app, which helps prevent MFA fatigue attacks. Microsoft decides when a user is prompted again, based on factors such as location, device, role and task. Since July 29, 2024, the 14-day registration grace period has been removed for new and existing tenants.

Registration must use the Microsoft Authenticator app with notifications. Users can also use verification codes from the app, and any non-Microsoft app that generates OATH TOTP codes.

MFA for administrators

After registration, these roles must do MFA every time they sign in: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator and User Administrator. The Microsoft Learn page also lists Authentication Policy Administrator and Identity Governance Administrator separately.

Legacy authentication and device code flow

Legacy authentication means older clients that do not use modern authentication (for example Office 2010) and older mail protocols such as IMAP, SMTP and POP3. These protocols cannot do MFA, so an attacker can use them to get around an MFA requirement. Once security defaults are on, requests using these protocols are blocked, including Exchange ActiveSync basic authentication. For a deeper walk-through of finding what still uses them, read /blog/block-legacy-authentication-microsoft-365.

Device code flow lets people sign in on devices with limited input, such as a device without a browser or keyboard. Attackers abuse it in phishing, so security defaults block it. Microsoft notes that starting July 1, 2026, all new Microsoft Entra tenants block device code flow as part of security defaults. Anything that relies on it, such as some shared devices, will fail to sign in.

Azure management

Anyone using the Azure portal, the Microsoft Entra admin center, Azure PowerShell or Azure CLI must complete MFA, whether or not they are an administrator. The Microsoft Entra Connect and Cloud Sync synchronization accounts are excluded.

What Conditional Access adds

Conditional Access is Microsoft's policy engine. A policy is an if-then statement: if a user wants to reach a resource, then they must complete an action. It evaluates signals and then makes a decision.

Signals you can use Decisions you can make
User, group or agent Block access
IP location, including whole countries or regions Require multifactor authentication
Device platform or state, with device filters Require authentication strength
Application Require a compliant or hybrid joined device
Sign-in and user risk (from ID Protection) Require an approved client app or app protection policy
Defender for Cloud Apps session signals Require a password change or terms of use

Microsoft notes that Conditional Access policies are enforced after first-factor authentication is completed and are not meant as a frontline defense against denial-of-service attacks.

Side-by-side comparison

Security defaults Conditional Access
Required license None At least Microsoft Entra ID P1; Microsoft 365 Business Premium also includes the features
Customization On or off only Fully customizable
Exclusions Not offered; on or off for the whole tenant Exclude users, groups and more
Report-only state Not applicable Yes
Risk-based policies No Yes, with Entra ID P2 (ID Protection)
Who turns it on Microsoft or an administrator Microsoft or an administrator

Microsoft's own guidance: if you have Microsoft Entra ID P1 or P2 licenses, security defaults are probably not right for you, and organizations with complex requirements should consider Conditional Access. A note on licensing: the Conditional Access overview page names Entra ID P1 as the requirement, while the page on Microsoft-managed policies lists P2 or Business Premium as a prerequisite for those managed policies. Check the policies you plan to use against your license before you rely on them.

Which should you use?

Use this as a starting point:

  • No premium licenses, simple needs: keep security defaults on. They protect against the most common identity attacks and need no maintenance.
  • Microsoft 365 Business Premium or Entra ID P1: move to Conditional Access. You already pay for it, and it lets you exclude service accounts, require compliant devices or block countries you never do business with.
  • Need an exception security defaults cannot give: for example a scanner or line-of-business app that still uses legacy authentication, or a Teams Room device that needs device code flow. Those are Conditional Access jobs.
  • Need risk-based sign-in rules: that requires Entra ID P2 and Conditional Access.

If you are unsure what you own, see /blog/business-premium-vs-e3-vs-e5.

Prerequisites

  • An account with at least the Conditional Access Administrator role.
  • Two emergency access (break-glass) accounts. Microsoft recommends two cloud-only accounts permanently assigned Global Administrator and not tied to a person. Follow /blog/conditional-access-break-glass-accounts.
  • A list of anything that signs in without a person: scanners, apps that send mail, shared devices.
  • A way to tell users what is changing. Microsoft provides communication templates at aka.ms/mfatemplates and tells users to register at https://myprofile.microsoft.com through the Security Info link.

Step 1: Check what your tenant uses today

Sign in to the Microsoft Entra admin center at https://entra.microsoft.com as at least a Conditional Access Administrator.

Check security defaults

  1. Browse to Entra ID > Overview > Properties.
  2. Select Manage security defaults.
  3. Read the Security defaults toggle. It shows Enabled or Disabled.

If your tenant was created on or after October 22, 2019, security defaults might already be enabled. On new tenants there is a 24-hour grace period before protections are enforced. Microsoft also notifies customers before automatically enabling security defaults if they have no Conditional Access policies, no premium licenses and no active legacy authentication clients.

Check Conditional Access

  1. Browse to Entra ID > Conditional Access.
  2. Open Policies. The list includes report-only policies. A policy with Microsoft in the Created by column is a Microsoft-managed policy.

If security defaults are enabled, the managed MFA policies that require P1 or P2 apply only where security defaults are not enabled, so you may not see them yet.

Step 2: Enable security defaults (if that is your choice)

  1. In the Microsoft Entra admin center, browse to Entra ID > Overview > Properties.
  2. Select Manage security defaults.
  3. Set Security defaults to Enabled.
  4. Select Save.

Before you do, make sure none of your administrators uses legacy authentication, and leave all Methods available to users enabled in the MFA service settings. Microsoft warns that disabling methods while using security defaults might lock you out of your tenant.

Microsoft also advises revoking active tokens when you enable security defaults so existing sessions are forced to register for MFA. You can do this with the Microsoft Graph PowerShell SDK:

Connect-MgGraph
Revoke-MgUserSignInSession -UserId "[email protected]"

Sign in to Microsoft Graph PowerShell with an account that is allowed to do this, and run the cmdlet for each user you want to force back through sign-in. Ask all administrators to sign in right after, so they can register their authentication methods.

Step 3: Move from security defaults to Conditional Access

Do this in a quiet period, with a second admin session already signed in.

Prepare

  1. Confirm your two break-glass accounts exist and have been tested.
  2. Decide which protections you need to keep. Microsoft provides four managed policies for the upgrade: Block legacy authentication, Require multifactor authentication for Azure management, Require multifactor authentication for admins, and Require multifactor authentication for all users.
  3. Warn users that MFA prompts will continue.

Disable security defaults

  1. Browse to Entra ID > Overview > Properties > Manage security defaults.
  2. Set Security defaults to Disabled (not recommended).
  3. Select Save.

Microsoft says that after you disable security defaults you should immediately enable Conditional Access policies. Every minute in between is unprotected, so have the policies ready before you click Save.

Turn on replacement policies

Microsoft-managed policies are created in your tenant in Report-only state. Microsoft enables a managed policy no less than 30 days after it is introduced if it is left in report-only, and notifies you by email and Message center 2 weeks before. In some cases it can be faster, and the policy details say so. You can turn a managed policy on sooner, or opt out by setting it to Off. You can edit the state and the excluded identities, but you cannot rename or delete managed policies.

  1. Browse to Entra ID > Conditional Access > Policies.
  2. Open each policy whose Created by is Microsoft.
  3. Under Excluded identities, add your break-glass accounts.
  4. Review the Policy impact tab, even for report-only policies.
  5. Set the state to On when the impact looks right.

If you need changes beyond exclusions and state, use Duplicate to make an editable copy. Do not lower your security posture with those changes.

For policies you create yourself, test first in report-only mode, as described in /blog/conditional-access-report-only-mode-test-policies.

Step 4: Verify it works

  1. Sign in with a test user in a private browser window and confirm the MFA prompt appears.
  2. In the Microsoft Entra admin center, browse to Entra ID > Monitoring & health > Sign-in logs.
  3. Filter by Username and Conditional Access, select a sign-in, then select the Conditional Access tab to see which policies applied and the result.
  4. For policy changes, browse to Entra ID > Monitoring & health > Audit logs and set Service to Conditional Access. Microsoft-managed policy names start with Microsoft-managed:.

You need at least the Reports Reader role to read these logs.

Troubleshooting

Users locked in a sign-in loop on older Exchange Online tenants

Microsoft notes that Exchange Online tenants created before 2017 have modern authentication disabled by default, which can cause a login loop under security defaults. Enable modern authentication in Exchange Online.

A shared device or Teams Room device can no longer sign in

Device code flow is blocked by security defaults and by the Block device code flow managed policy. For Teams devices, Microsoft publishes guidance on restricting device code flow with Conditional Access so you can scope exceptions while still blocking it for other accounts.

A scanner or app that sends email stopped working

Legacy authentication is blocked. Microsoft links a guide on setting up a multifunction device or application to send email using Microsoft 365. Fix the device rather than reopening legacy authentication for everyone.

"Failed to update" when editing a managed per-user MFA policy

Microsoft says using the Edit pencil at the top of the Microsoft-managed per-user MFA policy might result in a failed to update error. Select Edit under Excluded identities instead.

An admin is locked out

Use a break-glass account, which should be excluded from the policies, to sign in and fix or turn off the offending policy. This is why those accounts come first.

Policies stopped being editable after a license lapse

When the licenses for Conditional Access expire, Microsoft says policies are not automatically disabled or deleted, but you can only view and delete them, not update them.

Checklist

  • Know whether security defaults, Conditional Access or neither is active.
  • Have two tested break-glass accounts excluded from every policy.
  • Inventory legacy authentication and device code flow users.
  • Tell users to register at https://myprofile.microsoft.com.
  • If switching, have replacement policies ready before disabling security defaults.
  • Review the Policy impact tab before moving a policy to On.
  • Check sign-in logs after the change.

References

This guide was researched and drafted with AI assistance and checked against the vendor documentation listed in its References. Read the maintained version and related guides on EpiFive.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.