Conditional Access & Identity Protection
Signals · Grant controls · Sign-in risk · User risk · Authentication strengths
Practice questions for this topic →
How Conditional Access works
| Part | Examples |
|---|---|
| Signals | User, group or agent; IP location; device; application; real-time and calculated risk (ID Protection); Defender for Cloud Apps |
| Decisions | Block (most restrictive) or grant with: MFA, authentication strength, compliant device, Entra hybrid joined device, approved client app, app protection policy, password change… |
| Timing | Policies are enforced after first-factor authentication; it isn't a frontline defense against DoS |
| License | Conditional Access needs P1; risk conditions need P2 |
Authentication strengths
- Specify which combinations of authentication methods satisfy a policy. Three built-in strengths: MFA, Passwordless MFA and Phishing-resistant MFA (Windows Hello for Business or platform credential, FIDO2 security key, certificate-based multifactor). Built-ins can't be modified; Microsoft updates them as methods arrive. Custom strengths are allowed.
- Use cases: sensitive resources, sensitive actions (with authentication context), access outside the corporate network, users at high risk, guest users (with cross-tenant settings).
Risk policies and report-only mode
- Sign-in risk → require MFA at medium/high. User risk → Microsoft recommends require risk remediation at High: passwordless users have sessions revoked, password users do a secure password change after MFA. Use separate policies for the two conditions.
- Users must be registered for MFA first, and hybrid users need password writeback, or they're blocked. Least-privileged role to manage policies: Conditional Access Administrator. Trusted network locations reduce false positives in some detections.
- Report-only mode evaluates without enforcing, except the User actions scope, which it can't test. Results: Success, Failure, User action required, Not applied. Exclude macOS, iOS and Android from report-only device-compliance policies to avoid repeated certificate prompts. The Conditional Access insights workbook (Azure Monitor) shows impact.
- Require risk remediation automatically applies two settings: the Require authentication strength grant control and the Sign-in frequency: Every time session control. A password change made outside the risky-user remediation flow doesn't count as the secure password change. Other user-risk controls: Require password change (blocks until a secure change is done) and Block access.
- ID Protection MFA registration policy: users are prompted at the next interactive sign-in and have 14 days to register (they can bypass during that period if MFA isn't required); exclude emergency access accounts. Modifying it needs P2 or Entra Suite, and the Security Administrator role is the least privileged for these risk-based policies.
- Microsoft's pages treat risk policies as Conditional Access policies and include a migration section. The legacy ID Protection policies' Oct 1, 2026 retirement date is quoted from Microsoft's warning box and portal banner ("This risk policy is now read-only and will be retired on October 1, 2026") by three independent sources; I couldn't read the Learn warning myself. Those sources add that there is no automatic migration. The date has now passed.
Exam Tips
Tick each tip once you can answer it without looking.
“Require MFA only for risky sign-ins” → Conditional Access with sign-in risk condition (P2).
“Force password change when credentials are leaked” → User risk policy → require risk remediation / password change (P2).
“Admins must use phishing-resistant MFA” → Conditional Access authentication strength.
“Only allow access from Intune-compliant devices” → Conditional Access grant: require compliant device.
“Evaluate impact of a new policy without blocking users” → Report-only mode.
“Block old protocols that can't do MFA (POP/IMAP basic auth)” → Conditional Access: block legacy authentication.
“Risky user can't self-remediate and is blocked” → They weren't MFA-registered (or hybrid without password writeback).
“Keep emergency access if Conditional Access locks everyone out” → Break-glass accounts excluded from policies.
“Combine sign-in risk and user risk in one policy?” → Don't: create separate policies.
“When Conditional Access policies are enforced” → After first-factor authentication. Trap: Not a frontline defense against denial of service; needs P1.
“Built-in authentication strengths” → MFA, Passwordless MFA, Phishing-resistant MFA (Windows Hello, FIDO2, certificate-based). Trap: Built-ins can't be modified; custom strengths are allowed.
“Report-only mode limits” → Can't test the User actions scope; results are Success, Failure, User action required, Not applied. Trap: Exclude macOS, iOS and Android from report-only compliance policies to avoid certificate prompts.
“Conditional Access grant controls” → MFA, authentication strength, compliant device, hybrid joined device, approved app, app protection policy, password change. Trap: Block is the most restrictive decision.
“Select Require risk remediation in a risk policy” → It applies Require authentication strength and sign-in frequency Every time automatically. Trap: Passwordless users have sessions revoked; password users do a secure password change after MFA.
“A user at high risk changes their password through the normal route” → Doesn't count: only the risky-user remediation flow meets the secure password change requirement. Trap: Users must be registered for MFA first; hybrid users need password writeback or they're blocked.
“ID Protection MFA registration policy” → Prompts at the next interactive sign-in; 14 days to register (bypass allowed meanwhile if MFA isn't required); exclude break-glass accounts. Trap: Needs P2 or Entra Suite; Security Administrator is the least privileged role for these policies.
“Apply risk controls at High only” → Fewer prompts and less friction. Trap: Low and Medium risks are excluded, which might not stop an attacker using a compromised identity.