Conditional Access in Microsoft Entra: the if-then engine that decides who gets in

A correct password used to mean "you're in." That assumption is how accounts get breached. Conditional Access replaces it with a question: given who you are, where you are, and what you are signing in from — should you get in, and on what terms? This is the engine, the rollout that doesn't lock you out, and the two policies that finish the job.

New to cloud? CAMPUX is a free, build-first course. Start here →

Conditional Access is Microsoft Entra ID's policy engine: it evaluates every sign-in against if-then rules — who is signing in, from where, on what device, into which app — and then allows the sign-in, blocks it, or demands more proof such as MFA or a compliant device. The part most guides skip: how the engine decides when several policies apply at once, which is exactly where people lock themselves out.

In a cloud world the network perimeter is gone and identity is the real front line. Conditional Access is the control that makes identity do that job — Microsoft calls it "Microsoft's Zero Trust policy engine," which "brings signals together, to make decisions, and enforce organizational policies." It sits between a successful sign-in and the resource, weighs the context, and decides whether to wave you through, block you, or ask for more proof. That is Zero Trust in one sentence: never assume the network vouches for anyone, verify every request explicitly.

It is an if-then statement

Strip away the enterprise language and a Conditional Access policy is a rule you already understand. The docs put it plainly: policies "at their simplest are if-then statements." If a user wants to reach a resource, then they must satisfy a condition — for example, if someone opens a sensitive app, then they must complete multifactor authentication. That is the entire mental model. Everything else is richer ifs and stronger thens.

What Conditional Access does

Two halves: the signals it reads, and the actions it can take. On the signal side, the "if", a policy can weigh:

• User or group — target policies at specific people or roles, so admins get stricter rules.
• Location — named locations you define: trusted office IP ranges, or whole countries you allow or block.
• Device state — the platform, and whether the device is compliant in Intune or Entra-joined.
• Application — different rules for different apps; the Azure management plane can be stricter than webmail.
• Real-time risk — signals from Entra ID Protection flagging a risky sign-in or user, which needs a P2 licence.

On the action side, the "then", the extremes are block access and grant access, but the interesting middle is grant, with conditions: require multifactor authentication, require the device to be marked compliant or Entra hybrid joined, require an approved client app or app-protection policy, require a password change or acceptance of terms of use, or apply session controls that keep the sign-in but limit it — shorter sign-in frequency, no persistent browser sessions, or app-enforced restrictions such as blocking downloads on unmanaged devices.

Because it combines these, you can express nuance a flat rule cannot. "An admin, from an unmanaged device, in a new country" is a very different request from "a regular user, on a compliant laptop, in the office." Note what it does not do: it does not decide what you can touch once inside. That is authorization, and in Azure it belongs to RBAC, the subject of Class 8 — RBAC and Azure Policy.

A password says who you claim to be. Conditional Access asks whether — given everything else — that claim is good enough to let you in right now.

How the policy engine evaluates policies

This is the part almost nobody explains plainly, and it is where real lockouts come from. Once you have more than one policy, and every real tenant does, you need the evaluation rules in your head.

• Every matching policy is evaluated, on every sign-in. There is no ordering, no priority number, no first-match-wins. If a sign-in falls in scope of five enabled policies, all five apply. You cannot put one policy above another to override it.
• Block wins over everything. If any matching policy says block, the sign-in is blocked and no other policy's grant can rescue it. This is why a broad block policy with a typo in its scope takes a whole tenant down.
• Grant controls combine. When several policies grant with conditions, the user must satisfy the controls from all of them. Within a single policy you choose whether its own controls combine with AND ("require all the selected controls") or OR ("require one of the selected controls"), but across policies it is effectively AND.
• Exclusions beat inclusions. If a user is both included, say via "All users", and excluded via a break-glass group, the exclusion wins. That is the mechanism that keeps emergency accounts reachable, and also the quiet way policies get holes punched in them, so audit your exclusion groups.
• Report-only mode evaluates but never enforces. A report-only policy runs through the same engine and writes its would-have-been outcome to the logs without affecting anyone. It is the safe way to see a policy's blast radius before turning it on.

The MFA decisions that actually change your risk

"Turn on MFA" is where most guidance stops and most breaches slip through. MFA is the single most effective control in Entra ID — it stops the overwhelming majority of account takeovers, which almost all begin with a stolen or sprayed password — but "enabled" and "effective" are different states. The space between them is where real incidents live: the admin protected by SMS who got SIM-swapped, the mailbox reached over IMAP that never saw a prompt, the user who tapped Approve on an attacker's tenth push at midnight.

Enforce through Conditional Access, not per-user MFA

Entra has three ways to require MFA and only one is the modern answer. Per-user MFA is the oldest, a per-account on/off flag with no context; Microsoft steers you off it and you should not build anything new there. Security defaults is a free, all-or-nothing baseline that is genuinely respectable for a small tenant without P1 — it pushes MFA registration and blocks legacy authentication, which is most of the risk reduction. Conditional Access is the standard for everyone else, and it requires Entra ID P1.

Prefer phishing-resistant methods and demote SMS

