Conditional Access is one of those Microsoft 365 features that gets mentioned a lot in security conversations but rarely gets explained clearly. Most IT documentation describes it in terms of its technical components — conditions, controls, policies — without really explaining what problem it's solving or why it matters in practice.
Having configured Conditional Access policies across hundreds of tenants, here's how I explain it to clients.
The Basic Idea
Traditional network security worked on the assumption that if you're inside the office network, you're trusted. If you're outside, you're not. That model collapsed when cloud services and remote working became the norm — users now access Microsoft 365 from their homes, hotels, airports, personal devices, and everywhere else. The network perimeter essentially disappeared.
Conditional Access is Microsoft's answer to this. Instead of deciding access based on where you are on the network, it decides access based on a set of conditions evaluated at sign-in time. Think of it as a smart security guard who checks not just your ID card, but also where you're logging in from, what device you're using, what application you're trying to access, and whether anything looks unusual about the attempt. Depending on what they find, they either let you in, ask for additional verification, or block you entirely.
What Can It Check?
A Conditional Access policy evaluates several things at sign-in:
- Who is signing in — specific users, groups, or roles like Global Administrator or Exchange Administrator
- What application they're accessing — all apps, specific apps like SharePoint or Exchange, or a custom selection
- Where they're signing in from — specific named locations (like your office IP ranges), countries, or any location outside of trusted ones
- What device they're using — whether it's compliant with Intune policies, whether it's a domain-joined machine, what operating system it's running
- What client app they're using — modern browser, desktop app, or legacy protocols like basic authentication
- How risky the sign-in looks — Microsoft's risk scoring flags unusual patterns like impossible travel (logging in from London and then Sydney an hour later) or sign-ins from known malicious IPs
What Can It Do When Conditions Are Met?
Based on those conditions, a Conditional Access policy can take one of several actions. It can grant access normally with no additional requirements. It can require MFA — the user has to pass a second factor before proceeding. It can require the device to be compliant (enrolled in Intune and meeting your security policies). It can require a hybrid Azure AD joined device — meaning a corporate machine that's domain-joined. Or it can block access entirely.
The power is in combining conditions and controls. For example: require MFA for all users, but require a compliant device for anyone trying to access SharePoint. Block access from countries you don't operate in. Allow access from the office without MFA, but require MFA for remote access. Require stronger authentication (like a hardware key or Windows Hello) for admin accounts.
Common Policies Worth Having
Most organisations should have at least these baseline policies in place:
- Require MFA for all users — the single highest-impact security control available in Microsoft 365
- Require MFA for all admins — separate policy with stronger requirements, since admin accounts are the highest-value targets
- Block legacy authentication — prevents attackers from bypassing MFA by using older protocols
- Block access from high-risk sign-ins — automatically blocks sign-ins that Microsoft's risk scoring flags as likely compromised
Before enabling any Conditional Access policy: Always test in report-only mode first, and make sure you have a break-glass admin account excluded from your policies. A misconfigured policy blocking all admins is a serious situation to recover from.
Why Most Organisations Get It Wrong
The most common problem I see is organisations that have Conditional Access policies configured but haven't thought carefully about the exclusions. Every policy needs to exclude the break-glass admin account. Policies requiring compliant devices need to account for users who legitimately use personal devices. Policies blocking certain countries need to account for users who travel.
The second most common problem is having too many overlapping policies that interact in unexpected ways. When multiple policies apply to the same user, all of them have to be satisfied — which can create situations where a user is effectively blocked even though no individual policy was intended to block them.
The third is policies left in report-only mode long after they should have been enabled. Report-only mode is useful for testing but doesn't actually enforce anything — it just logs what would have happened. I've seen tenants with "require MFA" policies that have been in report-only mode for over a year.
🛡️ The CA Policy Explainer lets you paste a raw Conditional Access policy JSON and get a plain English explanation of exactly what it does — who it applies to, what it checks, and what it requires.
Open CA Policy Explainer →🔐 The M365 Security Scanner checks your tenant's Conditional Access policies and flags common gaps — missing MFA enforcement, legacy auth still enabled, admin accounts without stronger requirements.
Open M365 Security Scanner →