Conditional Access vs MFA in Microsoft Entra ID: What's the Difference?
People treat these as rivals — as if you pick one. You do not. MFA is a check you can demand; Conditional Access is the thing that decides when to demand it. Once you see them as a control and a policy engine, the confusion evaporates.
New to cloud? CAMPUX is a free, build-first course. Start here →
MFA is a verification method — a second proof of identity like an app approval or a security key. Conditional Access is the Entra policy engine that decides when to demand that proof. They are not alternatives: Conditional Access usually enforces MFA. Without it (or security defaults), per-user MFA still exists, but that is the legacy way.
If you have been searching for "conditional access vs mfa" expecting a winner, that is the reframe: you are not comparing two products. You are looking at a check and the engine that calls for the check. Get that straight and every downstream question — licensing, security defaults, adaptive MFA, risk-based policies — falls into place. If Conditional Access itself is new to you, start with the Conditional Access explainer — it covers how the policy engine works from zero; this page stays focused on the comparison.
What MFA actually is (a control, an authentication factor)
MFA asks a user to prove identity with more than a password. A password is something you know. MFA adds a second category — something you have (a phone running the Authenticator app, a hardware key) or something you are (a fingerprint, a face). Requiring two categories means a stolen password alone does not get an attacker in. That is the entire security value, and it is large: the majority of account takeovers stop cold at an MFA prompt.
The point to hold onto is that MFA is a control, not a decision-maker. On its own, MFA has no opinion about when it should run. Something else has to say "for this sign-in, require a factor." In a very simple setup, that "something else" is a blunt rule — every user, every time. In a real one, you want to be far more precise about when the prompt fires. That precision is not MFA's job. It belongs to the policy engine.
What Conditional Access is (a signal-driven policy engine)
Conditional Access is the "if this, then that" layer of Microsoft Entra ID — a Zero Trust policy engine that sits in the sign-in path, reads signals about the attempt (user, application, device state, location, and risk on P2), and enforces an outcome: allow, block, or require a control such as MFA or a compliant device. The classic policy reads like a sentence — "if a user in the Finance group opens the payroll app from an untrusted location, require MFA." MFA is the control the policy calls for; Conditional Access is the sentence. How the engine evaluates policies — the assignments, the and/or logic across conditions, why block wins when policies conflict — is its own topic, and the Conditional Access explainer walks through the whole policy engine step by step.
MFA answers "prove it's you." Conditional Access answers "should I even ask right now — and if so, how hard?"
Why you use them together, not either/or
The reason this stops being a versus is that each is incomplete without the other in a serious environment. MFA with no policy engine is all-or-nothing: you either prompt everyone constantly or you prompt no one. A policy engine with no controls to call has nothing to enforce. Put them together and you get what you actually want — the right friction in the right moment.
A worked example makes it concrete. You do not want to nag a known employee on a compliant laptop from the office every single morning; that trains people to click "approve" on reflex, which is its own risk. You do want a hard MFA challenge the instant someone tries to reach an admin portal from an unfamiliar country on an unmanaged device. Same control — MFA — applied two different ways because Conditional Access read the signals and decided. That targeting is the whole game. Blanket MFA protects you but annoys everyone; targeted MFA protects you and stays quiet when the sign-in is obviously fine.
This is also why "do I need both" is the wrong question. You need MFA — that is not in doubt. Conditional Access is how you deliver MFA with judgment instead of a sledgehammer. When you are ready to actually roll it out, the enforce-MFA-with-Conditional-Access runbook walks the rollout end to end — report-only first, break-glass exclusions, then enforcement — and it assumes you already understand what Microsoft Entra ID is as the identity layer underneath.
Adaptive MFA: making MFA conditional
"Adaptive MFA" is not a separate Entra product — it is what you get when Conditional Access decides the MFA prompt instead of a blanket rule. The policy engine reads the context of each sign-in and only demands the second factor when the context warrants it. In practice, four triggers cover most of what teams deploy:
- Outside named locations. You define trusted IP ranges (the office, the VPN egress) as named locations, then require MFA for any sign-in that comes from anywhere else. The everyday desk sign-in stays quiet; the hotel Wi-Fi sign-in gets challenged.
- Unfamiliar or unmanaged device. Require MFA (or block outright) when the device is not Entra-joined or not marked compliant by Intune. A known corporate laptop passes; a personal machine gets the prompt.
- Risky sign-in — with P2. Entra ID Protection scores each sign-in (anonymized IP, atypical travel, unfamiliar patterns), and a risk-based policy demands MFA only when that score crosses your threshold. This is the purest form of adaptive MFA, and it needs the P2 tier.
- Sensitive applications. Scope a policy to specific apps — admin portals, payroll, HR — and require MFA on every access to those, regardless of location or device. Low-stakes apps stay frictionless; high-stakes apps always check.
These patterns stack. A common production shape is: MFA everywhere outside named locations, plus always-MFA on admin portals, plus risk-based step-up if you have P2. Each trigger is a separate policy, which keeps them individually testable in report-only mode before you enforce.
Conditional Access and routing: it does not route traffic
A point of recurring confusion: Conditional Access is not a networking feature. It evaluates once, at authentication time, and its location conditions are just IP lists — named locations are ranges you declare, not paths traffic takes. Conditional Access never routes, inspects, or filters packets, and it has no view of what a session does after the token is issued (session controls can shorten or restrict the token, but that is still identity, not routing). If a user signs in over a VPN, all Conditional Access sees is the VPN's egress IP.
If what you actually need is network control — steering or restricting traffic between subnets, VMs, and the internet — that is a different toolset: network security groups for subnet- and NIC-level rules, Azure Firewall for centralized inspection and egress control. The NSG vs Azure Firewall comparison covers when each applies. The clean division of labor: Conditional Access guards who gets a token; NSGs and firewalls guard where packets can go.
Azure security defaults vs Conditional Access (the free middle ground)
Before you reach for the policy engine, there is a free option that gives you MFA without any policy writing: Security Defaults. It is a single on-or-off switch in Entra ID, available on the free tier. Turn it on and Entra enforces a sensible baseline for everyone — MFA registration for all users, MFA prompts when Entra judges them necessary, MFA for privileged roles, and a block on legacy authentication protocols that cannot do MFA.
For a small tenant with no special requirements, Security Defaults is genuinely good and you should not feel behind for using it. The catch is that it has no granularity. You cannot exclude a break-glass admin account, you cannot carve out a service account, you cannot say "trust the office network" or "only challenge risky sign-ins." It is one policy, applied to everyone, that you cannot edit. The moment you need an exception — and you will, the first time an automation account gets stuck at an MFA prompt it cannot answer — you have outgrown it.
That is the honest relationship between the two. Security Defaults is the floor: free, broad, uncustomizable MFA. Conditional Access is the tool you graduate to when "everyone, always" is too crude and you need to target by signal. You do not run both at once — turning on Conditional Access policies is what lets you turn Security Defaults off.
Security Defaults is a switch. Conditional Access is a language. The switch gives you one hardcoded MFA policy for free. The language lets you write as many targeted policies as you need — at the cost of a license and the responsibility of writing them well.
The gap: the licensing line — where free MFA stops and P1 Conditional Access begins
This is where the comparison gets money attached, and it is the detail most articles skate over. MFA as a factor is available broadly across Entra tiers — you can require it through Security Defaults or through legacy per-user MFA on the free tier at no extra cost. What you are paying for when you buy up is not MFA. It is the policy engine.
Conditional Access requires Microsoft Entra ID P1 for every user a policy protects. That license is the line: below it you get MFA but only the blunt, uncustomizable kind; at P1 you get the if-then engine, the signals, the exceptions, the trusted locations, the device rules. And there is a second line above it. Risk-based Conditional Access — policies that react to sign-in risk or user risk — requires Entra ID P2, because those risk scores are produced by Entra ID Protection, a P2 feature. So "require MFA only for risky sign-ins," the pattern everyone wants, sits at the top tier.
Worth naming the old approach so you recognize it in a tenant: per-user MFA is the legacy method where you flip MFA on or off account by account in a standalone list. It works and it is free, but it is enforced per user with no signal awareness — it cannot tell a risky sign-in from a routine one. Modern practice is to leave per-user MFA alone and drive MFA through Conditional Access instead, so the same control gets applied with context. If you are deciding which tier to actually buy, the Entra ID P1 vs P2 note maps the licensing lines feature by feature.
| Security Defaults | Per-user MFA (legacy) | Conditional Access | |
|---|---|---|---|
| Cost / license | Free (Entra ID Free) | Free (Entra ID Free) | Entra ID P1 per user; P2 for risk-based |
| Granularity | None — one policy, everyone, no edits | Per account on/off; no conditions | High — target by user, app, device, location, with exceptions |
| Exclusions / break-glass | None — cannot exclude any account | Manual — leave the account off the list | Built in — exclude break-glass admins and service accounts per policy |
| Report-only mode | No — on or off, immediately live | No | Yes — see who a policy would affect before enforcing it |
| Signals used | Microsoft-decided baseline only | None — identity only | User, group, app, device state, location, and risk (P2) |
| Best for | Small tenants wanting solid MFA with zero setup | Legacy tenants not yet on P1; avoid for new work | Any org needing exceptions, trusted networks, or risk-aware MFA |
Tiers and feature boundaries are current as of 2026; Microsoft moves the licensing lines occasionally, so confirm against Microsoft Learn before you budget.
If you are mapping the tiers to spend, the Entra ID overview sets up the identity layer these policies run on, and Defender for Cloud basics covers the posture side of the same security story — the part that watches your resources rather than your sign-ins. For the access side, Owner vs Contributor vs Reader covers who can change what once someone is through the door, and if you are moving between tenants, remapping Conditional Access after a migration walks the rebuild policy by policy.
Where Conditional Access lives, and the policies that appeared without you
Two practical questions arrive with the conceptual one, and the page would be incomplete without them. The first is simply where to find it: sign in to the Microsoft Entra admin center, then Entra ID → Conditional Access → Policies. You need at least the Conditional Access Administrator role to see the list. It is the same list whether you reach it from the Entra admin center or from the identity blades of the Azure portal.
The second question is the one that sends people searching: why are there policies in my tenant that nobody here created? Those are Microsoft-managed policies, and understanding them matters because they are the first Conditional Access most small tenants ever run.
Microsoft creates them directly in eligible tenants, in report-only state, preconfigured with recommended controls. If you leave one in report-only, Microsoft turns it on itself no less than 30 days after it appears, with an email and a message-centre post two weeks before. You can switch it on sooner, or opt out by setting it to Off. You can also exclude identities — do exclude your break-glass accounts, exactly as you would for any other policy. What you cannot do is rename or delete one; if you need more changes than that, duplicate it and edit the copy. In the policy list they show Microsoft in the Created by column, and in the audit log their names start with Microsoft-managed:.
| Policy | What it does | Who gets it |
|---|---|---|
| Multifactor authentication for admins accessing Microsoft admin portals | Requires MFA for fourteen highly privileged roles when they open an admin portal | P1 and P2 tenants without security defaults |
| Multifactor authentication for all users | MFA on every sign-in; the session usually persists on the device afterwards | Eligible tenants |
| Multifactor authentication for per-user MFA users | Moves users still on the legacy per-user switch onto a Conditional Access policy | P1 and P2 tenants with fewer than 500 per-user MFA users |
| Multifactor authentication and reauthentication for risky sign-ins | MFA and a fresh sign-in when Entra ID Protection scores a sign-in as high risk | P2 tenants without security defaults |
| Block access for high-risk users | Blocks accounts Entra ID Protection judges likely compromised, until remediated | P2 tenants |
| Require remediation for high-risk users | Sends a high-risk user through a guided recovery rather than a flat block | P2 tenants |
| Block legacy authentication | Blocks the protocols that cannot do MFA at all | Also appears as a Baseline security mode policy |
| Block device code flow | Blocks a flow rarely used by customers and frequently used by attackers | Eligible tenants |
If that exact phrase is what brought you here, it is because it appeared in your tenant as a security group, and nobody on your team made it. It belongs to the risky-sign-ins managed policy above. When a tenant has more MFA-registered users than P2 licences, Microsoft does not scope the policy to everyone; it creates a group with that name, fills it with as many licensed users as the P2 count allows — prioritising directly assigned licences — and scopes the policy to the group. So the group is the policy's scope, and you adjust who is covered by editing the group rather than the policy. Tenants with enough P2 licences for every active user get the policy scoped to all users instead, which is why it is worth checking whether service and break-glass accounts landed in it. Guest users are never included.
Why “Microsoft Authentication Broker” keeps showing up
The Microsoft Authentication Broker is a first-party application, not something you installed. It is the component that the Authenticator app on iOS and the Company Portal app on Android use to register a device with Entra and to broker sign-ins on that device afterwards. You mostly meet it in two places: in the sign-in logs, as the application a phone authenticated to during enrolment, and in Conditional Access troubleshooting, when a policy blocks it.
The block is nearly always the same chicken-and-egg. A policy says require a compliant device for all cloud apps. A brand-new phone is not compliant yet, because it has not registered; registration goes through the broker; the broker is a cloud app; the policy blocks it; the phone can never become compliant. The symptom is a user who cannot get past enrolment, and a sign-in log entry showing the broker failing the compliant-device policy.
The fix is to stop asking for compliance at the one moment compliance is impossible. Microsoft's documented pattern is a separate policy targeting the register or join devices user action that requires MFA rather than a compliant device, and to keep the compliance requirement for the apps that actually need it. Microsoft also notes that require device to be marked as compliant does not block Authenticator's access to the scope it needs to register a user's methods, so the app itself is not the problem — the policy shape is. If you are tempted to exclude the broker from a policy wholesale, understand that you are opening a path around your device requirement, and scope it to the registration action instead.
Using Duo or another MFA provider with Conditional Access
A common version of the “versus” question is not Conditional Access against Microsoft's MFA but against someone else's: we already use Duo, does Conditional Access replace it, and can they work together? The answer is that they sit at different layers, exactly as MFA and Conditional Access do, so the question resolves the same way.
Conditional Access is the engine that decides when a second factor is required. A third-party provider is one way of supplying that factor. Microsoft supports this formally through external authentication methods: you register the provider in Entra, and when a policy demands MFA, the user can satisfy it with the external method, and that satisfies the MFA requirement of Microsoft-managed policies too. The older mechanism, custom controls, is being retired — Microsoft's own guidance is that custom controls do not satisfy MFA claim requirements and that organisations using them should migrate to external authentication methods. If you are still on a custom control, that migration is the work, and your provider will have the integration guidance.
So “Duo vs Conditional Access” is not a choice. Keep Conditional Access as the policy engine, register the provider as an external method, and let policies decide when the prompt fires. What you should not do is run a third-party MFA in front of Entra with Conditional Access unaware of it, because then the engine cannot tell a sign-in that already did MFA from one that did not, and you end up either double-prompting or trusting a claim Entra never saw.
Questions people also ask
Is Conditional Access the same as MFA?
No. MFA is a control — a second factor that proves you are who you say you are. Conditional Access is a policy engine that decides when to require that control, based on signals like user, device, location, and application. Conditional Access can enforce MFA, but MFA is not Conditional Access. One is the check; the other is the rule that calls for the check.
Where is Conditional Access in Entra?
In the Microsoft Entra admin center, under Entra ID, then Conditional Access, then Policies. You need at least the Conditional Access Administrator role to see the list, and it is the same list whether you reach it from the Entra admin center or from the identity section of the Azure portal. Policies created by Microsoft show Microsoft in the Created by column.
What is the “Conditional Access: Risky sign-in multifactor authentication” group?
A security group Microsoft creates in your tenant to scope its managed policy for risky sign-ins when you have more MFA-registered users than P2 licences. Microsoft fills it with as many licensed users as the P2 count allows and scopes the policy to the group, so you control coverage by editing the group. Tenants with enough P2 licences for every active user get the policy scoped to all users instead. Guests are never included.
What is Microsoft Authentication Broker in Conditional Access?
A first-party application that the Authenticator app on iOS and the Company Portal app on Android use to register a device with Entra and broker sign-ins on it. It appears in Conditional Access troubleshooting when a require-compliant-device policy blocks it before the device has registered, which is a chicken-and-egg the policy shape creates. Microsoft's pattern is a separate policy on the register-or-join-devices user action that requires MFA rather than compliance.
Can I use Duo with Microsoft Conditional Access?
Yes, and they are not alternatives. Conditional Access decides when a second factor is required; a third-party provider registered as an external authentication method supplies it, and that satisfies the MFA requirement of your own policies and Microsoft-managed ones. The older custom-controls mechanism does not satisfy MFA claim requirements and is being retired, so organisations still on it should migrate to external authentication methods.
Can I delete a Microsoft-managed Conditional Access policy?
No. You can set it to Off, turn it on early, and exclude identities such as break-glass accounts, but you cannot rename or delete it. If it is left in report-only, Microsoft enables it no less than 30 days after it appears, with notice two weeks beforehand. For changes beyond state and exclusions, duplicate the policy and edit the copy.
Does Conditional Access replace MFA?
No — it enforces it. MFA is the verification method; Conditional Access is the policy layer that decides when that method is demanded. Turning on Conditional Access does not remove the need for MFA: nearly every real deployment includes policies whose grant control is "require multifactor authentication." You can run MFA without Conditional Access (security defaults or legacy per-user MFA), but you cannot get much value from Conditional Access without controls like MFA to enforce.
What triggers MFA in Conditional Access?
Whatever conditions your policies name. The common triggers are a sign-in from outside your named locations, an unmanaged or non-compliant device, access to a sensitive application, and — with Entra ID P2 — a sign-in the risk engine scores as suspicious. Each trigger is a policy condition; when it matches and the grant control says require MFA, the prompt fires.
Does Conditional Access require a license?
Yes. Conditional Access requires Microsoft Entra ID P1 for each user it protects. Risk-based Conditional Access — policies that react to sign-in risk or user risk — requires Entra ID P2, because those risk signals come from Entra ID Protection. MFA itself is available on lower tiers as a factor; it is the policy engine that carries the license cost.
What is the difference between security defaults and Conditional Access?
Security defaults is a free, on-or-off setting that enforces MFA broadly for all users with no ability to customize — no exclusions, no report-only mode. Conditional Access is a granular policy engine that requires Entra ID P1 and lets you target MFA by user, group, application, device, and location, with break-glass exclusions and report-only testing. Security defaults is the floor; Conditional Access is the tool you graduate to when you need control.
Can Conditional Access enforce MFA only for risky sign-ins?
Yes, and this is one of its strongest patterns. A risk-based Conditional Access policy demands MFA only when a sign-in looks suspicious — an unfamiliar location, an anonymized IP, atypical travel — and lets known-good sign-ins through untouched. This requires Entra ID P2, since the sign-in risk and user risk signals come from Entra ID Protection.