Conditional Access is the part of Microsoft 365 security that decides what happens the moment someone tries to sign in. The password is correct, but should this person actually get in right now, from this device, in this location, to this app? That question is what Conditional Access answers, and it’s the difference between “we turned on MFA” and “we control how access actually works.”
A lot of admins meet Conditional Access through a single goal: force MFA. That works, but it sells the feature short and it’s easy to build a policy that locks out the wrong people. This guide walks through what Conditional Access really is, the pieces it’s built from, the handful of policies most tenants should run, and the safety habits — report-only mode and break-glass accounts — that keep you from locking yourself out.
Where Conditional Access sits in the sign-in
Conditional Access lives in Entra ID (the identity service formerly called Azure AD). It runs after the first authentication factor is verified and before access to the app is granted. So the password check happens first, then Conditional Access evaluates the sign-in and decides the outcome: allow it, allow it with extra requirements, or block it.
The mental model is a simple sentence: when these conditions are true, require these controls. Everything in a policy is either an “if” (an assignment or condition) or a “then” (an access control). Get that split clear in your head and the whole interface stops feeling random.
The building blocks: signals, conditions, and controls
Every policy is assembled from three groups of settings. Learn these and you can read or write any policy.
Assignments — who and what the policy targets
This is the scope. You pick the users or groups the policy applies to (and, just as important, who’s excluded), and the cloud apps or actions it covers — all apps, or specific ones like Exchange Online or SharePoint.
Conditions — the signals that refine when it fires
Signals narrow the policy further. The common ones:
- Sign-in risk / user risk — Entra’s assessment of whether this sign-in or account looks compromised (requires P2).
- Device platform — Windows, macOS, iOS, Android.
- Locations — named IP ranges or countries, often used to define “trusted” networks.
- Client apps — browser, mobile/desktop apps, or legacy authentication clients.
- Device state / filters — whether the device is compliant or Entra-joined.
Access controls — what happens when the conditions match
Controls are the “then.” Grant controls can block access outright, or allow it while requiring one or more things: MFA, a compliant device, a Hybrid Entra-joined device, an approved client app, or a password change. When you require several, you choose whether the user needs all of them or any one. Session controls go further — limiting what happens inside the session, like forcing a shorter sign-in frequency or app-enforced restrictions.
The three parts of every Conditional Access policy
| Assignments | Which users/groups and which apps the policy applies to (plus exclusions) |
|---|---|
| Conditions | Signals that refine when it fires: risk, device platform, location, client app |
| Access controls | The outcome: block, or grant with MFA / compliant device / approved app |
The policies most tenants should run
You don’t need dozens of policies. A small, well-targeted set covers the majority of real risk. Here are the ones worth building first.
Require MFA for all users
The baseline. Target all users, all cloud apps, grant access but require MFA. This is the policy people mean when they say “we turned on MFA,” but doing it through Conditional Access instead of Security Defaults lets you add the exclusions and exceptions you’ll inevitably need.
Block legacy authentication
Legacy protocols — IMAP, POP, SMTP AUTH, older Office clients — can’t do MFA. Attackers lean on them precisely because they sidestep your MFA policy during password-spray campaigns. A policy that blocks legacy auth for all users closes that hole. Before you enforce it, check the sign-in logs filtered to legacy clients so you know what (if anything) still depends on it.
Require a compliant or Hybrid-joined device for sensitive apps
When you want to make sure only managed machines reach certain data, require a device that’s marked compliant in Intune or Hybrid Entra-joined. This is how you stop someone pulling company SharePoint down to an unmanaged personal laptop.
Require MFA for risky sign-ins (P2)
If you have Entra ID P2, add risk-based policies: require MFA when sign-in risk is medium or high, and require a secure password change when user risk is high. These react to Entra’s own detections rather than static rules.
Report-only mode: test before you enforce
The single most useful habit in Conditional Access is creating every new policy in report-only mode first. In this state the policy is fully evaluated against real sign-ins and the result is logged — but nothing is actually enforced. Nobody gets blocked, nobody gets an unexpected MFA prompt.
You let it run for a few days, then review the sign-in logs. Each sign-in shows what the report-only policy would have done. If it would have blocked your service accounts or hit an app you didn’t intend, you fix the scope before any user feels it. Only when the report-only results look clean do you flip the policy to On.
Rolling out a new Conditional Access policy safely
- Build the policy in report-only mode, not On
- Confirm your break-glass accounts are excluded
- Let it run against real sign-ins for several days
- Review the sign-in logs and check the report-only result column
- Look for unintended targets: service accounts, scanners, line-of-business apps
- Narrow the scope or add exclusions as needed
- Switch to On only after the report-only data looks clean
Break-glass accounts: don’t lock yourself out
Conditional Access can absolutely lock you out. A policy that requires a compliant device, an MFA provider outage, or a typo in an “all users” assignment can leave every admin staring at a sign-in screen they can’t pass. Break-glass accounts are the answer.
A break-glass (emergency access) account is a cloud-only global administrator that is excluded from every Conditional Access policy and from MFA. The standard practice:
- Create two of them, so a single account issue can’t strand you.
- Use long, randomly generated passwords stored offline in a sealed, controlled location.
- Exclude them from all Conditional Access policies — every single one.
- Don’t tie them to any individual person’s phone or token.
- Set up an alert that fires whenever a break-glass account signs in, since legitimate use should be rare.
Licensing: P1 vs P2 vs Security Defaults
Conditional Access isn’t in every plan, and the risk-based features cost more. Knowing the tiers keeps you from designing a policy you can’t license.
What you need for Conditional Access
| Security Defaults | Free. All-or-nothing MFA + legacy auth block. No customization, no exclusions. |
|---|---|
| Entra ID P1 | Full Conditional Access: targeting, device and location conditions, grant/session controls. Included in Business Premium, E3. |
| Entra ID P2 | Adds risk-based policies (sign-in risk, user risk) and Identity Protection. Included in E5. |
If you’re on a plan without P1, Security Defaults is a reasonable starting point — it’s far better than nothing. But the moment you need an exception (a service account that can’t do MFA, a trusted location, an app that needs tighter rules), you’ve outgrown Security Defaults and need P1.
How a sign-in is actually evaluated
When multiple policies apply to one sign-in, Entra evaluates all of them and combines the results. Two rules matter most:
- Block wins. If any applicable policy says block, the sign-in is blocked, regardless of what other policies would grant.
- All grant requirements must be satisfied. If one policy requires MFA and another requires a compliant device, the user has to meet both.
This is why scoping and exclusions matter so much. A broad block policy with a missing exclusion overrides everything else. It’s also why report-only mode is the right place to discover that two policies overlap in a way you didn’t expect.
Putting it together
Conditional Access is the control point where Microsoft 365 decides whether a verified user actually gets in. Build it from the three blocks — assignments, conditions, controls — start with a short list of high-value policies (require MFA, block legacy auth, require compliant devices for sensitive apps), and lean on risk-based policies if you have P2. Above all, create every policy in report-only mode and keep two break-glass accounts excluded from everything. Those two habits prevent almost every self-inflicted lockout.
Conditional Access pairs naturally with the rest of your identity hardening. If you haven’t yet, start by enabling MFA for your Microsoft 365 users, and once your sign-in policies are solid, tighten data movement with controls like stopping auto-forwarding of email. For a layered view of email threats specifically, our guide on protecting Microsoft 365 from phishing shows where Conditional Access fits alongside Defender.
