Conditional Access Starter Policies for Small Businesses

By Justin N. · Updated 2026-10-22 · This page may contain affiliate links

Conditional Access is the "if this, then that" engine in Microsoft Entra ID. If someone signs in from here, on this device, to this app, then require MFA, require a healthy device, or block them. Business Premium includes it through Entra ID P1. Here is the starter set I'd build for a 5–50 person business, in the order I'd build it.

Licensing check: Conditional Access needs Entra ID P1, which is included in Microsoft 365 Business Premium and Microsoft 365 E3. Risk-based policies (sign-in risk, user risk) need Entra ID P2, which neither plan includes. They're out of scope here.

First: security defaults vs. Conditional Access

New tenants often have security defaults turned on. Security defaults are a free, all-or-nothing baseline: MFA registration for everyone, MFA for admins, and legacy authentication blocked. They're a good baseline for tenants that can't use Conditional Access. You can't run both, though, so you'll turn security defaults off as you turn your own policies on.

To find the setting, sign in to the Entra admin center (entra.microsoft.com), go to Entra ID > Overview > Properties, and select Manage security defaults. Microsoft's security defaults article lists this same path (checked October 2026).

Order matters: build your Conditional Access policies in report-only mode first, then turn off security defaults and switch the policies on in the same sitting. Don't leave a gap where neither is protecting you. If you're still deciding which to use, see Security defaults vs Conditional Access.

You may also see Microsoft-managed policies already in your policy list. According to Microsoft's Microsoft-managed policies article, Microsoft creates them in eligible tenants in report-only mode and turns them on automatically no less than 30 days later unless you set them to Off first. You can't delete or rename them, but you can exclude users (add your break-glass group) or switch them on or off. Review them early, because they often overlap with the policies below.

Before any policy: two emergency access accounts

Microsoft's own policy guidance says to exclude emergency access ("break-glass") accounts from your policies. One bad policy can lock every admin out of the tenant, and these accounts are your way back in.

Create two cloud-only accounts on the .onmicrosoft.com domain with the Global Administrator role. Don't tie them to a person's mailbox.
Give them very long, unique passwords plus a phishing-resistant MFA method, such as a FIDO2 security key (passkey) or certificate-based authentication. A password alone isn't enough anymore (see the note on mandatory MFA below). Store the passwords and keys offline in two separate places.
Put both in a group named something like SG-CA-Exclude-BreakGlass and exclude that group from every policy below.
Set up an alert when either account signs in. In a small office, any sign-in by these accounts should be a surprise.

Microsoft also enforces mandatory MFA for its admin portals, separate from your own policies. According to Microsoft's mandatory MFA article, enforcement started in October 2024 for the Azure portal, Microsoft Entra admin center, and Intune admin center, began rolling out to the Microsoft 365 admin center in February 2025, and extended to Azure CLI, Azure PowerShell, and similar tools from October 1, 2025. Microsoft says this applies to every user account, including break-glass accounts, and recommends giving emergency accounts a passkey (FIDO2) or certificate-based authentication. Excluding them from your Conditional Access policies doesn't exempt them from Microsoft's enforcement, so test that each one can complete MFA. Phase 2 (Azure CLI, PowerShell, and similar tools) applies only to create, update, and delete operations. Read operations don't require MFA, per the same Microsoft article.

How to build each policy

Every policy below starts the same way:

Sign in to the Entra admin center as at least a Conditional Access Administrator.
Browse to Entra ID > Conditional Access > Policies and select New policy.
Give it a name that follows a pattern. I use CA01-Block-LegacyAuth-AllUsers, so the list sorts in order and the name says what it does.
Set Enable policy to Report-only, then select Create.

Many of these also exist as templates (Conditional Access > Policies > New policy from template). They're a fine shortcut, but read every setting the template creates.

CA01: Block legacy authentication

