User blocked due to risk on home tenant.

Identity Protection evaluates sign-in and user risk based on signals such as IP, location, and anomalous behavior. When traffic is routed through a cloud proxy like Cisco Umbrella, Microsoft Entra ID sees the proxy’s IP and location (for example, Dublin) rather than the user’s real source IP. This can lead to elevated sign-in or user risk and to users being blocked before Conditional Access policies are evaluated.

Mitigation and prevention options based on the provided context:

1. Adjust risk-based policies and remediation
   • Risk-based policies are configured by risk level and only apply when the sign-in or user risk meets those levels. If detections from the proxy IP are raising risk to a level that triggers blocking, administrators can:
     • Lower acceptable risk thresholds only after careful review, or
     • Adjust policies to require self-remediation instead of blocking, where appropriate.
   • For sign-in risk, configure Conditional Access to require multifactor authentication for medium or high sign-in risk instead of blocking, so users can self-remediate when prompted. If users complete MFA successfully, their sign-in risk is remediated and they can sign in.
   • For user risk, configure a user risk-based Conditional Access policy to require secure password change (or the “Require risk remediation” control) so users can remediate their own user risk instead of being blocked, where this is acceptable for the organization.
2. Enable self-remediation instead of hard blocks where possible
   • Policies that require risk remediation or password change allow users to unblock themselves by completing MFA and/or changing their password. This reduces the need for administrator intervention and helps avoid long-lasting false-positive blocks.
   • If a policy is configured to “Block access” for certain risk levels, users are blocked until risk is addressed by an administrator. Consider changing such policies to require remediation instead of blocking, at least for non-privileged users.
3. Use location-based controls carefully with cloud proxies
   • When a cloud proxy or VPN is used, Microsoft Entra ID evaluates Conditional Access based on the proxy’s IP, not the end user’s IP. The X-Forwarded-For header is not trusted and is not used because it can be spoofed.
   • Location-based policies that block or treat certain regions as risky should be tested carefully in environments using cloud proxies, because all users behind the proxy will appear to come from the proxy’s IP and its geolocation.
   • If location-based blocking is required, consider:
     • Defining named locations for the proxy IP ranges and treating them as trusted locations where appropriate.
     • Using other conditions (for example, device compliance or hybrid join) instead of or in addition to location, which can be easier to manage when a cloud proxy is in place.
4. Consider additional controls for high-risk scenarios
   • For high-risk users (for example, where credentials are suspected to be compromised), configure user risk-based Conditional Access to require password change or risk remediation. This ensures that even if the proxy causes unusual location signals, users must complete a secure remediation flow before regaining access.
   • Administrators can also decide to block access from specific locations or IP ranges if they are known to be malicious, but this should be done with care and thorough testing, especially when those IPs belong to shared cloud proxy infrastructure.
5. Administrative remediation and unblock
   • When users are blocked due to risk and self-remediation is not available or fails, administrators must remediate the risk and unblock users. This may involve investigating the risk detections, confirming that the activity is legitimate (for example, due to the proxy), and then clearing the risk and unblocking the user.
   • For external users, note that user-risk policies requiring password change cannot be resolved in the resource tenant; such users may be blocked if a password change is required and cannot be performed there.

By tuning risk-based Conditional Access policies (favoring MFA/password-change remediation over hard blocks where appropriate), carefully designing location-based policies in the presence of cloud proxies, and using administrator remediation when necessary, organizations can reduce false-positive blocks caused by proxy-based geolocation while still maintaining strong protection against genuine risky sign-ins and compromised accounts.

References:

• Remediate risks and unblock users
• Self-remediation experience with Microsoft Entra ID Protection and Conditional Access
• Risk-based access policies
• Conditional Access: Network assignment
• Require multifactor authentication for elevated sign-in risk
• Authentication and Conditional Access for External ID