Microsoft Entra ID Protection: Configure risk policies, triage detections and remediate safely

Microsoft Entra ID Protection scores every sign-in and every user for compromise, but the score only protects anyone if risk-based Conditional Access acts on it, analysts triage it correctly, and remediation actually evicts the attacker. Many tenants have P2 licences and still run with the legacy risk policies Microsoft retired on 1 October 2026, dismiss detections in bulk, or exclude the service accounts and hybrid users who are most at risk. This guide covers how ID Protection evaluates user, sign-in and workload identity risk, which roles can see and change it, how to configure the risk policies Microsoft recommends, how to remediate and give feedback without hiding an attack, and the misconfigurations that defeat it. It is for identity engineers and SOC analysts running Entra ID tenants. For the general design of risk scoring and step-up, see the Risk-Based and Adaptive Authentication Guide; for building your own detections from raw logs, see the Entra ID Sign-In and Audit Log Detection Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Legacy risk policies are retired. Microsoft retired the ID Protection user risk and sign-in risk policies on 1 October 2026; risk must now be enforced through Conditional Access policies with user risk or sign-in risk conditions.
• Microsoft's baseline is two separate policies. Require risk remediation when user risk is High, and require MFA with sign-in frequency Every time when sign-in risk is Medium or High; never combine both conditions in one policy.
• Remediation depends on registration. Users must already have MFA registered, and hybrid users need password writeback, or a risky user is simply blocked and lands on the helpdesk.
• Dismiss is not remediate. Dismissing user risk leaves the password and sessions as they were; use Confirm safe for false positives, Dismiss for benign true positives, and Confirm compromised plus revocation for real incidents.
• Workload identities need their own coverage. User-scoped policies do not touch service principals; workload identity risk needs Workload Identities Premium, and Conditional Access for workload identities applies to single-tenant service principals only.

How identity and access work in Entra ID Protection

ID Protection is a risk engine inside Microsoft Entra ID. It runs real-time detections during each sign-in to produce a sign-in risk level, runs offline detections afterwards, and aggregates the results into a user risk level that persists until remediated. Microsoft describes three functions: detect, investigate (through the Risk detections, Risky sign-ins and Risky users reports) and remediate (automatically through risk-based Conditional Access, or manually by an administrator).

Risk types and selected detections

Microsoft's detection reference lists each detection with its API riskEventType, whether it raises sign-in or user risk, and whether it is calculated in real time or offline. A selection, from that reference:

The token detections (anomalous token, attacker in the middle, token issuer anomaly) map to the techniques that defeat MFA: ATT&CK T1539 Steal Web Session Cookie, T1557 Adversary-in-the-Middle and T1606 Forge Web Credentials. Password spray maps to T1110.003 and leaked credentials to T1078.004 Cloud Accounts.

Licensing in one place

Availability: Microsoft's licence matrix gives risk policies, the full Risky users, Risky sign-ins and Risk detections reports, at-risk alerts, the weekly digest, the MFA registration policy and Microsoft Graph access to all risk reports to Entra ID P2 (or Microsoft Entra Suite). Free and P1 tenants see limited reports: Risky users shows only medium and high risk without details or history, and Risky sign-ins shows no risk detail or level. Several detections draw on Defender signals and need the matching licence: Defender for Cloud Apps (impossible travel, new country, mass access to sensitive files), Defender for Office 365 (suspicious inbox rules, suspicious sending patterns) and Defender for Endpoint (PRT access attempts); Microsoft 365 E5 covers these. Workload identity risk detail and risk-based policies need Workload Identities Premium.

Admin roles and privileged access

ID Protection controls whether a compromised account is blocked or waved through, so who can change risk state is as sensitive as who can change Conditional Access. Microsoft's role table:

