Conditional Access baseline policies every Microsoft 365 tenant should have

Conditional Access is the policy engine behind every Microsoft Entra ID sign-in. Each policy says: when these users sign in to these apps under these conditions, require these controls (or block). Microsoft's Conditional Access overview explains the model; this article is about which policies to create first.

The baseline below is deliberately small. A handful of well-understood policies, applied to all users with narrow exclusions, protects a tenant far better than thirty overlapping policies nobody can reason about.

Before you build anything

1. Check licensing. Conditional Access requires Microsoft Entra ID P1, included in Microsoft 365 Business Premium, E3 and E5. Risk-based conditions need P2. See Microsoft Entra licensing.

2. Create emergency access accounts. Two cloud-only accounts with the Global Administrator role, strong phishing-resistant credentials, and sign-in alerts. Microsoft's guidance: manage emergency access accounts. Put them in a group such as CA-Exclude-BreakGlass.

3. Plan to turn off security defaults. Security defaults and custom Conditional Access policies can't be used together. Build your policies in report-only mode first, then turn security defaults off and your policies on in the same change window. Unsure which you need? Read Security Defaults vs Conditional Access.

4. Agree a naming convention. Something like CA01-AllUsers-AllApps-RequireMFA makes policies sortable and self-describing in sign-in logs.

5. Learn the testing tools. Report-only mode evaluates a policy without enforcing it, and the What If tool shows which policies would apply to a given sign-in.

The baseline policies

Microsoft publishes Conditional Access templates for most of these. Using the templates is fine; understand each one before you enable it.

1. Block legacy authentication

Legacy protocols (older POP, IMAP, SMTP AUTH and ActiveSync clients using basic authentication) can't perform MFA, so a password is enough to get in. Blocking them removes a favorite target for password spraying. Check sign-in logs for legacy clients before you enforce; our guide to finding and blocking legacy authentication walks through it.

2. Phishing-resistant MFA for admins

Admin accounts are the highest-value targets. Use the built-in authentication strength "Phishing-resistant MFA", which accepts passkeys (FIDO2), Windows Hello for Business and certificate-based authentication. Make sure admins have registered one of those methods before you enforce. See phishing-resistant MFA.

3. MFA for all users

The single most important policy. Target All users and All resources, then exclude only what you must: the break-glass group and any service account that genuinely can't do MFA. Each excluded service account should be documented and, where possible, moved to a workload identity or restricted by location.

4. Protect security-info registration

If an attacker has a password, the next thing they try is registering their own MFA method. A policy on the Register security information user action closes that gap. For brand-new users, issue a Temporary Access Pass so they can register without an existing method.

5. MFA for guests

Guests authenticate with their home organization, but you decide what your tenant requires. Requiring MFA for guest and external users is low-friction for most partners. Cross-tenant access settings can trust MFA performed in a partner's tenant.

6. Compliant devices

Requiring a compliant device means a stolen password alone isn't enough; the attacker also needs one of your managed devices. It depends on Intune compliance policies being in place first, so roll it out after your Intune compliance baseline. For personal phones, use app protection policies and the "require app protection policy" grant instead of full compliance. Microsoft's common ways to use Conditional Access with Intune covers the options.

7. Block device code flow

Device code sign-in lets a user authenticate on another device by typing a code. It's used legitimately by some conference-room devices and command-line tools, and abused in phishing campaigns. The Authentication flows condition lets you block it for everyone except the accounts that need it.

8 and 9. Risk-based policies (Entra ID P2)

With P2, Microsoft Entra ID Protection scores sign-ins and users for risk. Requiring MFA on risky sign-ins and a secure password change for high-risk users lets people fix most risk themselves. Microsoft's templates pair these policies with sign-in frequency set to Every time. See what is Microsoft Entra ID Protection.

Exclusions done right

• Exclude groups, not individuals. A group named for its purpose (CA-Exclude-BreakGlass) is visible, reviewable and reusable.
• Keep break-glass exclusions narrow. Exclude emergency accounts from policies that could lock you out (MFA method requirements, device compliance, location blocks). Don't exclude them from everything, and alert on every sign-in.
• Never exclude "all admins" to make a problem go away. If an admin can't sign in, fix their method, not the policy.
• Review exclusions quarterly. Temporary exclusions become permanent if nobody looks. Access reviews (P2) can automate this.

A rollout plan that avoids lockouts

1. Create each policy in report-only mode. Leave it for at least a week so it sees normal work patterns, month-end processes and travelling staff.

2. Read the results. In the sign-in logs, filter on the policy and look at "Report-only: Failure" and "Report-only: User action required". Each one is a person or device that would have been affected.

3. Fix the causes. Help users register MFA (a registration campaign nudges them), enroll the devices, replace the legacy clients.

4. Enable for a pilot group, such as IT and a few volunteers, then widen to everyone.

5. Tell people before the change. What will happen, when, and who to call. Most "Conditional Access broke everything" stories are really communication failures.

Common mistakes we see in assessments

• Policies left in report-only mode for months, so they give a false sense of coverage.
• An MFA policy targeting a "MFA users" group that new starters are never added to. Target all users and exclude instead.
• Per-user MFA still enabled alongside Conditional Access, which confuses users and support. Microsoft recommends moving to Conditional Access.
• No emergency access accounts, or break-glass accounts whose passwords sit in one person's head.
• Country blocks treated as a primary control. Location conditions are useful, but attackers use local infrastructure; they complement MFA, they don't replace it.

Also check whether Microsoft-managed policies have been created in the tenant. Microsoft adds these automatically in report-only mode and turns them on after a notice period; review them rather than being surprised.

How M365Assessments helps

Every M365Assessments run reads the tenant's Conditional Access policies, security defaults state, authentication methods and MFA registration with read-only permissions, and flags gaps such as legacy authentication not blocked, admins without strong MFA, or policies stuck in report-only. Findings come with a recommended fix, and comparing runs shows whether your rollout closed them. See how it works.