TL;DR:
- Conditional Access in Microsoft 365 (now part of Entra ID) enforces security requirements at login: require MFA, block legacy protocols, restrict access to managed devices
- You need Microsoft 365 Business Premium, or an Entra ID P1 add-on, to use Conditional Access — it’s not available on the cheaper Microsoft 365 Business Basic or Standard licences
- Turning on three policies — require MFA for all users, block legacy authentication, and require MFA for admin roles — addresses the majority of credential-based attack risk in most SME environments
Most credential-based attacks on small business Microsoft 365 tenants succeed not because the attacker is sophisticated, but because basic controls aren’t in place. Password spray attacks work when users have weak passwords and no MFA. Legacy authentication bypasses MFA entirely. Compromised admin accounts cause disproportionate damage. Conditional Access is the Microsoft 365 feature that addresses all three, and it’s underused in the SME market.
The reason it’s underused isn’t mysterious. The Microsoft 365 admin centre is large and confusing, the feature is buried behind licencing requirements that aren’t obvious, and “Conditional Access” is a name that sounds like enterprise infrastructure when it’s actually a set of rules like “require MFA when logging in from outside the office.”
This guide is about the practical version of Conditional Access for UK small businesses: what it does, whether you’re licenced for it, and which policies to actually turn on.
What Conditional Access Does
Conditional Access is a rule engine that sits between your users and Microsoft 365. Every time someone signs in, it evaluates their sign-in against the policies you’ve defined and decides whether to allow the sign-in, require additional verification, or block it.
The conditions you can check include: which user is signing in, which application they’re accessing, what device they’re on, where they’re signing in from, and how risky the sign-in looks. The controls you can enforce include: requiring MFA, requiring the device to be enrolled in Intune, blocking legacy authentication clients, and blocking the sign-in entirely.
Without Conditional Access, Microsoft 365 has only the most basic access control: a username and password. With Conditional Access, you can require MFA for specific apps, block any authentication method that doesn’t support MFA, and restrict access to corporate devices.
Licencing: What You Actually Need
Conditional Access requires either:
- Microsoft 365 Business Premium (the highest SME tier, around £19.70/user/month as of 2026)
- Entra ID P1 as an add-on to a lower-tier Microsoft 365 licence (around £4.70/user/month to add to Business Basic or Standard)
Microsoft 365 Business Basic and Business Standard do not include Conditional Access. If you’re on those tiers and want Conditional Access, you need to either upgrade or buy the add-on per user.
There’s a partial alternative: Microsoft 365 Security Defaults. This is free for all tenants and enforces a preset collection of policies including MFA for all users. If you’re not yet on a Business Premium licence, Security Defaults is better than nothing. The limitation is that Security Defaults is all-or-nothing — you can’t customise the policies, add exceptions, or integrate it with more specific controls. Conditional Access gives you full control.
Check before you proceed: In the Microsoft 365 admin centre, go to Entra ID (Azure Active Directory) and look for the Conditional Access section. If you can see and create policies there, your licence includes it. If you see an upgrade prompt, you’re on a tier that doesn’t include it.
The Three Policies to Turn On First
1. Require MFA for All Users
This is the single most effective security control available in Microsoft 365. It requires every user to complete a second authentication factor on every new sign-in — typically Microsoft Authenticator on their phone.
Create a Conditional Access policy:
- Users: All users
- Cloud apps: All cloud apps
- Conditions: none (applies everywhere)
- Grant: Require multi-factor authentication
Before turning this on in enforcement mode, run it in Report-only mode for a week. This shows you what sign-ins would be affected without blocking anyone. Look for any service accounts or automation that’s authenticating as users — those need to be switched to service principals before MFA enforcement goes live, because they’ll break.
Exclude your break-glass emergency admin account from this policy. If MFA fails and you’re locked out, you need a way back in.
2. Block Legacy Authentication
Legacy authentication refers to older authentication protocols — Basic Authentication in Exchange, older versions of SMTP/POP3/IMAP clients — that don’t support MFA at all. If legacy auth is enabled, an attacker who gets a password can log in without ever being prompted for MFA, regardless of what your MFA policies say.
Create a policy:
- Users: All users
- Cloud apps: All cloud apps
- Conditions: Client apps — select “Exchange ActiveSync clients” and “Other clients” (these are the legacy auth categories)
- Grant: Block access
This will break any email client that’s still using Basic Auth — old versions of Outlook, some phones configured years ago with IMAP/POP3 settings, third-party integrations using deprecated APIs. Most organisations have a few of these. Again, run in Report-only mode first to find them before enforcement.
3. Require MFA for Admin Roles
Privileged accounts — Global Administrator, Exchange Administrator, SharePoint Administrator — are high-value targets. If an attacker compromises a regular user account, they get access to that user’s data. If they compromise a Global Admin account, they get access to everything, including the ability to create new accounts, modify MFA settings, and exfiltrate email from every user.
Create a separate policy targeting directory roles:
- Users: Directory roles — Global Administrator and any other admin roles you use
- Cloud apps: All cloud apps
- Grant: Require MFA
This gives you enforced MFA on admin accounts even if your main MFA policy has exceptions or is being phased in.
Named Locations: Trusting Your Office
Once MFA is running, you may find that users signing in from the office every day find the repeated MFA prompts disruptive. You can configure a Named Location for your office IP address and create a policy that reduces MFA frequency for trusted locations.
In the Entra ID portal, add your office’s public IP address as a Named Location. Then modify your MFA policy to exclude that location, or configure the session control to allow persistent browser sessions from trusted locations.
Be careful here. Named Locations by IP address mean that anyone connecting from that IP — including a visitor on your Wi-Fi — looks like a trusted location. Consider whether your office network is appropriately secured before using location exclusions.
What to Monitor
Once Conditional Access policies are live, the Entra ID Sign-in logs become genuinely useful. Filter for “Interrupted” or “Failure” sign-ins to see what’s being blocked. A spike in blocked legacy auth sign-ins often indicates an active credential stuffing attack against your tenant.
The Risky sign-ins report (in Entra ID under Protection) shows sign-ins that Microsoft’s threat intelligence has flagged as suspicious. Conditional Access policies can automatically require MFA or block these sign-ins without you reviewing each one — that’s an Entra ID P2 feature, but for lower-tier licences, the report alone gives you visibility.
Common Mistakes
Turning on policies without testing: Always use Report-only mode first. The number of things that break when legacy auth is blocked is consistently surprising.
Forgetting service accounts: Automation, backup tools, and third-party SaaS integrations often authenticate to Microsoft 365 as user accounts using stored passwords. These break with MFA enforcement. Switch them to app registrations with client credentials before enabling MFA.
Single admin account without a break-glass alternative: If your only Global Admin account gets MFA-locked or the MFA method becomes unavailable, you need another way in. Create a break-glass account with a very strong password, exclude it from Conditional Access policies, store the credentials securely offline, and use it only in emergencies.