Wesley Swann November 4, 2026 0 Comments

Microsoft 365 security defaults are one of the best things Microsoft has done for small businesses. One switch turns on MFA for everyone, blocks old sign-in protocols, and protects admin activity. For a ten-person office, that is often enough. But somewhere around 25 users, most businesses start needing things security defaults simply cannot do.

This article explains what security defaults actually enforce, the specific moments where they stop fitting, and how to move to Conditional Access without locking anyone out.

What security defaults do

Security defaults are a free, preconfigured set of identity protections in Microsoft Entra ID (formerly Azure AD). They are either on or off. There is nothing to tune. When they are on, Microsoft enforces the following:

  • All users must register for multifactor authentication, using the Microsoft Authenticator app or another authenticator app that generates codes.
  • Users with privileged admin roles, such as Global Administrator, Exchange Administrator, and Security Administrator, must complete MFA every time they sign in.
  • Other users are prompted for MFA when Microsoft decides it is necessary, based on signals such as location, device, and role.
  • Legacy authentication protocols (older POP, IMAP, and SMTP sign-ins that cannot do MFA) are blocked.
  • Device code flow sign-ins are blocked.
  • Anyone accessing Azure management tools, such as the Azure portal, Azure PowerShell, and Azure CLI, must complete MFA.

That is a strong baseline. If your tenant has nothing else, turning security defaults on is the right first move. You can check the setting in the Microsoft Entra admin center at Entra ID > Overview > Properties > Manage security defaults.

Why 25 users is the tipping point

There is nothing magic about the number 25. It is roughly where I see the same set of needs show up in almost every growing business. Once you have a few departments, a couple of shared devices, and at least one line-of-business app, the all-or-nothing design of security defaults starts to cause friction.

You need exceptions, and security defaults do not allow any

A scanner that emails documents using SMTP. A conference room device. A service account for a payroll integration. With security defaults, you cannot exclude these. The usual result is that someone turns security defaults off to make one device work, and the whole tenant loses its protection.

You cannot control when MFA is required

Security defaults let Microsoft decide when to prompt regular users. For a firm handling client financial or health data, “when Microsoft thinks it is necessary” is hard to explain to an auditor or cyber insurer. Conditional Access lets you require MFA on every sign-in, or on every sign-in from outside a trusted location.

You cannot require a compliant device

Once you roll out Intune, you will want a rule that says “only company-managed, healthy devices can open company data.” Security defaults have no way to express that. Conditional Access can.

You cannot block risky countries or risky sign-ins

If your staff all work in one or two countries, blocking sign-ins from elsewhere removes a lot of noise. Security defaults cannot do location rules. Risk-based policies, which use Microsoft Entra ID Protection, need Entra ID P2.

You need stronger MFA for admins

Phishing-resistant methods, like passkeys and FIDO2 security keys, are the right standard for admin accounts. Requiring a specific authentication strength is a Conditional Access feature.

Security defaults vs Conditional Access

Capability Security defaults Conditional Access
License needed None (free) Microsoft Entra ID P1 (included in Business Premium, E3, E5)
MFA for all users Yes, when Microsoft decides Yes, on your terms
Block legacy authentication Yes Yes
Exclusions for service accounts or devices No Yes
Require a compliant or managed device No Yes (with Intune)
Location-based rules No Yes
Phishing-resistant MFA for admins No Yes, using authentication strengths
Sign-in and user risk policies No Yes, with Entra ID P2

One important rule: security defaults and Conditional Access are not meant to run together. You cannot enable security defaults while Conditional Access policies exist, so the move is a switch, not a layer.

How to move off security defaults safely

The risk in this change is a gap: security defaults go off, and for an hour or a day nothing is protecting sign-ins. Plan it so that never happens.

  1. Confirm licensing. Every user covered by Conditional Access needs Entra ID P1. Business Premium includes it.
  2. Create two emergency access accounts. Cloud-only, strong credentials, excluded from your Conditional Access policies, and monitored. These are your way back in if a policy goes wrong.
  3. Build your core policies in report-only mode. At minimum: require MFA for all users, require MFA (ideally phishing-resistant) for admin roles, block legacy authentication, and require MFA for Azure management. Microsoft also offers Microsoft-managed Conditional Access policies designed to replace security defaults, which are worth reviewing.
  4. Review the report-only results in the sign-in logs for a few days. Look for users or apps that would be blocked.
  5. Pick a quiet time, then disable security defaults and switch your policies from report-only to on in the same session.
  6. Test immediately with a standard user, an admin, and a mobile device.
  7. Add the next layer once the core is stable: compliant device requirements, location rules, and session controls.

When security defaults are still the right answer

Not every business needs Conditional Access tomorrow. Security defaults remain a sensible choice if you are on Business Basic or Business Standard without Entra ID P1, have no devices or apps that need exceptions, and have no compliance requirement to control exactly when MFA happens. The worst outcome is not “security defaults instead of Conditional Access.” The worst outcome is neither.

The mistakes I see most often during this move are predictable. Someone disables security defaults to fix one scanner and plans to “do Conditional Access next week.” Someone builds a policy that excludes a large group “temporarily” and never removes the exclusion. Someone forgets the emergency access accounts and locks every admin out with a bad policy. Each of these is avoidable with report-only testing, a written list of exclusions, and a change made in one sitting rather than over several days.

If you are planning the move, our MFA enablement service builds and tests the policies with you. Pair it with Intune device management so you can require compliant devices, and use the Microsoft 365 cost calculator to see what a move to Business Premium would cost. Microsoft’s reference on security defaults in Microsoft Entra ID lists exactly what the baseline enforces.

Frequently asked questions

Are Microsoft 365 security defaults on by default?

For most newer tenants, yes. Older tenants, or tenants where someone turned them off to fix a problem, may have them disabled. Check under Entra ID > Overview > Properties in the Entra admin center.

Can I use security defaults and Conditional Access together?

No. They are designed as alternatives. If you create Conditional Access policies, you need to disable security defaults, so make sure your policies cover the same protections first.

Do I need Entra ID P2 to replace security defaults?

No. Entra ID P1, included in Microsoft 365 Business Premium, is enough to replace security defaults with Conditional Access. P2 adds risk-based policies, which are a useful extra but not required.

Outgrowing security defaults? Start with a free Microsoft 365 security assessment and we will map out the Conditional Access policies your business actually needs.