CtrlShiftIT
Free IT Assessment
Microsoft 365 Security

Conditional Access Policies for Small Business

Conditional Access is the identity-control layer that makes MFA, device compliance, and location-based rules work together. Done right, it stops most credential-based attacks. Done wrong, it locks out your team. Here is the safe deployment plan.

  • Create a break-glass account before any policy
  • Roll out in report-only mode first
  • Build the SMB baseline: MFA, block legacy auth, admin device compliance
Request a Free Security AssessmentBack to M365 Hub
15 min read Reviewed April 2026
5baseline policies protect every Business Premium tenant
1break-glass account created before any policy exists
7 daysminimum in report-only mode before you enforce
48 hbetween each policy enablement, so you can see what broke

Why Conditional Access is the identity-control layer every SMB needs

MFA alone is no longer enough. Attackers use adversary-in-the-middle phishing kits to capture both the password and the session cookie, defeating standard MFA. Conditional Access closes that gap by adding context to every sign-in: who is signing in, from what device, in what location, with what risk score.

For a Business Premium tenant, Conditional Access is included. The question is not whether to use it, but how to deploy it without breaking your team.

Before you begin

Before you begin: license, defaults, and the critical first step

Confirm the license

You need Microsoft 365 Business Premium or Azure AD Premium P1 to use Conditional Access (rather than Security Defaults). Confirm the license before planning.

Turn off Security Defaults

If your tenant currently uses Security Defaults, disable them before creating Conditional Access policies — the two cannot coexist. Toggle: Entra admin center → Identity → Overview → Properties → Manage Security Defaults.

Policy anatomy

How Conditional Access policies work

Every Conditional Access policy answers two questions: who and what does this apply to, and what controls do we require?

Stage 01

Assignments

Users and groups (include / exclude), cloud apps targeted, conditions (sign-in risk, device platform, location, client app).

Stage 02

Access controls

Grant (require MFA, require compliant device, require approved client app) or Block. Optionally apply session controls.

Stage 03

Report-only mode

Run any new policy in Report-only first. Sign-in logs show what the policy would have done without actually enforcing it.

The SMB baseline

The recommended SMB baseline policy set

These five policies form the baseline we deploy in every Business Premium tenant. Tune from here, do not start broader.

POL-01

Require MFA for all users

On
Users
All users · break-glass excluded
Scope
All cloud apps
Control
Grant · require MFA

Targets all users, all cloud apps, with the break-glass account excluded. The single most important policy.

POL-02

Block legacy authentication

On
Users
All users
Scope
ActiveSync + other legacy clients
Control
Block

Targets all users, all cloud apps, with the condition "Client app = Exchange ActiveSync clients, Other clients". Blocks IMAP, POP, SMTP AUTH — the most common MFA bypasses.

POL-03

Require compliant device for admins

On
Users
Admin role assignments
Scope
All cloud apps
Control
Grant · require compliant device

Targets users in admin role assignments. Forces admin sign-ins to come from an Intune-compliant device. Stops session-cookie theft from unmanaged laptops.

POL-04

Require MFA for guests

On
Users
Guest users
Scope
All cloud apps
Control
Grant · require MFA

Targets guest user type, all cloud apps. Guest accounts often outlive the relationship — MFA limits the damage of forgotten guests.

POL-05

Block access from high-risk countries

Report-only first
Users
All users
Scope
Outside named trusted locations
Control
Block

Optional but powerful. Block sign-ins from countries your staff do not work in. Define trusted locations under Identity → Conditional Access → Named locations.

Staged deployment

Rollout strategy that avoids lockouts

  1. 01

    Create the break-glass account

    Before anything else. Two break-glass accounts is better than one — store them in different physical locations.

  2. 02

    Disable Security Defaults

    If currently enabled. Otherwise CA policies will conflict.

  3. 03

    Build all baseline policies in Report-only mode

    1 week min

    Run them for at least one full work week. Review the Sign-in logs → Conditional Access tab daily to spot users who would have been blocked.

  4. 04

    Fix the report-only findings

    Common issues: a legacy app using IMAP, a service account without MFA, an executive on a personal device for admin work. Resolve each before moving on.

  5. 05

    Enable policies one at a time

    48 h gaps

    Turn the MFA-for-all-users policy On first. Wait 48 hours. Then block legacy auth. Then admin compliance. Staged enablement makes it easy to identify which policy broke what.

  6. 06

    Communicate before each enablement

    Email all staff 3 days before enforcing MFA: "Here is what is happening, here is how to enroll, here is the support line if you have trouble."

  7. 07

    Monitor sign-in logs for 2 weeks after enforcement

    Watch for blocked sign-ins from legitimate-looking patterns. The first 2 weeks reveal the corner cases your report-only run did not catch.

