This chapter covers Conditional Access and its relationship to multi-factor authentication (MFA). AZ-900 tests this under objective 2.5, building on the previous chapter's coverage of authentication methods.
Jump to a section
A simple way to picture Conditional Access and MFA
Imagine a security guard who lets employees through with just a badge scan under normal circumstances, but requires an additional ID check if someone tries to enter at an unusual hour, from an unfamiliar entrance, or is carrying something unusual. The guard isn't checking everyone the same way regardless of circumstances — the level of scrutiny adapts to the situation. Conditional Access works the same way for digital sign-ins: rather than applying the exact same authentication requirement to every sign-in attempt regardless of context, it applies additional requirements (like requiring MFA) specifically when certain conditions are met — an unfamiliar location, an unmanaged device, or other risk signals.
What Conditional Access is
Conditional Access is a Microsoft Entra ID feature that applies access policies based on specific conditions — such as the user's location, the device being used, or the application being accessed — rather than applying the same fixed requirement to every sign-in attempt regardless of context.
How it works
An administrator defines policies specifying conditions (like "signing in from outside a trusted location") and the corresponding requirement to apply when that condition is met (like "require multi-factor authentication" or "block access entirely"). This allows organizations to apply stronger security requirements specifically in higher-risk situations, without unnecessarily burdening low-risk, routine sign-ins with the same extra steps.
Relationship to MFA
Conditional Access and multi-factor authentication are related but distinct: MFA is an authentication method itself (requiring multiple verification factors); Conditional Access is a policy engine that can decide *when* to require MFA (or other requirements) based on defined conditions, rather than applying it uniformly to every sign-in.
Common use cases
Requiring MFA specifically when signing in from an unfamiliar location or an unmanaged device, blocking access entirely from certain high-risk locations, or requiring a compliant, managed device before accessing sensitive resources are all examples of policies Conditional Access can enforce.
Define the condition to evaluate
A condition is defined — such as sign-in location, device compliance status, or the specific application being accessed — that Conditional Access will evaluate for each sign-in attempt.
Define the resulting requirement
Based on whether the condition is met, a requirement is applied — such as requiring MFA, blocking access, or requiring a compliant device.
Apply the policy to relevant users or resources
The policy is scoped to specific users, groups, or applications, rather than necessarily applying organization-wide to everything.
Adjust policies as risk patterns change
Conditional Access policies can be refined over time as an organization better understands its risk patterns and sign-in behavior.
An organization configures a Conditional Access policy requiring MFA whenever an employee signs in from outside the company's trusted office locations, while allowing sign-ins from within those trusted locations with just a password — balancing security against convenience based on actual risk level.
A separate organization requires that sensitive financial applications can only be accessed from devices that meet the organization's compliance requirements (like having up-to-date security patches), using Conditional Access to enforce that requirement automatically rather than relying on employees to remember the policy themselves.
Objective 2.5 expects candidates to understand Conditional Access as a policy-based mechanism for applying security requirements based on specific conditions, distinct from MFA itself.
A common wrong answer is treating Conditional Access and MFA as the same thing — MFA is an authentication method; Conditional Access is a policy engine that can decide when to require MFA (among other possible requirements) based on defined conditions. Another common trap is assuming Conditional Access always blocks access — it can also simply require an additional step (like MFA) rather than outright denying access.
Stable terms: Conditional Access, policy, condition. Understanding that Conditional Access evaluates conditions and applies a corresponding requirement — which might be MFA, blocking access, or something else — is the core exam-relevant idea.
Memory trick: MFA is a specific authentication requirement. Conditional Access is the policy layer deciding when that requirement (or another one) should apply, based on the circumstances of the sign-in attempt.
Conditional Access is a Microsoft Entra ID feature that applies access policies based on specific conditions, rather than a uniform fixed requirement.
Conditional Access and MFA are related but distinct — MFA is an authentication method; Conditional Access can decide when to require it.
Conditional Access policies can result in requiring MFA, requiring a compliant device, or blocking access, depending on the defined conditions.
Policies can be scoped to specific users, groups, or applications rather than applying uniformly across an entire organization.
These come up on the exam all the time. Here's how to tell them apart.
Multi-Factor Authentication (MFA)
A specific authentication method
Requires multiple verification factors
Applied directly during sign-in
Conditional Access
A policy engine evaluating conditions
Decides when to require MFA or other actions
Applied based on context like location or device
Mistake
Conditional Access and multi-factor authentication are the same thing.
Correct
MFA is a specific authentication method requiring multiple verification factors. Conditional Access is a policy engine that can decide when to require MFA (or other requirements) based on defined conditions — they work together but aren't the same.
Mistake
Conditional Access always blocks access when a condition is triggered.
Correct
Conditional Access policies can result in various outcomes — requiring MFA, requiring a compliant device, or blocking access entirely — not just outright denial.
Mistake
Conditional Access policies must apply to the entire organization uniformly.
Correct
Policies can be scoped to specific users, groups, or applications, allowing different requirements for different parts of the organization rather than one blanket policy for everyone.
It's a Microsoft Entra ID feature that applies access policies based on specific conditions — like sign-in location or device compliance — rather than applying the same fixed security requirement to every sign-in regardless of context.
MFA is a specific authentication method requiring multiple verification factors. Conditional Access is a policy engine that can decide when to require MFA (or other requirements, like blocking access) based on defined conditions — they work together, but Conditional Access is the decision layer, not the authentication method itself.
No — depending on the policy, it might require an additional step like MFA, require a compliant device, or block access entirely. It's flexible in what action it applies when a condition is met, not limited to just blocking.
You've just covered Conditional Access and MFA — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?