• Give analysts Security Operator, not Security Administrator. Operators can triage and give feedback; only a small group should change settings such as the on-premises password change option.
• Admin password reset needs two roles. Resetting a password from ID Protection requires Security Operator and User Administrator, which is a reasonable separation for most SOCs.
• Make roles eligible, not permanent. Put Security Operator, Security Administrator and Conditional Access Administrator behind Privileged Identity Management activation. The Entra ID Security Guide covers PIM and protected actions.
• Alert on risk state changes made by people. A compromised Security Operator can dismiss the risk that would block an attacker. Treat bulk dismissals and dismissals on privileged users as events to review.

Integrations, API tokens and service accounts

Workload identity risk

ID Protection evaluates risk for single-tenant, non-Microsoft SaaS and multitenant applications. Managed identities are not currently in scope. All workload identity detections are offline:

Microsoft's configuration guidance is explicit that calls made by service principals are not blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to block a service principal when ID Protection marks it at risk; it applies to single-tenant service principals registered in your tenant, not to multitenant apps, non-Microsoft SaaS or managed identities. Continuous Access Evaluation for workload identities enforces those decisions almost immediately on CAE-capable resources.

Remediating a risky workload identity, per Microsoft: inventory every credential on both the service principal and the application object; add a new credential, preferably an X.509 certificate; remove the compromised credentials (all of them if you believe the identity is compromised); rotate any Key Vault secrets the service principal could read; and use Disable service principal to stop further sign-ins while you investigate. Investigate whether credentials were added (T1098.001 Additional Cloud Credentials), configuration changed or new application roles granted. See the Entra client secrets guidance and the Cloud Workload Identity Guide.

Getting risk data out

• Microsoft Graph: P2 gives Graph access to all risk reports; workload risk is in the riskyServicePrincipals and servicePrincipalRiskDetections collections. Any automation that reads or changes risk is itself a privileged service principal: give it the narrowest Graph permissions, a certificate credential and an owner.
• Diagnostic settings: export risk data to a Log Analytics workspace, a storage account or Event Hubs for longer retention and SIEM correlation. The Microsoft Sentinel ID Protection connector is the native route for Sentinel.
• Defender XDR: administrators can review and act on risk there, and Defender products feed signals back.

Logging and detection

ID Protection is a detection source, so the logging question is how to use its output well.

• Route high user risk on privileged accounts to an incident. Do not wait for the user to self-remediate; a High risk Global Administrator is a security incident.
• Correlate, do not just forward. Join risk detections with sign-in logs on correlation ID, and with your own rules for inbox rule creation, MFA method registration and app consent after a risky sign-in.
• Watch token theft detections closely. Microsoft states that for anomalous token, attacker in the middle, token issuer anomaly, verified threat actor IP and threat intelligence detections, sessions with MFA claims are no longer auto-remediated; a secure password change and fresh MFA are required if a user risk policy applies.
• Know the built-in block. Error 50053 with the message that sign-in was blocked by built-in protections due to high confidence of risk is ID Protection acting without your policy. Microsoft's options are trusted location configuration or moving off legacy protocols.
• Monitor the people who change risk. Alert on Dismiss and Confirm safe actions, especially in bulk, outside working hours, or for privileged users.

Triage and feedback: false positives versus benign positives

Microsoft notes feedback is processed offline and may take time to apply. Using Dismiss for false positives teaches the model nothing; using Confirm safe on a benign pen test suppresses future detections of the same pattern.

Metrics

• Median time from High user risk to remediated or confirmed compromised.
• Percentage of risky users self-remediated versus admin-handled.
• Number of users at risk older than 7 days.
• Percentage of users in scope of risk policies with MFA registered.
• Dismissals per analyst per week, with a sample reviewed.
• Risky workload identities open and mean time to credential rotation.

Hardening baseline

Microsoft's recommended configuration, built in Conditional Access:

How Require risk remediation behaves: it applies only to user risk. For password users it forces a secure password change after MFA and revokes previous sessions; for passwordless users it revokes sessions and forces sign-in again; where Microsoft threat intelligence flags an attacker-added device, the device object is disabled. Block overrides Require risk remediation, which overrides Require password change, so assign each user to only one of these. It is not supported for guests, because session revocation is not supported for them.

