Identity Protection Risk Policies

Azure AD Identity Protection is a feature of Microsoft Entra ID that detects, investigates, and remediates identity-based risks. It uses machine learning and Microsoft's vast threat intelligence to identify suspicious activities such as leaked credentials, impossible travel, anonymous IP addresses, and atypical sign-ins. Risk policies are automated responses to these detections, allowing administrators to block access or force additional verification (like MFA) when a certain risk level is detected. The goal is to prevent attackers from exploiting compromised identities before damage occurs.

Identity Protection operates by analyzing sign-in events and user behavior in real-time. It assigns a risk level (Low, Medium, High) to each sign-in and to each user based on aggregated detections. The risk level is calculated using a combination of real-time and offline detections. Real-time detections happen at the time of sign-in (e.g., anonymous IP address), while offline detections are processed later (e.g., leaked credentials). The risk levels are:

When a policy is configured, it evaluates these risk levels. For example, a sign-in risk policy might be set to 'Medium and above' to require MFA. The policy is enforced during the authentication process via Conditional Access. Conditional Access evaluates the policy conditions (including risk level) and then applies controls (grant access, require MFA, block access).

- User Risk Policy: Targets users who have been flagged as compromised. Default risk level is 'High'. Actions: Block access or allow access with password change. - Sign-in Risk Policy: Targets individual sign-in attempts. Default risk level is 'Medium and above'. Actions: Block access or allow access with MFA. - Risk Detections: There are two types: - Real-time: Detected during sign-in (e.g., anonymous IP address, atypical travel, unfamiliar sign-in properties, malware linked IP address, password spray, brute force attack). - Offline: Detected after sign-in (e.g., leaked credentials, impossible travel, suspicious inbox forwarding rules, mass access to sensitive files). - Risk Levels: Low, Medium, High. Also 'No risk' and 'Unknown'. - Investigation: Administrators can review risk detections in the Azure portal under 'Security' > 'Identity Protection' > 'Risk detections'. Each detection includes details like detection timing, risk level, and whether it was real-time or offline. - Remediation: Users can self-remediate by performing MFA or changing password. Admins can dismiss risk or confirm compromise. - Timers: Risk detections are stored for up to 30 days. User risk is calculated based on detections within a rolling window (typically 14 days).

Policies are configured in the Azure portal under 'Azure Active Directory' > 'Security' > 'Identity Protection' > 'User risk policy' or 'Sign-in risk policy'. Alternatively, using Microsoft Graph API or PowerShell:

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All", "IdentityRiskEvent.ReadWrite.All"

# Get user risk policies
Get-MgIdentityProtectionUserRiskPolicy

# Update user risk policy to block high risk users
Update-MgIdentityProtectionUserRiskPolicy -UserRiskPolicyId "policy-id" -IsEnabled $true -RiskLevelForRisk "high" -GrantControls @{operator="OR"; builtInControls=@("block")}

For sign-in risk policy:

# Get sign-in risk policy
Get-MgIdentityProtectionSignInRiskPolicy

# Update to require MFA for medium and above
Update-MgIdentityProtectionSignInRiskPolicy -SignInRiskPolicyId "policy-id" -IsEnabled $true -RiskLevelForRisk "medium","high" -GrantControls @{operator="OR"; builtInControls=@("mfa")}

Identity Protection integrates tightly with Conditional Access. Conditional Access policies can include 'Sign-in risk' and 'User risk' as conditions. This allows combining risk with other signals like location, device compliance, and application sensitivity. For example, a policy might require MFA for high-risk sign-ins but only from non-compliant devices. Additionally, Identity Protection feeds into Microsoft Defender for Cloud Apps for session control and investigation. It also integrates with Microsoft Sentinel for advanced threat hunting.

A large enterprise with 50,000 users uses Azure AD Identity Protection to detect leaked credentials. They enable the user risk policy set to 'High' and require password change. When a user's credentials appear on the dark web, Identity Protection flags the user as high risk. The next time the user signs in, they are forced to change their password. This prevents attackers from using stolen credentials. In production, the admin must ensure that the password change flow works seamlessly with self-service password reset (SSPR) enabled. A common misconfiguration is not enabling SSPR, causing users to be stuck and call helpdesk. Scale considerations: For large tenants, risk detections may have a delay of up to 15 minutes for offline detections. The admin should monitor the 'Risky users' report daily to handle false positives.

A global company with users traveling frequently uses sign-in risk policy to block impossible travel detections. Impossible travel occurs when a user signs in from two locations too far apart given the time difference. The policy is set to 'Medium and above' and 'Block access'. A real-world example: A user signs in from New York, then 10 minutes later from Tokyo. The sign-in risk policy blocks the second sign-in. However, legitimate users who use VPNs may trigger false positives. To mitigate, the admin can add trusted locations (corporate IP ranges) to Conditional Access and exclude those locations from the risk policy. The admin must also educate users about the policy to avoid frustration. Performance: The detection is real-time for impossible travel, so blocking happens immediately.

A company wants to require MFA when users sign in from anonymous IP addresses (e.g., Tor, VPN). They create a Conditional Access policy with condition 'Sign-in risk' set to 'Medium and above' and grant control 'Require MFA'. This policy is applied to all users. In production, the admin must ensure that MFA is already registered for all users. If a user has not registered, they will be blocked. The admin should set up a registration campaign to encourage MFA enrollment. A common mistake is not excluding emergency access accounts (break-glass accounts) from the policy, potentially locking out admins. The admin should also use 'Report-only' mode initially to see how many sign-ins would be affected.