Legacy protocols such as basic-auth POP, IMAP, and SMTP don't support MFA. Based on Microsoft's analysis, more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication (Microsoft Learn). Block them first.

Users: Include All users. Exclude the break-glass group, plus any account that genuinely still needs legacy auth (document why, and give it an end date).
Target resources: All resources (formerly "All cloud apps").
Conditions > Client apps: Configure Yes and check only Exchange ActiveSync clients and Other clients.
Grant: Block access.

Before you enforce it: go to Entra ID > Monitoring & health > Sign-in logs, add the Client App column, and filter for the legacy protocols. Check the non-interactive sign-ins tab too. The usual surprises in small offices are a scan-to-email copier and an old accounting add-in.

CA02: Require phishing-resistant MFA for admins

Users: Include Directory roles. Microsoft's phishing-resistant MFA for admins policy recommends at least these 14: 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. I also add Intune Administrator. Exclude break-glass.
Target resources: All resources.
Grant: Require authentication strength > Phishing-resistant MFA.

Microsoft's built-in Phishing-resistant MFA authentication strength accepts passkeys (FIDO2), Windows Hello for Business or platform credential, and multifactor certificate-based authentication. Passkeys in Microsoft Authenticator are registered under the Passkey (FIDO2) method, so they count. Ordinary Authenticator push or phone sign-in does not. If your admins don't have a phishing-resistant method registered yet, temporarily use the built-in Multifactor authentication strength and set a date to tighten it. Microsoft also warns that a phishing-resistant requirement on All resources can trap users in a loop when they try to add a passkey in Authenticator, so issue a Temporary Access Pass for that first registration.

CA03: Require MFA for all users

This is Microsoft's own recommended baseline: all users, all resources, require MFA, with no app exclusions.

Users: All users. Exclude break-glass. If you sync from on-premises AD, also exclude the Directory Synchronization Accounts role. Optionally exclude guests if you'll give them their own policy.
Target resources: All resources.
Grant: Require authentication strength > Multifactor authentication.

Microsoft notes that external authentication methods don't currently work with authentication strengths. If you use one, choose the classic Require multifactor authentication grant instead.

You may be tempted to skip MFA at the office by adding a trusted named location for your office's public IP. It works, but I'd avoid it. An attacker on your guest Wi-Fi then skips MFA too. Modern MFA prompts are infrequent enough on managed devices that the exception rarely pays off.

CA04: Protect security info registration

If an attacker has a user's password, the next thing they try is registering their own MFA method. Lock that down with a user action policy:

Users: All users. Exclude break-glass and guests.
Target resources: choose User actions > Register security information.
Grant: require MFA (authentication strength), or require a compliant device.

New hires who have no MFA method yet can bootstrap with a Temporary Access Pass, which you issue from the user's Authentication methods page. It counts as strong authentication for registration.

Consider a similar policy on the Register or join devices user action so that joining a PC to Entra ID requires MFA.

CA05: Require a compliant device on Windows and macOS

This is the policy that makes Intune pay off: company data is reachable only from PCs that Intune says are healthy. Build it last, after every PC is enrolled and showing compliant (see the Intune setup guide).

Users: All users. Exclude break-glass and guests.
Target resources: All resources. You don't need to exclude the Intune enrollment app. Microsoft's device-compliance policy article says the Require device to be marked as compliant control doesn't block Intune enrollment, so new devices can still enroll. Microsoft's recommended exclusions are your break-glass accounts and, if you sync from on-premises AD, the Directory Synchronization Accounts role.
Conditions > Device platforms: Include Windows and macOS.
Grant: Require device to be marked as compliant. If you have hybrid-joined PCs, also tick Require Microsoft Entra hybrid joined device and choose Require one of the selected controls.

Expect this one to catch personal home PCs that people quietly use for email. That's the point. Decide in advance whether to allow browser-only access from unmanaged PCs (see CA07) or to say no.

CA06: Phones and tablets: require app protection

