Microsoft Entra Conditional Access Baseline for SMBs
Conditional Access is the policy engine that controls how and when users can access Microsoft 365 resources. It is the correct mechanism for enforcing MFA, blocking legacy authentication and requiring compliant devices - more reliable and more flexible than Security Defaults. This guide covers the minimum policy set every small or mid-sized organisation should implement, the correct deployment order and how to avoid disrupting your users during rollout.
Before you start
Conditional Access requires Microsoft Entra ID Plan 1, which is included in Microsoft 365 Business Premium, E3 and E5. It is not available on Business Basic or Business Standard without an Entra ID P1 add-on.
Before creating any Conditional Access policies, you must configure break-glass accounts. These are two emergency admin accounts that are excluded from all Conditional Access policies. Their purpose is to ensure you can access the tenant if a policy misconfiguration locks out all admin accounts. Without break-glass accounts in place before you start, a policy mistake can result in complete admin lockout.
Configure break-glass accounts before creating any Conditional Access policies. Two accounts, Global Admin role, excluded from all CA policies, with sign-in alerts configured. This is not optional.
The minimum policy set
These six policies form the Conditional Access baseline for a Microsoft 365 Business Premium environment. Deploy them in this order, and use report-only mode for each policy before switching to enforcement.
- 01
Require MFA for all users
Scope: All users. Cloud apps: All cloud apps. Grant: Require multi-factor authentication. This is the single most impactful Conditional Access policy. It ensures MFA cannot be skipped or disabled by individual users. Exclude your break-glass accounts. Deploy in report-only mode for at least three business days before enforcing, and review the sign-in logs to confirm it will not block legitimate access.
- 02
Block legacy authentication
Scope: All users. Client apps: Exchange ActiveSync clients, Other clients (legacy protocols). Block access. Legacy authentication protocols bypass MFA entirely - a user with MFA enabled can still be compromised via Basic Auth SMTP or IMAP if this policy is not in place. Check sign-in logs for any active legacy auth sign-ins before enforcing - some older applications and printers use SMTP Auth and will need to be reconfigured first.
- 03
Require MFA for administrators
Scope: Directory roles - Global Admin, Exchange Admin, SharePoint Admin, Conditional Access Admin, Security Admin (at minimum). Cloud apps: All. Grant: Require MFA. This is separate from the all-users MFA policy because it applies even if an admin account is excluded from the main policy for any reason. Privileged accounts should always require MFA. No exceptions.
- 04
Require compliant device for Microsoft 365
Scope: All users. Cloud apps: Microsoft 365 apps. Grant: Require device to be marked as compliant. This ensures only Intune-managed, compliant devices can access Microsoft 365. Enable only after Intune is configured and your devices are enrolled and compliant. Deploy in report-only mode first - non-compliant or personal devices will show as blocked in the logs. Coordinate the enforcement rollout with users to avoid productivity disruption.
- 05
Block access from high-risk sign-in locations
Scope: All users. Locations: block any or all locations except named locations (your corporate IP ranges and trusted countries). This is optional but recommended - restrict access to countries your organisation operates in. If your users travel internationally for work, include those countries in named locations before enforcing. This significantly reduces attack surface from automated credential stuffing originating from overseas.
- 06
Require MFA for Microsoft Azure management
Scope: All users. Cloud apps: Microsoft Azure Management. Grant: Require MFA. If your organisation uses Azure, this policy ensures that access to Azure resources always requires MFA regardless of other policy exclusions. Lower priority than the above policies, but worth including in any complete CA baseline.
How to deploy without disrupting your users
- 01
Deploy all policies in report-only mode first
Report-only mode logs what would happen without actually enforcing the policy. Leave each policy in report-only mode for a minimum of three to five business days. Review the sign-in logs (Entra ID > Monitoring > Sign-in logs) to identify any accounts or applications that would be blocked.
- 02
Communicate to users before enforcement
Inform users that MFA will be required from a specific date. Provide instructions for setting up the Microsoft Authenticator app. Give users at least five business days notice. Include your helpdesk contact for users who need assistance.
- 03
Address exceptions before enforcement
Identify any service accounts, shared mailboxes or legacy applications that appear in report-only logs as blocked. Reconfigure them to use modern authentication before the policy goes live. Document any temporary exclusions with a named owner and review date.
- 04
Enforce the all-users MFA policy first
Switch the all-users MFA policy from report-only to on. Monitor the helpdesk queue for the first two business days. Most disruption occurs in the first 48 hours as users complete MFA registration.
- 05
Enforce remaining policies sequentially
Enforce the legacy authentication block next, then admin MFA, then the device compliance policy (which requires Intune to be fully deployed first). Allow three to five business days between each enforcement to identify and address issues before adding the next layer.
Common implementation mistakes
- Enforcing policies without report-only review first - results in unexpected lockouts for legitimate users or applications
- Forgetting to configure break-glass accounts before creating any policies
- Excluding too many accounts from MFA policies - each exclusion is a potential attack vector
- Not testing the compliant device policy before enforcement - users on personal devices or non-enrolled corporate devices lose access without warning
- Not checking for legacy auth sign-ins before blocking legacy authentication - printers, scanners and older applications frequently use SMTP Auth and will stop working
- Creating Conditional Access policies without understanding the difference between 'all cloud apps' and 'selected cloud apps' - inadvertently blocking non-Microsoft services that authenticate via Entra ID
Accuracy
Last reviewed: 9 October 2026 · Microsoft product capabilities, licensing and configuration options change regularly. Verify current details at learn.microsoft.com.
Next step
Implement the Cloud Security Baseline
The Cloud Security Baseline implements these Conditional Access policies in your environment - tested in report-only mode, reviewed with your team, and enforced without disruption. From $4,500.
Learn more