Static Conditional Access checks are easy to bypass with residential proxies and stolen credentials. Risk-based policies evaluate session and identity posture continuously.

Preface

Traditional CA evaluates simple static conditions at sign-in. That is not enough when attackers spoof trusted networks or reuse leaked credentials. A policy that says "require MFA outside the office" or "block sign-ins from these countries" answers the question of where a request appears to come from. It does not answer whether the request looks like the real user.

Risk-based Conditional Access adds that second question. Entra ID Protection scores each sign-in and each user, and Conditional Access uses those scores as conditions. This requires Entra ID P2 (or a suite that includes it) for the users in scope.

Problem

Residential proxies can masquerade as local ISPs and bypass geo-based rules. Static policies may not demand stronger MFA or block unrecognized devices when risk is elevated.

How the attack works in practice

Commercial residential proxy networks route traffic through consumer connections in almost any city. An attacker who has bought or phished a password chooses an exit node in the victim's own country, often the same metropolitan area, so country blocks and "unfamiliar location" heuristics see nothing unusual. If the tenant trusts a named location broadly, or only asks for MFA once per device, the attacker may face a single push prompt or an SMS code, both of which are routinely relayed or fatigued.

What these sign-ins still tend to carry are signals that ID Protection does evaluate: a known malicious or anonymizing IP, unfamiliar sign-in properties for that user, impossible travel relative to the user's real session, password spray patterns, credentials found in leak data, or anomalous token behavior after an adversary-in-the-middle capture. Risk policies let you act on those signals at the moment they appear.

Solution

Align with NIST SP 800-207 and Entra ID Protection:

  1. Sign-in risk policies: Require phishing-resistant MFA for medium/high risk sessions. Use an authentication strength rather than plain "require MFA", and set sign-in frequency to every time so a remembered session does not satisfy the control.
  2. User risk policies: Force secure password change on high user risk. Where the grant control is available in your tenant, "require risk remediation" also handles passwordless users, for whom a password change does not remove the risk.
  3. Device compliance: Require Intune-compliant devices for corporate resource access, so a valid credential and MFA on an attacker's machine are still not enough.

Design guidance

  • Build these in Conditional Access, not legacy ID Protection policies. The legacy user and sign-in risk policies are being retired; Conditional Access gives you report-only mode, exclusions, authentication strengths and session controls.
  • Make remediation self-service. Users can only clear their own risk if they have already registered strong methods and, for hybrid accounts, if password writeback is enabled. Otherwise every detection becomes a help desk ticket.
  • Block high sign-in risk for privileged roles. For administrators, a challenge may not be enough. Block and investigate.
  • Treat trusted named locations carefully. Marking a location as trusted lowers risk scoring and can exempt sign-ins from controls. Trust only egress IPs you own, never whole countries or provider ranges.
  • Exclude break-glass accounts and monitor them separately. Workload identities need their own policies; user risk does not apply to service principals.

Implementation steps

  1. Confirm licensing for every user in scope, and that ID Protection detections are visible in the risky sign-ins and risky users reports.
  2. Run a registration campaign so users have phishing-resistant or at least app-based methods before enforcement.
  3. Create the sign-in risk policy (medium and high) and the user risk policy (high) in report-only mode, scoped to all users with break-glass exclusions.
  4. Review two to four weeks of report-only results: who would have been challenged, from which apps, and whether any blocked flows are business-critical.
  5. Enable for a pilot group, then all users. Add a separate block policy for high sign-in risk on privileged roles.
  6. Document the triage process: who reviews risky users, when risk is confirmed compromised, and when it is dismissed.

PowerShell: Review Conditional Access Policies

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Conditions | Format-Table

To see which policies actually use risk conditions, and whether they are enforced or still in report-only mode:

Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.Conditions.SignInRiskLevels -or $_.Conditions.UserRiskLevels } |
    Select-Object DisplayName, State,
        @{n = "SignInRisk"; e = { $_.Conditions.SignInRiskLevels -join "," }},
        @{n = "UserRisk";   e = { $_.Conditions.UserRiskLevels -join "," }} |
    Format-Table

Monitoring and detection

The most important question is whether risky sign-ins are succeeding without a strong challenge. In Microsoft Sentinel:

SigninLogs
| where TimeGenerated > ago(7d)
| where RiskLevelDuringSignIn in ("medium", "high")
| where ResultType == "0"
| summarize SignIns = count(), Apps = make_set(AppDisplayName), IPs = make_set(IPAddress)
    by UserPrincipalName, RiskLevelDuringSignIn, AuthenticationRequirement, ConditionalAccessStatus
| order by SignIns desc

Rows with singleFactorAuthentication or a Conditional Access status of notApplied show gaps in policy scope. To understand which detections drive your risk volume, summarize the AADUserRiskEvents table by RiskEventType and RiskLevel; a tenant dominated by one detection type usually points to a tuning issue, such as a missing named location for a VPN egress.

Also track users who stay at high risk for days. Risk that is never remediated or dismissed means either the self-service path is broken or nobody owns triage. The AADRiskyUsers table gives you that view.

Common mistakes

  • Requiring generic MFA on risky sign-ins, which an adversary-in-the-middle kit can relay.
  • Enforcing user risk password change for users with no registered methods or no password writeback.
  • Leaving policies in report-only mode indefinitely.
  • Dismissing risk in bulk to clear the dashboard without investigating.
  • Excluding large groups, such as all contractors, because of a single failed rollout.
  • Relying on country blocks as a primary control.

Where to start

Run the PowerShell review to see what risk-based policies exist today, then deploy the Sentinel query to measure how many risky sign-ins succeed without a strong challenge. Create the sign-in and user risk policies in report-only mode, fix registration and writeback gaps, and enforce. Add device compliance for corporate resources as the third layer once the first two are stable.