Most small offices don't want to fully enroll personal phones. Intune app protection policies (MAM) protect the Outlook, Teams, and OneDrive data inside the apps without managing the whole phone.

In Intune, create app protection policies for iOS/iPadOS and Android under Apps > Protection (also labeled App protection policies). Require a PIN, block copy/paste into unmanaged apps, and allow selective wipe.
Back in Conditional Access: Users All users (exclude break-glass), Target resources All resources, Device platforms iOS and Android, Grant Require app protection policy.

This blocks the built-in iOS Mail app and other non-Microsoft mail apps from your mailboxes, which is intentional. Tell staff ahead of time to install Outlook. For the full app protection setup, with Microsoft's recommended settings, see Intune app protection for BYOD phones.

CA07: Browser sessions on unmanaged devices

If you want to allow occasional browser access from a home PC, limit what that session can do instead of blocking it:

Users: All users, excluding break-glass.
Target resources: Office 365.
Conditions > Client apps: Browser.
Conditions > Filter for devices: Include filtered devices in policy with the rule Microsoft uses in its own unmanaged-device sign-in frequency policy: device.trustType -ne "ServerAD" -or device.isCompliant -ne True. Microsoft notes that unregistered devices have null properties, so negative operators like -ne are the reliable way to catch them.
Session: set Sign-in frequency to a short period (Microsoft's example is 1 hour) and Persistent browser session to Never persistent. Use app enforced restrictions passes device state to SharePoint and Exchange Online, which can then give unmanaged devices a limited, web-only experience (you configure that limit in SharePoint and Exchange too).

Getting CA05 and CA07 to cooperate takes care, because CA05 as written above also blocks browsers on non-compliant Windows PCs, and when policies overlap, all of them apply. If you decide to allow browser access from unmanaged PCs, one approach is to set CA05's Conditions > Client apps to Mobile apps and desktop clients only, so CA05 covers desktop apps and CA07 covers browsers. That's my approach, not a Microsoft template. Leave both in report-only and check them with the What If tool and the report-only results in the sign-in logs before you enforce anything.

CA08 (optional): Block countries you never work from

Create a named location under Conditional Access > Named locations listing the countries you do work from. Then create a policy for all users and all resources that blocks access from any location except that list. It's a cheap way to cut noise from overseas password spraying. Remember to update it before someone travels.

Testing, then switching on

Leave everything in report-only for at least a few business days.
In the sign-in logs, open individual sign-ins and check the Report-only tab to see what each policy would have done.
Use Conditional Access > Policies > What If to simulate a specific user, app, platform, and location.
Turn security defaults off, then switch policies to On one at a time in this order: CA01, CA02, CA03, CA04, CA06, then CA05/CA07 once devices are ready.
Sign in as your own test user after each change, from a private browser window, while you still have another admin session open.

The Conditional Access insights and reporting workbook is useful, but it needs sign-in logs sent to a Log Analytics workspace, which means an Azure subscription and possible ingestion costs. For a small tenant, the sign-in logs are usually enough.

Mistakes I'd avoid

Forgetting the break-glass exclusion on even one policy.
Enforcing "require compliant device" before devices are enrolled.
Excluding "just this one app" from the MFA policy. Exclusions pile up and become the attack path.
Using a trusted office IP as an MFA bypass.
Not telling staff what will change. A one-paragraph email the day before prevents most helpdesk calls.

Related: Conditional Access protects sign-ins, but two other gaps are worth closing next. Offboarding an employee covers cutting off a leaver's access the same day, and SPF, DKIM, and DMARC stops attackers from sending email that looks like it came from your domain.

Sources

Useful links for this guide: Microsoft's guide to enabling passkeys (FIDO2) and security keys · free Microsoft Learn training for Entra ID. These are ordinary links, not affiliate links.

Accuracy note: Microsoft changes admin center menus and licensing often. Paths and prices were checked against Microsoft documentation on 2026-10-22. If something has moved, tell me at [email protected].