Conditional Access Baseline Policies: Six Policies to Set Up First in a Small Microsoft 365 Tenant

The short version: A small tenant should start with six Conditional Access policies: MFA for administrators, MFA for all users, block legacy authentication, protect security info registration, MFA for Azure management, and MFA for guests. Exclude the emergency access accounts from all six, create each policy in Report-only mode, read the results, and only then switch it On. The registration policy cannot be tested in Report-only, so pilot it with a group instead. The policies are numbered CA001 to CA006 in the list below; the go-live order is different and is given at the end of the Report-only section. You need Microsoft Entra ID P1, which Microsoft 365 Business Premium customers can also use.

This guide is for the administrator of a small or mid-sized Microsoft 365 tenant who has the licence but has not built a Conditional Access baseline yet. For each policy you get who it applies to, the conditions, the grant control and the exclusions, then the Report-only steps for going live safely. Steps were checked against Microsoft Learn on 28 October 2026.

Before you create anything

1. Create two emergency access accounts. Microsoft recommends cloud-only accounts on the onmicrosoft.com domain, with the Global Administrator role assigned permanently and a passkey (FIDO2) as the sign-in method. Put both in a group called EmergencyAccess.
2. Decide what happens to security defaults. Security defaults and Conditional Access replace each other. Disable security defaults (Entra ID > Overview > Properties > Manage security defaults > Disabled) before you rely on the policies.
3. Check for Microsoft-managed policies. In Entra ID > Conditional Access > Policies, rows with Microsoft in the Created by column were created by Microsoft in Report-only state. Microsoft enables them no less than 30 days after introduction if you leave them. Do not create a second copy of the same rule without a reason.  Policies such as "Multifactor authentication for all users" and "Block legacy authentication" may already cover CA003 and CA001, so edit those (state and exclusions) instead of creating duplicates.
4. Pick a naming standard, for example CA001 to CA006 with a short description.
5. Know the roles. You need at least Conditional Access Administrator to create policies.  Licence: Microsoft Entra ID P1 or Microsoft 365 Business Premium; risk-based policies need Entra ID P2.

Everything below is in the Microsoft Entra admin center (entra.microsoft.com) under Entra ID > Conditional Access > Policies > New policy. You can also start from Entra ID > Conditional Access > Create new policy from templates. Microsoft's templates are created in Report-only mode, and a template that targets users excludes only the person who creates it, so you must open the policy afterwards and add your emergency group.

The six policies

Each policy uses the same order: users, target resources, conditions, grant control, exclusions.

CA001: Block legacy authentication

• Users: All users.
• Target resources: All resources (formerly 'All cloud apps').
• Conditions: Client apps > Configure = Yes. Tick only Exchange ActiveSync clients and Other clients.
• Grant: Block access.
• Exclude: the EmergencyAccess group. Add any account that must still use a legacy protocol, as a temporary exception with an end date.
• Before you switch on: find who uses it. Go to Entra ID > Monitoring & health > Sign-in logs, add the Client App column and filter on the legacy protocols. Do this on the interactive and the User sign-ins (non-interactive) tabs.

CA002: Require MFA for administrators

• Users: Include > Directory roles. Microsoft's list is 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.
• Target resources: All resources.
• Conditions: none.
• Grant: Grant access > Require multifactor authentication. Microsoft recommends considering phishing-resistant MFA through authentication strength for admins once they are ready.
• Exclude: the EmergencyAccess group.
• Note: this policy covers built-in roles only. Administrative-unit-scoped and custom roles are not enforced by it.

CA003: Require MFA for all users

• Users: All users.
• Target resources: All resources (formerly 'All cloud apps'), with no app exclusions. Microsoft recommends this as the baseline.
• Conditions: none. If you add a trusted-network exception (Network > Include Any network or location > Exclude All trusted networks and locations), document it, because it weakens the policy.
• Grant: Grant access > Require authentication strength > Multifactor authentication.
• Exclude: the EmergencyAccess group; the directory role Directory Synchronization Accounts if you use Entra Connect or Cloud Sync; and guests only if you are covering them with CA006.

CA004: Secure security info registration

• Users: All users. Exclude All guest and external users (Temporary Access Pass does not work for guests) and the EmergencyAccess group.
• Target resources: User actions > Register security information.
• Conditions: Locations > Configure = Yes, include Any location, exclude All trusted locations.
• Grant: Grant access > Require authentication strength, with the built-in or custom strength you choose.
• Exclude: as above.
• Note: this needs combined registration to be enabled. Issue a Temporary Access Pass to new starters so they can meet the MFA requirement to register. Microsoft's page says that from 6 July 2026 policies targeting Register security information also apply when users register Windows Hello for Business or macOS Platform SSO credentials.

