Conditional Access and MFA in Microsoft Entra ID
Almost every identity question on AZ-500 comes back to one idea: decide who may sign in, from where, and under which conditions. In Microsoft Entra ID (formerly Azure AD) that decision engine is Conditional Access.
How a Conditional Access policy works
A policy is an if-then rule. It has three parts:
- Assignments: users or groups, the cloud apps, and conditions such as sign-in risk, device platform, location and client app.
- Grant controls: block access, or grant access with requirements such as MFA, a compliant device, a Microsoft Entra hybrid joined device, an approved client app or a password change.
- Session controls: sign-in frequency, persistent browser session, or app-enforced restrictions.
Policies are evaluated after first-factor authentication. All policies that match are applied together, there is no order, and a Block always wins. Exclude at least one emergency (break-glass) account from every policy so you cannot lock yourself out. Use report-only mode to test the effect before enforcing.
Conditional Access versus per-user MFA
Per-user MFA (the legacy MFA service settings) turns MFA on for an account everywhere. Conditional Access is the recommended way, because it can target specific apps and conditions. Security defaults give a free baseline (MFA registration, MFA for admins, blocking legacy authentication), but you cannot use them together with Conditional Access. Conditional Access needs Microsoft Entra ID P1; risk-based conditions need P2.
Named locations let you mark trusted IP ranges or countries. A trusted location is a condition you can include or exclude, it does not skip authentication by itself.
Identity Protection and Password Protection
| Feature | Purpose | License |
|---|---|---|
| Microsoft Entra ID Protection | Detects user risk and sign-in risk, supports risk policies and remediation | P2 |
| Password Protection | Blocks weak and banned passwords, can extend to on-premises AD with a proxy and DC agent | P1 |
| Self-service password reset | Lets users reset their own password, with writeback to on-premises | P1 |
Sign-in risk is about the attempt (for example an anonymous IP address). User risk is about the account (for example leaked credentials). Risky users usually need a password change; risky sign-ins usually need MFA.
Authentication methods
Prefer phishing-resistant methods: FIDO2 security keys, Windows Hello for Business and certificate-based authentication. Microsoft Authenticator is strong; SMS and voice are the weakest. Authentication strengths in Conditional Access let you require a specific set of methods for sensitive apps.
Exam traps
- Per-user MFA and Conditional Access are different. Only Conditional Access understands apps, locations and device state.
- Block overrides grant, and policy order does not exist.
- Security defaults and Conditional Access cannot both be on.
- Risk-based policies need Microsoft Entra ID P2, not P1.
- Excluding break-glass accounts is expected; trusted locations do not remove the need for a policy.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. Users in the finance group must use MFA only when they sign in to a specific cloud app from outside the corporate network. What should you configure?
Show answer
Answer: B.Conditions such as app and location are evaluated by Conditional Access. Per-user MFA cannot be scoped by app or location.
2. Two Conditional Access policies apply to a sign-in. One requires MFA, the other blocks access from a country. The user signs in from that country. What happens?
Show answer
Answer: B.All matching policies apply and Block overrides any grant control. Policies are not ordered.
3. You want users with a medium or higher sign-in risk to be forced to use MFA automatically. What do you need?
Show answer
Answer: A.Sign-in risk comes from Microsoft Entra ID Protection and is used as a condition in Conditional Access (Entra ID P2).
4. You must stop users from choosing passwords that contain variations of the word "contoso". What do you configure?
Show answer
Answer: B.Password Protection checks passwords against a global list and your custom banned list, including common substitutions.