Conditional Access for Canadian SMBs: The Control Insurers Expect

MFA stops most credential attacks. Conditional Access decides when MFA is required, which devices can connect, and what happens when something looks wrong. It is the control plane between a username/password and the data behind it. Most Canadian SMBs on Microsoft 365 have MFA. Far fewer have Conditional Access configured properly.

This piece covers what Conditional Access does, the baseline policies every SMB should have, the misconfigurations that show up in our M365 assessments, and why cyber insurance carriers and SOC 2 auditors are asking about it specifically.

What Conditional Access Is

Conditional Access (CA) is a Microsoft Entra ID feature that evaluates every sign-in attempt against rules you configure and then grants, blocks, or modifies access. The rules can reference who the user is, where they are signing in from, what device they are using, and how risky the sign-in looks to Microsoft's identity protection signals.

Without CA, MFA is a binary: either it is on or off. With CA, MFA becomes contextual: always on for admins, always on from outside Canada, always on for unmanaged devices. That contextual layer is what closes the gaps attackers exploit.

Licensing note: Conditional Access requires Entra ID P1 or higher, which is included in Business Premium and Microsoft 365 E3/E5. Most Canadian SMBs already pay for it and do not use it.

The Three Building Blocks

Every Conditional Access policy has three components:

1. Assignments. Who and what the policy applies to: users, groups, cloud apps, and conditions like location, device platform, sign-in risk, and user risk.
2. Access controls. What to do when the policy matches: grant access with controls (require MFA, require compliant device), block access, or apply session controls.
3. Session controls. What to do during the session: limit sign-in frequency, restrict downloads, enforce app-enforced restrictions.

The architectural mistake most SMBs make is starting with all users and trying to write one policy that covers every case. The cleaner approach: start with admins and the highest-risk scenarios, and add policies incrementally.

Baseline Policies Every SMB Should Have

Five baseline policies cover most Canadian SMB risk:

• Block legacy authentication (no exceptions)
• Require MFA for all users from untrusted networks
• Require MFA for all admin roles, always
• Require compliant or hybrid-joined devices for admin actions
• Block access from countries the business does not operate in

These five close the most-exploited paths. Each is covered below.

Block Legacy Authentication

Legacy authentication protocols (POP, IMAP, SMTP basic auth, older Outlook clients) cannot enforce MFA. They are the most common way attackers bypass MFA on Microsoft 365: they find one account that still uses an old protocol and brute-force it. Microsoft disabled legacy auth by default for new tenants in 2022, but existing tenants still allow it unless explicitly blocked.

The policy: block legacy authentication for all users, all apps, all conditions. The rollout: enable in report-only mode for two weeks, identify the few users or service accounts that still depend on it, migrate them to modern auth, then enforce.

This is the single highest-impact CA policy. If your tenant has not been audited for legacy auth in the last 12 months, our M365 assessment surfaces every account still using it.

Require MFA from Untrusted Networks

Many SMBs configure MFA but exempt the office network from the requirement. The reasoning is reasonable (less friction for staff in the office) and the implementation is usually wrong: the office IP gets listed as a "trusted location" and MFA is skipped entirely from that range.

The risk: if an attacker phishes a credential and then connects via your office VPN or compromised office device, they bypass MFA. The fix: do not exempt office locations from MFA. The slight inconvenience for staff is far outweighed by the risk reduction. If you want to reduce prompt frequency, configure sign-in frequency at 30 to 90 days on trusted devices instead of skipping MFA entirely.

Require Compliant Devices for Admins

Admin sign-ins should require both MFA and a compliant device (managed by Intune or hybrid-joined to Entra). This means an admin cannot sign in from their personal phone or laptop, even with the right MFA token. The control matters because the most valuable target in a Microsoft 365 tenant is the Global Admin, and attackers actively try to steal admin tokens through session hijacking on unmanaged devices.

The rollout: deploy Intune for the small set of devices admins use, mark them compliant, then enforce the CA policy. The friction is concentrated on the people who can absorb it.

Common Misconfigurations

The misconfigurations we see most often in M365 assessments:

• Break-glass account not excluded. Every CA policy should exclude a dedicated break-glass admin account so a policy mistake cannot lock you out of your own tenant. The account is monitored separately and used only in emergencies.
• Service accounts in the user pool. Service accounts cannot complete MFA and need different policies. They should use workload identity or app passwords with strict CA scoping, not regular MFA enforcement.
• Guest users not scoped. Default policies often skip guests, which means external collaborators sign in with weaker controls than your own staff. Apply the same MFA requirement to guests, with possible relaxation on sign-in frequency.
• Report-only mode left on. Policies in report-only mode log what they would have done but do not enforce. Many tenants have policies sitting in report-only for years.
• Location-based exemptions for unverified IP ranges. If a "trusted location" includes a CGNAT range or a coffee shop IP that was used once, MFA is effectively disabled from those addresses.

How It Maps to Insurance and SOC 2

Cyber insurance applications increasingly ask for evidence of MFA enforcement on privileged accounts and blocking of legacy authentication. CA is how you produce that evidence on Microsoft 365. The screenshot from the Entra portal showing your policies is the artifact carriers want to see, and the absence of CA policies often triggers follow-up questions or sub-limits.

SOC 2 is the same picture from a different angle. The Common Criteria around logical access (CC6.1, CC6.2, CC6.3) want documented controls that restrict access to authorized users on authorized devices. CA policies, properly scoped and reviewed, are how SOC 2 auditors verify that requirement on M365 environments. For the broader picture, see our SOC 2 readiness guide.

Getting Started

The right starting order is:

1. Create a break-glass admin account, document it, exclude it from all CA policies
2. Enable the legacy authentication block policy in report-only mode
3. Review the report-only results for 1 to 2 weeks, migrate any remaining apps to modern auth
4. Flip the legacy auth policy to enforce
5. Add the all-users MFA from untrusted networks policy
6. Add the admin-MFA-always policy
7. Add the compliant-device-for-admin policy after Intune is rolled out for admin devices
8. Add geo-blocking for countries you do not operate in

Most SMBs can complete this rollout in 4 to 8 weeks with a competent partner. The controls reference at our Microsoft 365 management guide covers the broader hardening picture, and our M365 service page covers what an engagement looks like.

Want to know where your tenant stands on Conditional Access, legacy auth, and MFA coverage? Our free cyber insurance readiness checker gives you a no-email-gate starting picture. A real M365 assessment produces the prioritized fix list.