MFA vs Conditional Access: what UK small businesses need to know

If you’ve enabled multi-factor authentication across Microsoft 365 and think you’re done, you’re only halfway there. MFA stops most password-based attacks, but it can’t decide whether the sign-in itself is safe. That’s the job of Conditional Access.

This guide explains the difference in plain English, why MFA alone isn’t enough for a growing UK business, and how to roll out Conditional Access without locking out your team. By the end you’ll know exactly what to turn on, in what order, and how to test changes safely.

In short: MFA proves who is signing in, while Conditional Access decides whether to allow that sign-in based on risk, so you want both, not one or the other. Here is the difference in plain English and what to turn on.

What MFA actually is

Multi-factor authentication is a verification step that proves the person signing in is actually the account holder. It adds something you have (a phone, a token) or something you are (a fingerprint, face) on top of something you know (a password). When MFA is on, a stolen password alone isn’t enough to compromise the account.

Microsoft’s own data shows MFA blocks roughly 99.9% of credential-based attacks. It is, by some distance, the single most important security control on a Microsoft 365 tenant. If you do nothing else this year, switch on MFA for every account that supports it.

What Conditional Access actually is

Conditional Access is the policy engine that lives one layer above MFA. It evaluates each sign-in attempt against a set of rules you define, then decides what to do.

A Conditional Access policy is essentially: “if signal A, signal B and signal C are true, then action X.” For example:

• If the team member is in the “Finance” group, AND signing in to SharePoint, AND from outside the UK, THEN block.
• If the team member is signing in to email, AND the device is non-compliant, THEN require MFA AND limit access to web-only.
• If the team member is an admin, AND the sign-in risk is medium or higher, THEN block until risk is remediated.

The signals it can evaluate include: the team member identity, the group memberships, the application being accessed, the device’s compliance status, the location (country, IP range, named location), the sign-in risk score from Entra ID Protection, the team member risk score, the time of day, and more.

Why MFA alone isn’t enough

MFA is great at blocking phishing where the attacker has only the password. But it doesn’t help in three increasingly common scenarios:

1. Token theft

If an attacker tricks the team member into completing the MFA challenge themselves (via a fake login page that proxies the real one), the attacker walks away with a valid session token. Future requests bypass MFA entirely. Conditional Access lets you require sessions to come from compliant devices, breaking this attack.

2. Legacy protocols

Old protocols like POP3, IMAP and SMTP-Auth don’t support modern MFA. If you have MFA enabled at the team member level but legacy auth is still allowed, attackers happily switch protocols. Conditional Access can block all legacy auth in one rule.

3. Suspicious location

If a team’s password is on the dark web and someone tries to sign in from Russia at 3am with the correct password, MFA still fires the prompt. The team member might not be paying attention and approve it. Conditional Access can block sign-ins from countries you never operate in, full stop.

The recommended Conditional Access baseline

Six policies cover the bulk of what UK SMBs need:

Policy 1: Require MFA for all staff

Targets: All staff. Cloud apps: All. Conditions: All client apps. Grant: Require MFA.

This is the foundation. Use this in place of per-person MFA.

Policy 2: Block legacy authentication

Targets: All staff. Cloud apps: All. Client apps: Exchange ActiveSync, Other clients. Grant: Block.

Most modern Outlook clients support modern auth. Anything still using legacy is either misconfigured or attacker traffic.

Policy 3: Require compliant device for SharePoint and OneDrive

Targets: All staff. Cloud apps: SharePoint, OneDrive. Grant: Require device to be marked as compliant. Combine with Intune.

This stops document access from random unmanaged personal computers.

Policy 4: Block sign-ins from outside the UK (with allowlist)

Targets: All staff (excluding break-glass admins). Cloud apps: All. Conditions: Locations = any location, exclude “United Kingdom” and any other countries you operate in. Grant: Block.

If you have travelling staff, allow specific countries or use named locations. Adjust as needed.

Policy 5: Stronger controls for admin accounts

Targets: Directory roles (Global Admin, Security Admin, etc.). Cloud apps: All. Grant: Require MFA + compliant device + sign-in frequency every 4 hours.

Policy 6: Block high-risk sign-ins

Targets: All staff. Conditions: Sign-in risk = High. Grant: Block.

Requires Entra ID P2 (included in Business Premium). Catches genuinely impossible scenarios like instant geographic travel.

The break-glass account, non-negotiable

“We’ve been locked out of our own tenant” is a story we hear roughly twice a year from new clients. Every single time, it’s because they enforced Conditional Access without a break-glass admin.

Before turning any policy on, create a “break-glass” admin account. It should:

• Have a long, randomly-generated password (40+ characters), stored offline (paper in a safe, not a password manager).
• Be a Global Admin.
• Be EXCLUDED from every Conditional Access policy you create.
• Have its sign-ins monitored (alerts when it’s used).
• Never be used for day-to-day work.

If a misconfigured policy locks out every other admin, this account gets you back in. Without it, you’d be on the phone to Microsoft support for hours.

How to roll out without breaking anything

1. Create the break-glass account first.
2. Create policies in “Report-only” mode. Conditional Access policies can run in a mode where they evaluate but don’t enforce. Watch the report for 1-2 weeks to see what would have been blocked.
3. Pilot with IT/admin staff first. Apply the policy to a small group, confirm everything works, then scale.
4. Communicate to staff before tenant-wide rollout. “From Monday, every sign-in will require MFA. Here’s how to set it up if you haven’t already.”
5. Have a rollback plan. Know which policy ID to disable if things go wrong.

Frequently asked questions

Initial IT deploys Conditional Access policies as the security baseline for every managed-IT client. We handle break-glass setup, staged rollout and ongoing tuning across Lichfield, Staffordshire and the West Midlands.