What's changed: Created MS-102 Chapter 2 (domain: Microsoft Entra identity and access): identity synchronization (IdFix pre-remediation, Microsoft Entra Connect Sync vs Cloud Sync, Connect Health monitoring, troubleshooting), authentication (authentication methods, SSPR, Password Protection global/custom banned lists, password writeback), and secure access (Identity Protection risk detection and risk policies, Conditional Access signals and grant/block, enforcing MFA via Conditional Access, require compliant device).
2.3Secure access
Understand risk-based detection with Microsoft Entra Identity Protection, access control via Conditional Access policies, and enforcing multifactor authentication (MFA) using Conditional Access.
Secure access combines a "detect risk" layer and a "control access" layer. Detection is Identity Protection; control is Conditional Access.
2.3.1Identity Protection
Microsoft Entra Identity Protection evaluates sign-in risk and user risk from signals (leaked credentials, impossible travel, anonymous IP), surfacing risky users / risky sign-ins. Via risk policies, it can require MFA or force a password change when risk is high. Its role is "detecting and classifying risk".
2.3.2Conditional Access and MFA
Conditional Access is the access-control engine that evaluates signals (user/group, location, device, app, risk) and applies grant/block decisions with conditions. Set conditions like require MFA, require a compliant device, and sign-in frequency. Enforcing MFA via a Conditional Access policy is today’s standard—e.g., "always MFA for admin roles or risky sign-ins." You can also use Identity Protection risk as a Conditional Access condition.
Cues: "detect risk from leaked credentials/impossible travel; risky users/sign-ins" = Identity Protection. "grant/block or require MFA/compliant device from user/location/device/app signals" = Conditional Access. "standard way to enforce MFA" = Conditional Access policy. IP risk can be a CA condition.
Watch the mix-ups: (1) Identity Protection (detect/classify risk) vs Conditional Access (control access). (2) MFA is a "capability," but enforcement is normally via Conditional Access (distinct from legacy per-user MFA or security defaults). (3) Require-compliant-device is a Conditional Access grant control (works with Intune compliance).
2.3.3Section summary
- Identity Protection detects/classifies risk; risky users/sign-ins and risk policies act on it
- Conditional Access controls access—grant/block, require MFA/compliant device—from signals
- Enforcing MFA via Conditional Access is standard; IP risk can be a CA condition
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to detect and surface risky sign-ins and users from signals like leaked credentials and impossible travel. Best?
Q2. You want to always require MFA when admin-role users sign in from untrusted locations. Best?
Q3. You want to limit external access from unmanaged devices to only Intune-compliant devices. Best?
Q4. You want to auto-require MFA when sign-in risk is high and force a password change when user risk is high. Best?
Q5. "Risk detection" and "access control" are different layers. Which is the control engine that actually allows/blocks access?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.