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?