{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/microsoft-entra-risky-user-remediation-evidence/", "item": { "id": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "slug": "microsoft-entra-risky-user-remediation-evidence", "url": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-entra-risky-user-remediation-evidence/" }, "title": "Investigate and remediate risky Microsoft Entra users with evidence", "summary": "Microsoft Entra ID Protection can support automatic and manual risk remediation, but each action must follow investigation and preserve the distinction between password change, account recovery, and risk dismissal.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:53+00:00", "modified_at": "2026-07-19T21:27:53+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 436, "potentially_affected": "Microsoft Entra tenants using ID Protection risk detections, risk-based Conditional Access, self-service password reset, password hash synchronization, or hybrid identities.", "dse_recommendation": "Collect the risk and session evidence, validate the user independently, contain suspected compromise, choose the documented remediation path, and record why risk was remediated, dismissed, or left under investigation.", "primary_source": { "name": "Microsoft Learn: Remediate risks and unblock users", "url": "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock", "published_on": "2026-05-27", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

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.

\n

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.

\n

Licensing and hybrid boundaries

\n

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.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  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. \n
  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. \n
  3. If compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation.
    4. \n
  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. \n
  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. \n
  6. Review role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise.
    7. \n
  7. Close the event only after access, session, credential, and monitoring actions are verified.
    8. \n
\n

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.

\n

Official reference

\n

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

", "content_text": "Source fact: what Microsoft documents\nMicrosoft 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.\nIf 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.\nLicensing and hybrid boundaries\nFull 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.\nDSE recommendation: production-safe operational steps\n\nCapture 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.\nValidate the user’s activity through an independent trusted channel. Do not ask the user to confirm a suspicious session through that same session.\nIf compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation.\nUse 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.\nDismiss 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.\nReview role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise.\nClose the event only after access, session, credential, and monitoring actions are verified.\n\nDSE 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.\nOfficial reference\nRemediate risks and unblock users — licensing, least-privileged roles, self-remediation, password flows, hybrid behavior, and manual actions.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft 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.\n\nIf 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.\n\n## Licensing and hybrid boundaries\n\nFull 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.\n\n## DSE recommendation: production-safe operational steps\n\n- 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.\n\n- Validate the user’s activity through an independent trusted channel. Do not ask the user to confirm a suspicious session through that same session.\n\n- If compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation.\n\n- 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.\n\n- 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.\n\n- Review role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise.\n\n- Close the event only after access, session, credential, and monitoring actions are verified.\n\nDSE 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.\n\n## Official reference\n\n[Remediate risks and unblock users](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock) — licensing, least-privileged roles, self-remediation, password flows, hybrid behavior, and manual actions." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo.png" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "url": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-07-19" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Investigate and remediate risky Microsoft Entra users with evidence", "item": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/#article", "identifier": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "url": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/", "headline": "Investigate and remediate risky Microsoft Entra users with evidence", "description": "Microsoft Entra ID Protection can support automatic and manual risk remediation, but each action must follow investigation and preserve the distinction…", "abstract": "Microsoft Entra ID Protection can support automatic and manual risk remediation, but each action must follow investigation and preserve the distinction between password change, account recovery, and risk dismissal.", "articleBody": "Source fact: what Microsoft documents\nMicrosoft 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.\nIf 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.\nLicensing and hybrid boundaries\nFull 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.\nDSE recommendation: production-safe operational steps\n\nCapture 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.\nValidate the user’s activity through an independent trusted channel. Do not ask the user to confirm a suspicious session through that same session.\nIf compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation.\nUse 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.\nDismiss 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.\nReview role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise.\nClose the event only after access, session, credential, and monitoring actions are verified.\n\nDSE 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.\nOfficial reference\nRemediate risks and unblock users — licensing, least-privileged roles, self-remediation, password flows, hybrid behavior, and manual actions.", "datePublished": "2026-07-19T21:27:53+00:00", "dateModified": "2026-07-19T21:27:53+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@id": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": "https://update.dsesecurity.com/assets/dse-updates-share.png", "articleSection": [ "Cybersecurity", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "Microsoft 365 & Identity", "Playbook", "Important priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 436, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Microsoft Learn: Remediate risks and unblock users", "url": "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock", "datePublished": "2026-05-27" } } ] } }