Conditional Access and Identity Protection in Microsoft Entra ID
Eighth in this series on Microsoft Entra ID, covering the two risk-based access control layers that sit on top of MFA: Conditional Access and Identity Protection. They're covered together here because they're explicitly complementary — and easy to conflate — so it's worth understanding both at once and seeing exactly where they differ.
Conditional Access
Conditional Access requires a Microsoft Entra ID P1 or P2 licence (Microsoft 365 Business Premium also includes access to it). It focuses on securing access to specific applications based on signals — user account details, location, device, real-time risk, and the application itself — and can respond by granting access outright, requiring MFA, or blocking access depending on how those signals evaluate. The defining characteristic is application specificity: policies are tied to individual applications (Office 365, Salesforce, and so on), and each policy only applies to the app it's configured for.
During sign-in, Conditional Access collects these signals, evaluates them against configured policies, and enforces the resulting decision — allow, deny, or challenge for MFA.
Typical uses: requiring MFA conditionally based on role, location, or network (administrators but not regular users, say, or anyone connecting from outside the corporate network); restricting access to approved client applications only; requiring access only from devices that meet your compliance standards; blocking access from untrusted or unexpected locations outright; and excluding whole geographic regions you don't expect legitimate users to connect from, by defining a named location and creating a block policy against it — while remembering to exempt admin accounts from that policy, since locking out your own administrators is an easy and painful mistake.
Key building blocks: named locations (IP ranges or countries representing trusted or untrusted networks), user and workload identity targeting (scoping policies to specific users, groups, or directory roles), cloud apps (the applications a policy governs), grant controls (the enforcement action — block, require MFA, require a compliant device), session controls (governing session duration and behaviour, including sign-in frequency), and integration with Intune to enforce device compliance as part of the policy evaluation.
A representative walkthrough: navigate to Azure Active Directory → Manage → Security → Conditional Access; define a named location (say, "HQ" covering 192.168.1.0/24 and 192.168.2.0/24, marked as trusted); alternatively configure trusted IP ranges directly in Conditional Access settings; create a new policy, name it, and assign it to a group ("O365 Conditional Access" targeting "Sales users"); select the cloud apps it applies to ("Office 365"); set conditions on user risk (High) and location (the "HQ" named location just created); configure grant controls (block access, in this example); and set session controls such as an 8-hour sign-in frequency.
Common pitfalls: an overly restrictive policy applied to an administrator can lock them out of Entra ID entirely — hence the earlier point about exempting admins from broad blocking policies. Policies can also unexpectedly block legitimate users, Intune integration needs devices properly enrolled and compliant for device-based conditions to work as expected, users can remain signed in on persistent browser sessions even after a policy change, and during an Entra ID outage, Conditional Access policies may not evaluate as expected — worth factoring into any resilience planning.
Identity Protection
Microsoft Entra ID Protection is a security capability that detects suspicious activity and assigns risk levels to users and sign-ins. Administrators can define policies that automatically respond to different risk levels — blocking access, requiring a password change, or enforcing MFA.
Risk detections
One correction worth flagging here: the original note attributed leaked-credential detection to something called the "Elite Credential Service (LCS)." That name doesn't appear anywhere in Microsoft's documentation, and I couldn't verify it as a real product or internal name — it looks like a mishearing or misremembering during the course. What Microsoft actually documents is the Leaked credentials risk detection: Microsoft runs a large-scale credential-scanning pipeline across dark web forums, breach dumps, and paste sites, cross-referencing what it finds — through partnerships including its own Threat Intelligence Center and Digital Crimes Unit — against your tenant's actual valid password hashes. A detection only fires on a confirmed match, which is why it's always scored as high risk rather than a heuristic guess, and it's available on Free/P1, not gated behind P2. A cloud-based password reset remediates it for on-premises passwords too, provided password hash synchronisation is enabled.
The other detections in the note map cleanly onto real Microsoft Learn terminology, just worth naming precisely: impossible travel (originating from Microsoft Defender for Cloud Apps, requiring P2 plus a Defender for Cloud Apps licence) flags sign-ins from geographically distant locations within a shorter time than travel would allow; the note's "unfamiliar location" example maps to the unfamiliar sign-in properties detection (P2, real-time), which looks at properties — IP, ASN, location, device, browser — the system hasn't seen for that user before, after an initial learning period (minimum five days) during which the detection is deliberately switched off while it learns normal behaviour. Users and sign-ins are categorised into high, medium, and low risk.
Risk policies
A user risk policy assigns an overall risk level to a user based on accumulated signals, and can be configured to automatically block access, allow access, or allow access with a required password change, depending on the level — medium risk might allow access with a forced password change, high risk might block outright. Microsoft dynamically adjusts what qualifies as each risk level based on the evolving threat landscape, rather than relying on a static, administrator-defined mapping — a risk considered low today can be reclassified as medium or high later without any policy change on your end.
A sign-in risk policy is narrower: rather than assessing the account as a whole, it evaluates the risk of one specific sign-in attempt, and can be targeted at specific users or groups — stricter policies for executives with access to sensitive data, for example. Based on sign-in risk, administrators can block access or allow access with required MFA.
Identity Secure Score
Microsoft provides an Identity Secure Score — a snapshot of an organisation's identity security posture, with recommendations attached for improving it. (The course example showed a score of 33 out of 223, which is obviously specific to that lab tenant rather than a general benchmark, so it's not included here as anything more than an illustration of the format.)
Conditional Access vs. Identity Protection
The two are complementary but operate at different scopes. Identity Protection takes a holistic view — it assesses user risk and sign-in risk generally, independent of which application is being accessed. Conditional Access is application-focused — the "condition" driving its decisions is the specific app being accessed, which is what allows genuinely granular, per-application policy: requiring MFA at a given risk level for Office 365, say, while blocking access outright at that same risk level for Salesforce. That per-application flexibility is Conditional Access's real differentiator from Identity Protection's account-wide risk assessment.