What If simulator

Testing your policies before full enforcement

Conditional Access has a "What If" tool — Entra → Conditional Access → What If — that simulates a sign-in scenario and tells you which policies would apply. Use it for every policy:

Test as a normal user

MFA prompt

Confirm they get the expected MFA prompt and that nothing is blocked.

Test as an admin

Grant · compliant

Confirm device-compliance enforcement and that admin sign-in works from a compliant device.

Test as the break-glass account

No restriction

Confirm the account is excluded from all policies and can sign in without restriction.

Test from a non-compliant device

Block

Confirm admin sign-in is correctly blocked. If it succeeds, the policy is misconfigured.

If it goes wrong

Recovery strategy: if something goes wrong

Despite all precautions, eventually a policy will lock someone out unexpectedly. Be ready:

  1. 1

    Sign in as the break-glass account

    Disable or fix the problem policy via the Entra portal.

  2. 2

    Re-enable the policy in Report-only mode

    Investigate the lockout in Sign-in logs before re-enabling enforcement.

  3. 3

    Document the incident

    Add the discovered edge case to your CA testing checklist so it does not recur.

  4. 4

    Rotate the break-glass password if used

    Treat any break-glass sign-in as a security event. Reset the password and re-store the new one.

Avoid these

Common mistakes — and how to avoid them

No break-glass account

The most common — and most painful — mistake. Always create one first.

Enforcing all policies at once

You cannot debug what broke. Roll out one policy at a time.

Skipping Report-only

You will discover edge cases the hard way. Always start in Report-only.

Excluding too many accounts

Every exclusion is a hole. Document each one and review quarterly.

No communication to staff

Staff will report "Microsoft is broken" to support rather than recognize an MFA prompt.

Keep going

More Microsoft 365 security guides

Microsoft 365 Security Checklist for Small Businesses (2026)

A 19-control Microsoft 365 hardening checklist for Canadian small businesses: MFA, Conditional Access, legacy auth, phishing defense, endpoints, backup, and incident response.

Phishing & Email Threat Defense for Microsoft 365

How to configure Microsoft Defender anti-phishing, Safe Links, impersonation protection, and reporting habits for small teams on Microsoft 365.

Rolling Out MFA Without Breaking Things

A practical rollout plan for Microsoft 365 MFA across staff, shared mailboxes, service accounts, BYOD devices, and admin accounts.

Microsoft 365 Backup for Small Business

Why OneDrive sync and the Recycle Bin are not full backups, and what small businesses should deploy for reliable Microsoft 365 recovery.

FAQ

Frequently Asked Questions

5 results
CoverageWhat if I have Microsoft 365 Business Standard, not Premium?

Business Standard does not include Conditional Access — only Security Defaults, which enforce MFA but offer no granular control. Either upgrade to Business Premium ($35/user/month at time of writing) or use Security Defaults and accept the lower granularity.

SecurityCan I use Conditional Access alongside Security Defaults?

No — they are mutually exclusive. Disable Security Defaults before creating Conditional Access policies.

CoverageHow long should I run policies in Report-only?

At least one full business week, including a weekend, to capture weekend usage patterns and the after-hours work that often reveals unmanaged devices.

CoverageShould I require compliant devices for all users?

For most SMBs, start with admins-only. Requiring compliant devices for all users requires every staff device be Intune-enrolled, which is a larger lift. Plan it as Phase 2 after the baseline policies are stable.

CoverageWhat happens to legacy apps that need IMAP/POP?

They break. Most "legacy" apps have modern equivalents or OAuth-capable replacements. If you genuinely need to keep one (a copier that scans-to-email, an old line-of-business app), create a service account with a strong password, exclude it from the legacy-auth-block policy, and document the exception.