Security Defaults vs Conditional Access for a Small Business Tenant: Which to Turn On First

The short version: Security defaults are a free, on-or-off setting in Microsoft Entra ID that makes every user register for MFA, requires MFA for administrators and blocks legacy authentication. Conditional Access does the same jobs with rules you write, but it needs Microsoft Entra ID P1 (included in Microsoft 365 Business Premium) for the users it covers. You cannot run both at once. Without P1, keep security defaults on. With P1, build Conditional Access policies in report-only mode first, then switch off security defaults and enforce the policies in the same change window.

Most small Microsoft 365 tenants reach this question the same way: a new app or a shared mailbox stops working, someone finds that security defaults are the cause, and the suggestion is to "turn them off and use Conditional Access instead". Sometimes that is the right move. Sometimes it leaves the tenant with neither, which is the worst of the three possible states.

This guide covers the security defaults vs Conditional Access decision for a small business: what each one does, what licence Conditional Access needs, how to choose, and the order to switch over safely. It does not repeat the list of policies to build; our Conditional Access baseline policies guide covers that, and this article links to it at the step where you need it.

What do security defaults actually do?

Security defaults are a single switch in the Microsoft Entra admin center, available on every tenant at no extra cost. When they are on:

• Every user must register for MFA. Microsoft has removed the 14-day grace period that used to let users postpone registration, so users register at sign-in.
• Administrators are asked for MFA every time they sign in. Admin roles are where a stolen password does the most damage.
• Other users are asked for MFA when Microsoft's sign-in signals call for it, rather than on every sign-in.
• Legacy authentication is blocked. Sign-ins using older protocols that cannot do MFA are refused.

What you cannot do is tune any of it. There are no exclusions, no choice of which apps require MFA and no conditions based on device or location. That is the point: security defaults are designed for tenants that have no one to manage policies. It is also why they sometimes break things, such as an old scanner that sends email with a basic password, or an emergency account you would rather not tie to a single phone.

Microsoft's own guidance is that tenants with Entra ID P1 or P2 licences are probably better served by Conditional Access, and tenants with complex requirements should use it.

What does Conditional Access add?

Conditional Access is a policy engine. Each policy says: for these users, signing in to these apps, under these conditions, require this (MFA, a compliant device, a password change) or block. That lets you do what security defaults cannot:

• Exclude named accounts on purpose, such as two emergency access accounts protected by passkeys.
• Require MFA every time for everyone, not only when Microsoft judges the sign-in risky.
• Use device and location conditions, for example allowing access to files only from managed laptops.
• Test before enforcing, because every policy can run in report-only mode and show what it would have done.

The cost is twofold. Conditional Access needs Microsoft Entra ID P1 (or P2) licences for the users it covers; P1 is included in Microsoft 365 Business Premium and in the E3 and E5 suites, and the plans are compared on our Microsoft 365 pricing page. And someone has to own the policies: a policy written once and never reviewed collects exclusions until it protects very little.

Security defaults vs Conditional Access at a glance

Side by side

• Licence: security defaults are included with every tenant; Conditional Access needs Entra ID P1 or P2 for the users it covers.
• Control: security defaults are one switch with no options; Conditional Access is a set of policies you write and maintain.
• MFA for ordinary users: security defaults ask when Microsoft's signals call for it; Conditional Access asks whenever your policy says, usually every sign-in.
• Exclusions: none with security defaults; any account or group you choose with Conditional Access, which is a strength and a risk.
• Legacy authentication: both block it; with Conditional Access you must write the policy.
• Testing: security defaults have no test mode; Conditional Access policies can run in report-only first.
• Who maintains it: Microsoft maintains security defaults; you, or your provider, maintain Conditional Access.

Which one should a small business run?

Three questions settle it.

1. Do the users you want to protect have Entra ID P1? If not, keep security defaults on. Switching them off without P1 leaves you with nothing, and a tenant with neither is exactly the kind of gap an audit flags first.
2. Is there someone who will own the policies? If you have P1 but nobody will review policies and their exclusions at least quarterly, security defaults may still be the safer setting until that changes.
3. Is something specific broken by security defaults? If the only problem is one legacy device or app, fix that device or app first (move it to modern authentication or a supported relay). Do not switch off tenant-wide protection to accommodate it.

If the answers are "yes, yes, and we need the flexibility", move to Conditional Access. Most small businesses that buy Business Premium for its Intune and Defender features end up here anyway, because they already have the licence.

