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 →
Here is the short version: MFA is the "what," and Conditional Access is the "when." MFA — multi-factor authentication — is a control. It is a second factor a user has to present to prove identity: a code, an app approval, a security key. Conditional Access is a policy engine. It sits in the sign-in path, reads signals about the attempt, and decides what to do — allow it, block it, or require a control like MFA. So they are not two options on the same shelf. One is the protection; the other is the rule that decides when the protection kicks in.
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 control and the engine that applies it. Get that straight and every downstream question — licensing, Security Defaults, risk-based policies — falls into place.
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. Microsoft's own framing is a Zero Trust policy engine: it takes signals from a sign-in, evaluates them against policies you write, and enforces an outcome. The shape of a policy is an if-then. If these conditions hold, then require these controls — or block.
The signals it can read are the reason it is useful:
- User or group — who is signing in, and what roles they hold.
- Application — which app or resource they are reaching for.
- Device state — is the device compliant, is it Entra-joined, is it managed.
- Location — the IP or named location the attempt comes from.
- Sign-in and user risk — a real-time risk score, when you have the tier that supplies it.
The outcomes it can enforce include: grant access, block access, require MFA, require a compliant device, or force a password change. So 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.
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. For the ground-level mechanics of writing that first policy, the Conditional Access basics note walks through the if-then structure step by step, and it assumes you already understand what Microsoft Entra ID is as the identity layer underneath.
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. The methods themselves are worth understanding on their own; the MFA methods note covers how factors like the Authenticator app and security keys behave in practice.
| 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 |
| 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.
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.
Do I need both MFA and Conditional Access?
They are not an either/or. MFA is the protection you want to apply; Conditional Access is how you apply it precisely. You can run MFA without Conditional Access using Security Defaults or per-user MFA, but you lose the ability to target it by signal. Most organizations end up using Conditional Access to drive MFA once they need exceptions, trusted locations, or device rules.
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. 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 exceptions. 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.