CA005: Require MFA for Azure management

• Users: All users.
• Target resources: Select resources > Windows Azure Service Management API. This covers the Azure portal, Microsoft Entra admin center, Azure PowerShell and Azure CLI.
• Conditions: none.
• Grant: Grant access > Require multifactor authentication.
• Exclude: the EmergencyAccess group.
• Note: Microsoft also enforces MFA on Azure sign-ins itself, and Microsoft says that includes break-glass accounts. Keep this policy anyway so your own rule is visible and testable.

CA006: Require MFA for guests and external users

• Users: Include > Select users and groups > Guest or external users, and choose the guest types you use.
• Target resources: All resources, or the apps your guests need.
• Conditions: none.
• Grant: Grant access > Require authentication strength > Multifactor authentication. Check your cross-tenant access settings for inbound MFA trust first.
• Exclude: the EmergencyAccess group.
• Note: Microsoft says authentication strength currently applies to guests who authenticate with Microsoft Entra ID. For email one-time passcode, SAML/WS-Fed, Google federation and personal Microsoft account guests, use the Require multifactor authentication grant control.

Test in Report-only first

1. When you create each policy, set Enable policy to Report-only and select Create.
2. Let it collect sign-ins for at least one full working week, so month-end or weekly jobs appear. A longer wait is better for CA001. The one-week figure is the writer's suggestion, not a Microsoft number.
3. Open the policy and look at Policy impact (Security Reader role or higher), which shows 24 hours, 7 days or one month of impact on interactive sign-ins.
4. Open Entra ID > Monitoring & health > Sign-in logs, pick a sign-in, and read the Report-only tab to see Success, Failure or User action required for each policy.
5. If you have Entra ID P1 and a Log Analytics workspace receiving sign-in logs, use the Conditional Access Insights and Reporting workbook to compare many sign-ins.
6. Fix the gaps: add exclusions, move scanners to modern authentication, register MFA methods for stragglers.
7. Move Enable policy from Report-only to On, one policy at a time, with a day or two between them.  If sign-ins fail after a policy goes On, sign in with an emergency access account and set that policy back to Report-only or Off.

Microsoft's Report-only page states that items in the User actions scope cannot be evaluated in Report-only mode. CA004 is such a policy, so test it by assigning it to a pilot group first and then widening the group, instead of relying on Report-only results.

Order of go-live that works for most small tenants: CA002 (admins), CA005, CA001 (after the legacy-auth review), CA003, CA006, then CA004.

Common mistakes

1. No emergency access account, or not excluded. A faulty policy can lock out everyone, including you. Test the accounts each quarter.
2. Excluding too much. An exclusion for "the IT team" or "the directors" becomes the way in. Keep exclusions to emergency accounts and genuinely unavoidable service accounts.
3. Using templates without editing the exclusions. Templates exclude only the person who created the policy.
4. Turning policies on without reading Report-only results. Sign-in logs show what would have been blocked.
5. Forgetting service accounts and sync accounts. Entra Connect or Cloud Sync accounts need the Directory Synchronization Accounts exclusion. Replace user accounts used for scripts with managed identities or workload identities.
6. Leaving classic policies behind. Classic Conditional Access policies stopped enforcing on 10 July 2024. Recreate them as modern policies (Entra ID > Conditional Access > Classic policies), then disable them.

How to check it worked

1. Open the Conditional Access tab on a recent sign-in in the sign-in logs and confirm each policy shows as Success or Not applied as you expect.
2. Use the What If tool in Conditional Access with a test user, app and client type to see which policies would apply.
3. Sign in as a test user from a private window and confirm the MFA prompt.
4. Try a legacy protocol connection from a test mailbox and confirm it is blocked.
5. Sign in with an emergency account and confirm it still works. Record the date.
6. Review the Conditional Access Overview and Coverage tabs to see which apps have no policy.

How do you audit the Conditional Access policies a tenant already has?

The six policies above are for a tenant that has nothing yet. In many tenants somebody built policies two or three years ago, a few more were added for a project, and nobody has read the set since. Auditing that set is a different job from building it. You are not asking "which policies should exist" but "does what exists still do what the owner believes it does". Work in the Microsoft Entra admin center under Entra ID > Conditional Access > Policies, with the sign-in logs (Entra ID > Monitoring & health > Sign-in logs, filtered by Conditional Access) open in a second tab, and go through the list below policy by policy. Note the policy name, the state, and what you found; the notes become the report.

Ten things to inspect in an existing Conditional Access set