Not all second factors are equal, so rank them and require the strong ones where the stakes are highest.

Use authentication strengths in Conditional Access to require a phishing-resistant method for administrators rather than merely allowing it. SMS should be a break-in-case-of-emergency fallback, never the primary factor on a privileged account. Alongside that, keep number matching on: instead of a tap-to-approve push, the user types a number shown on the sign-in screen into Authenticator. Because the number only appears on the genuine sign-in page, an attacker's push cannot be approved, which is what defeats MFA-fatigue spamming. It is on by default now.

Two operational habits close the loop. Run the Authenticator registration campaign to nudge users off SMS onto the app before you tighten policy, so enforcement day is not a helpdesk flood. And with P2, turn on Identity Protection risk policies so a risky sign-in triggers a step-up or block automatically. Pair privileged-role MFA with Privileged Identity Management so admin rights are elevated just in time rather than standing, which shrinks the window in which an unprotected admin session is even useful.

The rollout that doesn't lock you out

Everyone in identity has heard the story: an admin turns on a tenant-wide MFA policy at 5pm, forgets to exclude anyone, and locks the whole company out of Microsoft 365 including themselves. The order of operations below is what makes that story impossible to tell about you. The baseline policy is deliberately boring; the sequence is the part that matters.

Step 1: break-glass accounts, before anything else

Before you create your first policy, create two emergency access accounts. Not one — two, in case one is broken for a reason you have not discovered. Each requirement has a reason behind it.

• Cloud-only. Created directly in Entra with a *.onmicrosoft.com UPN, not synced from on-premises Active Directory. If your sync breaks or your federation provider has an outage, a synced account goes down with it. The point of this account is that it works when everything else does not.
• Excluded from every Conditional Access policy, including the ones you write next year. The cleanest way to keep that honest is a dedicated security group, something like CA-Exclude-BreakGlass, added to the exclusions of every policy as a matter of habit.
• Long random passwords, stored offline. A generated passphrase split across sealed envelopes in a safe, or whatever physically secured arrangement your organization can actually operate. Not in the password manager that requires the sign-in you might be locked out of.
• Alerts on every sign-in. These accounts should sign in close to never, so wire an alert that pages a human on any authentication. An unmonitored break-glass account is just a privileged account with a weak process around it.
• Global Administrator, tested quarterly. An emergency account you have never signed in with is a hope, not a control.

Microsoft's documentation on emergency access accounts covers the same ground in more depth. Nobody skips this step twice.

Step 2: the baseline policy, boring on purpose

Resist the urge to be clever. Every scoping decision — "just Office apps for now", "just the finance department" — is a gap an attacker does not have to respect and a future you has to remember. The strength of all users, all resources is that there is nothing to forget. The exclusions are where the judgment lives.

The service account problem, honestly

Most guides wave past this. Real tenants have accounts that are not people: a user account a scanner binds with, a mailbox a legacy app authenticates into, a vendor integration someone set up in 2019. These cannot answer an MFA prompt, and the moment your policy goes live they start failing, usually at 2am and usually attached to something the business cares about.

The uncomfortable truth is that user-style service accounts are a real problem that policy alone does not solve. Excluding them from MFA leaves password-only accounts sitting in your tenant, which is exactly what attackers hunt for. The honest hierarchy of fixes, best to worst:

1. Stop using a user account at all. If the workload runs in Azure, a managed identity removes the credential entirely; if it cannot, a service principal with a certificate is next best. Microsoft makes the same recommendation, and there is a structural reason it works: calls made by service principals are not blocked by Conditional Access policies scoped to users. Workload identities have their own policy type, which carries separate licensing. See managed identity vs service principal.
2. If a user-style account must stay, exclude it from the MFA policy but compensate: a long random password, a separate policy restricting it to known egress IPs, and monitoring on its sign-ins. That is a mitigation, not a solution, and it deserves a follow-up ticket rather than a shrug.
3. What you should not do is quietly exclude a broad "IT stuff" group and move on. Every exclusion is an attack path; keep the list short, named and reviewed.

Step 3: report-only mode, and actually reading it

Report-only is the single best lockout-prevention feature in the product. The policy evaluates on every sign-in and records what it would have done without doing any of it. Set the baseline to report-only and leave it about a week, long enough to catch the weekly rhythms — the Monday-morning sync job, the Friday payroll run. Then open the Entra sign-in logs, read the Report-only tab on individual entries, or use the Conditional Access insights workbook for the aggregate. You are looking for one thing: sign-ins that would have failed that you did not expect.

Every tenant I have watched go through this finds something. An app in a forgotten office authenticating like it is 2015. A conference-room device on a shared account nobody documented. A vendor integration on basic auth. When the report-only week is quiet, or every noisy line has an explanation and a decision, flip the policy to On — mid-morning on a normal weekday, with the helpdesk warned and watching, not at 5pm on a Friday.

Report-only mode is how you meet your tenant's skeletons on your own terms, instead of meeting them as an outage.

Block legacy authentication, or the rest does not matter

