Investigate and remediate risky Microsoft Entra users with evidence

Source fact: what Microsoft documents

Microsoft Entra ID Protection calculates user risk from active detections and supports both policy-based self-remediation and administrator action. A sign-in-risk policy can require multifactor authentication; successful completion can remediate that sign-in risk. A user-risk policy can require multifactor authentication followed by a secure password change. Microsoft distinguishes that password-change flow from self-service password reset, which is an account-recovery flow for a user who does not know the current password.

If the user cannot satisfy the policy requirement, the sign-in can be blocked and an administrator must investigate and unblock the user. Some detections do not reach the configured threshold or are not automatically remediated, so manual handling remains necessary. Microsoft documents User Administrator as the least-privileged role for password reset, Security Operator for dismissing risk, Security Administrator for risk policies, and Conditional Access Administrator for Conditional Access policies.

Licensing and hybrid boundaries

Full ID Protection capability requires Microsoft Entra ID P2 or Microsoft Entra Suite licensing. Hybrid users have additional dependencies. Microsoft documents on-premises password-change remediation when password hash synchronization is enabled and the tenant explicitly enables the applicable setting. That behavior must be tested before relying on it. Risk data is a security signal, not proof by itself that an account is compromised or safe.

DSE recommendation: production-safe operational steps

1. Capture the detection type, risk level and state, user, time, IP address, location, client, device, application, correlation or request identifiers, and related sign-ins before changing the record.
2. Validate the user’s activity through an independent trusted channel. Do not ask the user to confirm a suspicious session through that same session.
3. If compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation.
4. Use secure password change for the documented user-risk self-remediation flow. Use SSPR or an administrator reset when the user requires account recovery. Review registered authentication methods in either case.
5. Dismiss risk only when the evidence supports a false positive or safe event and record the reviewer, evidence, and reason. A dismissal is an administrative assertion, not containment.
6. Review role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise.
7. Close the event only after access, session, credential, and monitoring actions are verified.

DSE recommends testing risk policies with pilot users, emergency-access exclusions, and help-desk procedures before broad enforcement. If telemetry is incomplete, preserve uncertainty in the ticket and escalate; do not convert a lack of evidence into a claim that no compromise occurred.

Official reference

Remediate risks and unblock users — licensing, least-privileged roles, self-remediation, password flows, hybrid behavior, and manual actions.