Rollout

1. Clear existing risk. Microsoft advises investigating and remediating active risk before enabling policies, otherwise day one blocks every stale risky user.
2. Fix prerequisites. Enforce MFA registration (the MFA registration policy or a registration campaign) and enable password writeback for synced users. Unregistered users facing a risk policy are blocked and need an administrator.
3. Decide the hybrid option. Allow on-premises password change to reset user risk (ID Protection settings) lets hybrid users remediate by changing their password on-premises, including from Ctrl-Alt-Delete; it requires password hash synchronisation and Microsoft recommends MFA before on-premises password changes.
4. Create policies in Report-only. Review policy impact and sign-in logs for a fortnight, then switch to On.
5. Move any legacy configuration. If you still see legacy policy settings, recreate them in Conditional Access; the legacy policies retired on 1 October 2026.
6. Add workload identity policies once Workload Identities Premium is in place, starting with report-only for high-value service principals.

Small versus large tenants: a small tenant can adopt Microsoft's two policies unchanged and rely on self-remediation. A large tenant should add a stricter policy for privileged roles (block at Medium user risk, with SOC review), route risk to the SIEM, and run a weekly review of open risky users and workload identities.

Framework mapping

Common misconfigurations

• Combining user and sign-in risk in one policy. Microsoft explicitly warns against it and says to create a separate policy for each risk condition, because each needs a different grant and remediation path.
• Treating Dismiss as a fix. Dismissing user risk does not change the password or end sessions; an attacker with a stolen refresh token keeps access. After a real compromise, revoke refresh tokens, revoke access tokens through CAE where used, and disable affected devices. See the OAuth Token Theft Incident Playbook.
• Excluding broad groups. Large exclusions for executives, contractors or "service accounts" remove exactly the identities attackers target. Exclude only emergency access accounts, and monitor those separately; see the Break-Glass Account Guide.
• Assuming user policies cover service principals. They do not. Without workload identity policies, a leaked client secret is detected but never blocked.
• No password writeback for hybrid users. Synced users cannot complete the secure password change, so they are blocked and the helpdesk resets passwords outside the remediation flow, which Microsoft notes does not count as secure password change.
• Licence gaps hiding detections. Without P2, risk detail and levels are hidden; without Defender for Cloud Apps or Defender for Endpoint, several detections never fire. Check the matrix before relying on a detection in a runbook.

Practitioner checklist

• Confirm no legacy ID Protection policies remain and both Microsoft-recommended risk policies exist in Conditional Access, as separate policies.
• Exclude only emergency access accounts and alert on their every sign-in.
• Enforce MFA registration before users can hit a risk policy, and enable password writeback for synced users.
• Decide and document the Allow on-premises password change to reset user risk setting.
• Assign analysts Security Operator through PIM; keep Security Administrator to a small, eligible group.
• Write a triage runbook distinguishing Confirm safe, Dismiss and Confirm compromised, with revocation steps for compromise.
• Export risk data to the SIEM and correlate with sign-in, audit and mailbox activity.
• License and enable workload identity risk, and block risky single-tenant service principals with Conditional Access for workload identities.
• Review open risky users and workload identities weekly against the metrics above.

Standards and references

• Microsoft Learn: What is Microsoft Entra ID Protection?
• Microsoft Learn: Risk-based access policies
• Microsoft Learn: Configure and enable risk policies
• Microsoft Learn: What are risk detections?
• Microsoft Learn: Securing workload identities
• Microsoft Learn: Remediate risks and unblock users
• Microsoft Learn: Give feedback on risk detections

Related NHI Mgmt Group resources: Risk-Based and Adaptive Authentication Guide, Conditional Access Guide, ITDR Guide, Entra ID Sign-In and Audit Log Detection Guide.