This is the policy people skip, and it silently voids everything above. Legacy authentication is any sign-in over a protocol that cannot do modern auth: basic authentication on IMAP, POP, SMTP AUTH, MAPI, older Office clients and older Exchange ActiveSync. Those protocols cannot perform MFA at all. A password is the entire conversation, so an attacker with a valid password signs in over one of them and is never prompted.

This is not a theoretical gap. Microsoft's own analysis puts it starkly: more than 97 percent of credential-stuffing attacks and more than 99 percent of password-spray attacks use legacy authentication protocols. Those attacks would stop with basic authentication disabled or blocked. Password spray does not bother with your shiny modern login; it aims straight at the legacy endpoints. MFA everywhere, minus one protocol, equals no MFA for an attacker who knows to use that protocol.

Audit before you enforce. In the sign-in logs, add the Client App column, filter on the legacy authentication protocols, and do it on the non-interactive sign-ins tab too, which is where most of this traffic hides. Microsoft also ships a Sign-ins using legacy authentication workbook for triage. This is the policy most likely to surface an ancient scanner or a printer that emails scans over SMTP, so find those first and migrate them.

One sequencing note that catches people moving off security defaults: the defaults were blocking legacy authentication for you. Turn them off, ship only an MFA policy, and you have quietly become less secure than you were. This policy is how you re-create that protection deliberately. And if you have no licence for Conditional Access, security defaults remain the supported way to block legacy auth.

Refinements that earn their place

Require compliant devices for admins. An admin session is worth more than a user session, so it can carry more requirements. If you run Intune, a policy requiring privileged roles to sign in from a compliant or hybrid-joined device means a phished admin credential is not enough by itself; the attacker also needs a managed machine. Scope it to the directory-role level, exclude break-glass, and run report-only first, because getting device compliance wrong for admins is a lockout with extra steps.

Named locations, useful but weaker than they look. Named locations let you tag IP ranges — your offices, your VPN egress — and use them as conditions. Be clear-eyed about what an IP proves: that traffic came from a network, not that a trustworthy human sent it. Attackers rent residential proxies in your country for pennies, and "trusted location, skip MFA" quietly turns your office LAN into an MFA bypass for anyone with a foothold on it. Use locations to add friction — block countries you never operate from, restrict service accounts — rather than to remove it.

Microsoft is enforcing some of this whether you act or not. Through 2025 and into 2026 Microsoft has been rolling out managed policies and mandatory MFA requirements of its own, most visibly required MFA for sign-ins to administrative surfaces such as the Azure portal, plus Microsoft-managed Conditional Access policies that appear in tenants in report-only mode before enforcing. Specifics and timelines have shifted during the rollout, so check the current state on Microsoft Learn's mandatory MFA page rather than trusting any blog's snapshot, this one included. The direction is settled: unenforced MFA is being phased out from above, and building your own baseline means you decide the shape of enforcement instead of inheriting it.

The honest gap: enforced MFA is not phishing-proof

Here is the section that should temper the victory lap. The baseline policy, fully enforced, stops the classic attack — a stolen or sprayed password used directly — and that is a large share of real-world compromise. What it does not stop is attacker-in-the-middle phishing, which is now commodity tooling. The kit sits between the victim and the real Microsoft sign-in page, relays the password, relays the code or prompt approval in real time, and walks away with the session token. The user did MFA. It did not matter.

The answer is phishing-resistant authentication: FIDO2 security keys, passkeys and Windows Hello for Business. These bind the credential cryptographically to the genuine site, so a proxy in the middle receives nothing it can replay, and Conditional Access can require them through authentication strengths — a grant control demanding not merely "MFA" but "phishing-resistant MFA". The pragmatic sequencing is to enforce standard MFA for everyone first, since it stops the bulk of attacks and needs no new hardware, then move privileged roles to phishing-resistant methods as the next project. If your rollout plan ends at "everyone gets the Authenticator app", it has a known expiry date. Write the phase-two ticket now.

When it goes wrong anyway: What If and the sign-in log

Two tools cover most Conditional Access debugging. The What If tool lets you simulate a sign-in — this user, this app, this platform, this location — and see exactly which policies would apply and what they would demand. Use it before enforcing anything, and any time someone claims a policy "should" cover a case.

After the fact, the sign-in logs are ground truth. Open the specific entry and look at the Conditional Access tab: every policy is listed with its result — success, failure, not applied — and clicking one shows which condition matched. Nine times out of ten the mystery ("why was I prompted?", "why wasn't I?") dissolves the moment you read the entry instead of guessing. This is also where you audit reality: filter for sign-ins where no MFA policy applied and ask why each one exists.

The order, one more time

1. Two cloud-only break-glass accounts, excluded from everything, passwords in a safe, alerts on sign-in.
2. Know your starting point — security defaults, per-user MFA, or nothing — and what turning each off means.
3. One boring baseline policy: all users, all resources, require MFA, a short and honest exclusion list.
4. Report-only for a week. Read the logs. Fix or consciously exclude what you find.
5. Enforce, then add the refinements: block legacy auth, compliant devices for admins, careful named locations.
6. Write the phase-two ticket: phishing-resistant methods, starting with admins.

None of it is glamorous. All of it is the difference between the lockout story and a quiet Tuesday.

Questions people also ask