• Policies still in Report-only. Look at the State column. A policy that has sat in Report-only for months is enforcing nothing, and the person who created it has often forgotten that. Good looks like: every policy is either On with a reason or Off with a reason; nothing is Report-only past its test window.
• Exclusion groups that have grown. Open each policy's Users > Exclude and then open the groups themselves. A group named EmergencyAccess with two members in 2024 can have nine today. Good looks like: exclusions limited to the two emergency access accounts and documented service accounts, each with an owner and a review date.
• Named locations that no longer match the offices. Under Entra ID > Conditional Access > Named locations, compare the trusted IP ranges with the addresses the offices actually use now. An old range belonging to a previous ISP, or to an office that closed, is a trusted location for whoever has that address today. Good looks like: every range matches a current office or VPN exit, and the list carries a last-verified date.
• No legacy-authentication block. Confirm a policy equivalent to CA001 exists and is On, then filter the sign-in logs by Client app for Exchange ActiveSync and Other clients to see whether anything still gets through. Good looks like: the block is On and the legacy-protocol sign-ins in the last 30 days are zero or explained.
• No sign-in frequency or persistent-browser controls. Check Session controls on the user-facing policies. Without them, a token on a shared or unmanaged machine can stay valid for a long time. Good looks like: a defined sign-in frequency for unmanaged devices and persistent browser sessions disabled where the device is not compliant or hybrid-joined.
• "All users" policies with no emergency-access exclusion. Any policy scoped to All users that does not exclude the EmergencyAccess group is a lockout waiting for a bad change. Good looks like: every All-users policy excludes exactly that group, and the emergency accounts are tested on a schedule.
• Device-filter rules that reference retired models. Open Conditions > Filter for devices and read the rule. Filters written around a device model, operating system version or naming prefix that the company no longer uses silently match nothing, which usually means the control they were meant to apply no longer applies. Good looks like: filters expressed in attributes that are still maintained, such as compliance state or trust type.
• Duplicated Microsoft-managed policies. Rows with Microsoft in the Created by column may duplicate CA001 or CA003. Two policies with the same rule but different exclusions produce results nobody can predict. Good looks like: one policy per rule, with the Microsoft-managed copy either adopted and edited or deliberately switched off.
• An admin MFA policy that excludes service accounts. Open the CA002 equivalent and read the exclusions. Service accounts holding administrator roles without MFA are the most common path from a leaked password to a tenant takeover. Good looks like: no human or service account with a privileged role is excluded; automation runs under managed identities or workload identities instead.
• No policy covering guests. Check whether anything targets Guest or external users. Guests from a partner that ended two projects ago still have a seat in Teams and SharePoint. Good looks like: a CA006 equivalent is On, cross-tenant access settings are reviewed, and stale guests are removed on a schedule.

For each line, the finding is only useful if it can be checked by someone else later. Export the policy set as JSON (each policy's Download JSON action, or the Graph API), save a dated sign-in log sample showing the Conditional Access result for a representative user, and record who reviewed the exclusion groups and when. Those three items, kept with the review date, are designed to be used as evidence when an insurer, auditor or client asks how access is controlled; a screenshot of the policy list on its own is not.

This list is a large part of the identity section of our one-off Microsoft 365 security audit, which reviews every policy, exclusion group and named location in the tenant and records the result against the CIS Microsoft 365 Benchmark. The companion article on the MFA gap report covers the other half of the identity picture: which users are actually registered for MFA, and which methods they use.

FAQ

What is Conditional Access?

It is a Microsoft Entra feature that makes access decisions in an if-then pattern. If a user wants a resource such as Microsoft 365, then they must meet a requirement, such as MFA. Microsoft enforces the policy after first-factor authentication is complete.

What is Microsoft Entra?

Microsoft Entra is Microsoft's brand for its identity and access products. Microsoft Entra ID, formerly Azure Active Directory, is the directory that holds your Microsoft 365 users. Conditional Access is configured in the Microsoft Entra admin center under Entra ID > Conditional Access.

What type of authentication does Azure use?

Sign-ins use Microsoft Entra ID. With Conditional Access you can require built-in authentication strengths: Multifactor authentication, Passwordless MFA or Phishing-resistant MFA.

Is Azure Policy the same as Conditional Access?

No. Azure Policy is a separate governance service for Azure resources. Conditional Access controls sign-in to apps and resources based on identity signals. Microsoft notes Azure Policy can also audit or deny Azure requests that lack MFA, but that is a different mechanism.

Next step

If you want a second pair of eyes on your Conditional Access policies and the rest of your tenant, see our Microsoft 365 security audit, and read how to enable MFA in Microsoft 365, how to improve your Secure Score and the Microsoft 365 security checklist.

If you would rather know the price of a full review before you start, what a Microsoft 365 security audit costs sets out the fixed prices by headcount.