Device compliance and authentication strength are the most common inputs to Conditional Access policies. They’re not the only ones. Named locations, sign-in risk, user risk, and Identity Protection signals give Conditional Access the ability to respond to context and threat in ways that device-only enforcement can’t.
Understanding these additional signals isn’t optional for a complete Conditional Access design – it’s what separates an environment that enforces a static security posture from one that responds dynamically to changing conditions. Device compliance tells you about the device. Risk signals tell you about what’s happening right now.
Named locations define network ranges and countries that Conditional Access can use as conditions. An IP range named location identifies specific trusted networks – your office ranges, known VPN exit points, data center ranges – that can be used to relax or tighten enforcement based on where a sign-in originates. A country/region location identifies geographic areas that can be used to block access entirely or require additional verification.
The practical use cases for named locations fall into two categories. Restricting access from countries where your organization has no presence or legitimate users is one of the highest-value, lowest-friction Conditional Access policies available – it blocks a significant portion of credential-based attacks with essentially no impact on legitimate users. Using trusted IP ranges to allow specific scenarios – legacy authentication from specific network printers, service accounts that can’t support modern auth – lets you scope exceptions precisely rather than applying them broadly.
Named locations require maintenance. IP ranges change. VPN providers change. Office locations move. A named location that was accurate when it was created becomes stale without a review process. Stale named locations either create gaps in enforcement or block legitimate access – neither outcome is acceptable. Build the review cadence into your operational process when you create the location.
Blocking sign-ins from countries where you have no users is one of the simplest, highest-value Conditional Access policies you can build. It costs almost nothing and eliminates a significant attack surface.
Sign-in risk is Entra ID Identity Protection’s assessment of the likelihood that a specific sign-in attempt isn’t being made by the legitimate account owner. The assessment is based on signals Microsoft aggregates across the identity ecosystem – atypical travel patterns, sign-in from anonymous IP addresses, sign-in properties that don’t match the user’s established pattern, password spray patterns, and more. The result is a risk level – low, medium, or high – that Conditional Access can evaluate as a condition.
A sign-in risk policy that requires MFA for medium or higher risk and blocks high risk is a practical starting point for most environments. It adds friction at the moment something looks suspicious, without affecting the experience for normal sign-ins. The key design decision is what to do with medium risk – requiring MFA allows a user who is genuinely trying to sign in to complete authentication, while blocking requires IT intervention. Starting with MFA requirement for medium risk and monitoring the volume of triggered events before considering a block approach is the more operationally sound path.
User risk is distinct from sign-in risk. Where sign-in risk assesses a specific sign-in attempt, user risk assesses the overall likelihood that a user account has been compromised – based on accumulated signals over time, including leaked credential detection. A user risk policy that requires password change for high user risk is the appropriate response, because if a credential has been leaked, forcing a password change is the remediation – not just blocking access.
Sign-in risk and user risk are different things. One assesses a specific authentication attempt. The other assesses the account itself. They require different Conditional Access responses.
Identity Protection requires Entra ID P2 licensing for the full risk signal capability. P1 provides some risk detection but the full signals – including leaked credential detection and the complete risk policy capability – require P2. This is a meaningful licensing consideration when designing risk-based Conditional Access, because the value of risk policies depends directly on the richness of the signals feeding them.
Token protection is a newer capability worth understanding as it matures. It binds issued tokens to the specific device and session from which they were requested, preventing token theft and replay – the attack pattern where a stolen access token is used from a different device or network. Token protection policies in Conditional Access can require token binding for specific applications, adding a layer of enforcement that survives the sign-in event. As of the time of writing, token protection is available for specific applications and expanding over time – worth tracking as it reaches broader availability.
These signals – named locations, sign-in risk, user risk, and token protection – complete the picture of what a mature Conditional Access design can evaluate. Device compliance and authentication strength establish the baseline. Risk signals and location awareness add the dynamic layer that makes enforcement responsive rather than static.
Conditional Access
‹ Previous: [CA 2.1] Testing Conditional Access: What-If Analysis and Safe Rollout
Next: [CA 4] The VCIO CA Framework ›