One state to retire on the way: some older tenants still have MFA switched on per user from the legacy MFA settings page. Treat that as a third configuration to clean up during the switch-over rather than something to keep alongside Conditional Access.

How do you switch from security defaults to Conditional Access safely?

Security defaults and Conditional Access cannot run at the same time; the admin center will not let you enable Conditional Access policies while security defaults are on. So the switch has a moment of exposure, and the aim is to make it minutes, not weeks. Do the preparation first and the cut-over in one sitting.

1. Confirm licences. Check that every user your policies will cover has Entra ID P1, directly or through Business Premium or an E3/E5 suite.
2. Find what still uses legacy authentication. In the sign-in logs, filter by client app for older protocols. Scanners, line-of-business apps and old mail clients show up here. Fix or replace them before the cut-over.
3. Create two emergency access accounts. Cloud-only, Global Administrator, strong passkeys stored separately, excluded from your policies by a dedicated group, and monitored.
4. Check MFA registration. Everyone should already be registered under security defaults, but confirm it. Our guide to finding every user without MFA shows how to build that report in Entra.
5. Build the policies in report-only mode. Use the six policies in our Conditional Access baseline guide as the starting set. Report-only policies can be created while security defaults are still on.
6. Read the report-only results for at least a week. Look for sign-ins the policies would have blocked or challenged that you did not expect, and adjust before enforcing.
7. Cut over in one change window. Switch off security defaults, then immediately switch each policy from report-only to on. Test an admin sign-in, an ordinary user sign-in and the emergency accounts before you finish.
8. Check the Microsoft-managed policies. Tenants with P1 may see policies created by Microsoft in report-only state. Decide whether each one stays, is enforced, or is covered by your own policy, and write that down.
9. Watch the sign-in logs for a week. Failures from a forgotten service account usually appear in the first days.

What goes wrong most often?

• Switching security defaults off "temporarily" and forgetting. The tenant then runs with no MFA requirement at all.
• Excluding a whole group to fix one user. Exclusions should name accounts and carry a reason and a review date.
• No emergency access accounts, or emergency accounts that depend on one person's phone.
• Enforcing without report-only, and discovering the effect through the help desk.
• Leaving legacy authentication open because the policy to block it was the one left for later.
• Forgetting guests and service accounts. Guest users and accounts used by applications sign in too; decide deliberately whether each policy covers them, and record the decision.
• Nobody owns the review. Put a quarterly reminder in someone's calendar to read the policy list and every exclusion. A policy set that nobody reviews slowly turns back into security defaults with holes.

Where does an audit fit?

If your tenant already runs Conditional Access, the question is no longer which to choose but whether the policies still do what they were written to do. That is a configuration audit question: which policies are on, who is excluded and why, whether legacy authentication is really blocked, and whether every account is covered by something. Our Microsoft 365 security audit checks Conditional Access policies and their exclusions as part of its identity review, with the current pricing on that page. If you would rather have the rollout done for you, our MFA solutions service covers design, user enrolment and Conditional Access.

Frequently asked questions

Can I use security defaults and Conditional Access at the same time?

No. They are alternatives. Conditional Access policies cannot be enabled while security defaults are on, which is why the switch-over has to be planned as a single change.

Do I need Business Premium for Conditional Access?

You need Microsoft Entra ID P1 or P2 for the users the policies cover. Business Premium includes P1, as do the Microsoft 365 E3 and E5 suites. P1 can also be bought on its own.

Are security defaults enough for a cyber insurance questionnaire?

Often they answer the core questions, because they require MFA registration for all users, MFA for administrators and block legacy authentication. Insurance forms that ask whether MFA is enforced on every sign-in to email, or on all remote access, may need the precision of Conditional Access. Read the question literally and answer with dated evidence.

Will turning on security defaults lock anyone out?

Users who have not registered for MFA will be asked to register at sign-in, and apps that use legacy authentication will stop working. Check the sign-in logs for legacy authentication first and tell staff before you switch it on.

Can I exclude an emergency account from security defaults?

No. Security defaults have no exclusions. If you need emergency access accounts with their own authentication method, that is one of the reasons to move to Conditional Access.

We switched security defaults off years ago and have no Conditional Access. What now?

Turn security defaults back on today unless you can deploy Conditional Access this week. Then plan the Conditional Access move properly, following the order above.

Next step

If you are not sure which state your tenant is in, or you want the switch-over planned and run for you, talk to a consultant. For a full picture of identity, email and sharing settings first, start with the Microsoft 365 security audit.