A practical deployment guide for Canadian small businesses on Microsoft 365 Business Premium — covering the five baseline policies, rollout strategy that avoids lockouts, and recovery steps when things go wrong.
A password and MFA code protect you at the moment of login — but not after. An attacker who steals a session token, authenticates from an unfamiliar country, or logs in from a personal device may bypass that login challenge entirely. Conditional Access evaluates the context of every sign-in — who is signing in, where they are, what device they are using, and how risky the session looks — and applies a policy decision in real time.
For small businesses, Conditional Access is not an enterprise luxury. It is the control that stops a stolen Microsoft 365 password from turning into a mailbox takeover, and it is now a requirement for most Canadian cyber insurance policies. This guide stays focused on deploying a safe, practical SMB baseline. For the surrounding identity and email controls, branch into the Microsoft 365 Security Checklist or the Phishing Protection guide.
Conditional Access requires Microsoft 365 Business Premium or a standalone Microsoft Entra ID P1 licence. Business Standard does not include Conditional Access — if you are on Standard, your equivalent option is Security Defaults (free, included in every M365 plan), which enforces MFA and blocks legacy auth without granular control. The Business Premium upgrade unlocks Conditional Access, Microsoft Defender for Business, and Intune — making it worth the cost for most businesses managing security seriously.
Security Defaults and Conditional Access are mutually exclusive. Microsoft will not enforce CA policies while Security Defaults is enabled. You must disable Security Defaults before creating Conditional Access policies — but do not disable it until you are ready to enable your CA policies immediately afterward, or you will have a gap in MFA enforcement.
This is the single most important step in this guide. A break-glass account is a dedicated Global Administrator account that is intentionally excluded from every Conditional Access policy. Its only job is emergency recovery: if a misconfigured CA policy locks every other admin out of the tenant, the break-glass account is your way back in.
Without a break-glass account, a single policy mistake can make your tenant unrecoverable without calling Microsoft Support — a process that can take days.
breakglass@yourdomain.com. Assign Global Administrator. Use a strong, randomly generated password — 40+ characters, stored securely offline.Track your baseline deployment progress. Your state is saved locally in this browser.
Each Conditional Access policy has three components: Assignments (who the policy applies to and under what conditions), Target resources (which apps are affected), and Grant controls (what happens — allow, require MFA, require compliant device, or block). Policies stack: if a sign-in matches multiple policies, the most restrictive grant applies.
Who the policy targets: all users, specific groups, or directory roles. Includes and excludes. Also covers conditions: location, device platform, client app type, sign-in risk.
Which cloud apps the policy applies to. "All cloud apps" covers everything including Microsoft 365, Teams, SharePoint, and any OAuth-connected apps. You can also scope to specific apps like Exchange Online only.
What happens: Grant access (optionally requiring MFA, compliant device, or approved app), or Block access entirely. Session controls can layer on top — sign-in frequency, app-enforced restrictions.
Report-only mode is a native CA feature: set it during policy creation and the policy evaluates sign-ins and records what it would have done — but does not enforce anything. Sign-in logs in Microsoft Entra admin centre show the report-only results. Use it before every policy enforcement.
These five policies cover the exposure profile of most Canadian small businesses. Policies 1–4 can be deployed without Intune. Policy 5 is an optional second-tier control for tenants that have completed Intune enrollment.
Enforces multi-factor authentication for every sign-in across the tenant. The highest-impact single policy you can deploy — blocks the overwhelming majority of automated credential attacks.
Blocks IMAP, POP3, and basic auth protocols that cannot enforce MFA — eliminating the side door that makes MFA irrelevant when credentials are stolen.
Forces MFA on every admin session without persistent session tokens. Admins control the entire tenant — they are the highest-value target and should never be remembered.
Restricts access to countries your business actually operates in. Most Canadian SMBs have zero legitimate sign-in traffic from the regions attackers most commonly use.
Restricts tenant access to devices enrolled in Intune or joined to your domain. Prevents sign-ins from unknown personal devices entirely.
The single most common Conditional Access failure mode: switching a policy directly from disabled to On for All users, then spending the morning fielding calls from locked-out staff. A three-phase rollout takes an extra two weeks and prevents that entirely.
Microsoft Entra admin centre includes a built-in policy simulator called What If. Navigate to Protection → Conditional Access → What If. Enter a user, an app, a location, and other conditions — the tool shows exactly which policies would apply and what the result would be. Run it before enforcing any policy and after making changes.
Sign-in logs live in Microsoft Entra admin centre → Monitoring → Sign-in logs. Filter by Conditional Access status — look for Failure and Not applied entries. A Failure may indicate a misconfigured policy catching an unintended account. A Not applied entry means no policy matched — check whether that account should be covered. Review logs daily for the first week after full enforcement.
If you cannot sign in with any admin account: retrieve the break-glass account credentials and FIDO2 key from their secure storage location. Sign in at entra.microsoft.com or portal.azure.com directly. Once in, you can disable or modify any policy that caused the lockout.
If a single user — not an admin — is blocked by a policy: sign in as an admin, navigate to Microsoft Entra admin centre → Users, locate the account, and review which policies are applying via the sign-in logs for that user. Add them temporarily to an exclusion group to restore access while you investigate, then resolve the underlying cause and remove the exclusion.
Most Conditional Access lockouts and policy failures follow the same patterns. Recognizing them before deployment is considerably cheaper than diagnosing them after.
If your break-glass account is caught by a Require MFA policy and the associated MFA device is unavailable, you lose all administrative access to the tenant with no recovery path. Create the break-glass exclusion group as the very first step — before writing any policy.
Security Defaults and Conditional Access are mutually exclusive. Microsoft will not enforce CA policies while Security Defaults is active, and running both produces unpredictable behaviour. Disable Security Defaults first, then create your CA policies — do not leave a gap between disabling and enforcing.
A location-based block set to "all countries except Canada" will lock out any employee travelling internationally, working from a US satellite office, or using a VPN with a non-Canadian exit node. Define named locations deliberately before enforcing, and update the list before travel happens — not after a lockout.
The most common lockout scenario: enabling a block policy against All users without first running report-only. Sign-in logs surface exceptions you did not know existed — shared mailboxes, CRM integrations, old printers using basic SMTP. Two weeks of observation prevents a Monday morning outage.
Always exclude at minimum your break-glass group. Decide upfront whether service accounts, guest users, and BYOD-approved accounts need separate treatment. Policies that catch unintended accounts are the leading cause of post-deployment help desk spikes.
Policy 5 will immediately block any user whose device is not enrolled in Intune. Only enable it after every company device is enrolled, marked compliant, and verified in the portal. Run an extra week in report-only before enforcing to confirm coverage is accurate.
Conditional Access is the identity enforcement layer — it is not a complete security posture on its own. It works best when the surrounding controls are also in place.
Conditional Access is manageable in-house for most small businesses — but a few situations benefit from professional review before you enforce anything.