Microsoft Entra risky users

Investigate Risky Users with the Customer Context You Need

Connect identity-risk signals to the right customer, account and investigation. Review available Microsoft Entra evidence, check account state, and coordinate supported response actions without treating a risk label as the whole story.

For administrators and MSP technicians. Availability depends on your installed MSPControl version, connected Microsoft services, permissions, licenses and configured ticket workflow.

IdentifyMatch the customer, user and risk signal.

InvestigateCheck available detections and sign-in context.

RespondChoose justified, authorized actions.

VerifyConfirm account, Microsoft risk and ticket state separately.

What Are Microsoft Entra Risky Users?

A Microsoft Entra risky user is an identity that Microsoft Entra ID Protection considers potentially compromised. Sign-in risk relates to an individual authentication attempt; a risk detection is a contributing signal. MSPControl brings supported risk records, directory state and ticket context into customer operations. It does not replace Microsoft’s risk engine or make a risk label proof of compromise.

The operating workflow

Move from a Risk Signal to a Verified Decision

Confirm the customer and identity

Match the organization, user principal name and Microsoft object identity. Separate a stored MSPControl risk record from the current Microsoft Entra assessment. Check when the evidence was collected.

Check evidence availability first

Confirm the tenant connection, required permissions, Microsoft licensing and query window. Inspect collection errors. An empty dashboard or Risk History tab does not prove there is no risk.

Investigate the event in context

Review available detection time, type, risk level and state, activity, IP address and location. Compare relevant sign-in details with expected user activity using a trusted contact channel. A failed attempt and a successful unauthorized sign-in require different interpretation.

Choose the appropriate response

If compromise is suspected, use the established incident-response process. MSPControl supports account and session actions in the relevant user workflow, subject to permissions and environment. Preserve evidence while containing access; do not wait for a perfect report if active harm is occurring.

Record the decision and follow-up

Keep the evidence, investigator decision and action results in the incident record. Where ConnectWise integration and risk-ticket settings are configured, use the linked ticket workflow. Do not clear a record just to remove an alert.

Verify each resulting state

Check task errors and the resulting account/session state. Review Microsoft Entra risk separately from the MSPControl record and ticket status. Restore access only after the approved recovery checks are complete.

What MSPControl supports

Know Which Surface You Are Reviewing

The dashboard, per-user risk history, API/AI reads and response controls serve different parts of the investigation.

Customer and ticket context

The Risky Users dashboard lists stored risk-ticket records for organizations available to the operator. It includes customer/user identity, creation time, ticket priority and link, Active/Cleared/All filters, and AD/Entra account-state checks.

Per-user Risk History

The user’s Risk History tab displays available Entra detections: time, event type, risk level, risk state, activity, IP address and location. Its query requests a 90-day lookback; this is not a guarantee that Microsoft retains or returns 90 days of evidence.

Additional API/AI evidence

Supported API/AI read actions expose risky-user, risky-sign-in and risk-detection information for the selected organization or user. Available results depend on Microsoft permissions, licensing, filters and collection limits; the reads are not a promise of an autonomous investigation.

Response and ticket coordination

Supported user workflows include session revocation, password and disable-user actions. Risk policies can filter detections and sign-ins; configured ConnectWise integration provides risk-ticket handling. Each action still needs an appropriate decision and result verification.

Current boundary: The dashboard is backed by the risk-ticket workflow, not a complete live inventory of every Entra risk. Current Graph risk reads are bounded to a single page of up to 500 records per request. Removing a risky-user record follows the ticket-close path and can also dismiss Entra user risk for matching ticket types. Dismissal is not credential cleanup, session containment or proof that an account is safe.

Interpretation and coverage

Separate Risk, Access and Case Status

Surface or signal What it tells you What it does not prove
Microsoft user risk Microsoft’s assessment of potential identity compromise. That a particular remediation action has succeeded.
Sign-in risk and detections Signals about authentication attempts and related activity. That every flagged attempt was successful or malicious.
AD and Entra account state Whether the account appears enabled, disabled or unmapped in the checked directory. That every existing application session is terminated.
MSPControl Active/Cleared record The stored risk-ticket workflow state. The current Microsoft risk state or complete tenant coverage.
Ticket closure or risk dismissal That a workflow status was changed, with Microsoft dismissal on the applicable close path. That credentials, persistence or unauthorized sessions have been addressed.

Configuration and next actions

Open the Guide That Owns the Next Step

Common questions

Microsoft Entra risky users FAQ

What is the difference between a risky user and a risky sign-in?

User risk assesses whether an identity may be compromised. Sign-in risk concerns an individual authentication attempt. Risk detections contribute evidence to those assessments. Investigate the details rather than treating the labels as interchangeable.

Does MSPControl show every risky user across all tenants?

No complete-coverage claim is made. The cross-customer dashboard uses stored risk-ticket records within the operator’s accessible organizations. Per-user history and API/AI reads have their own permissions, licensing, filters and collection limits.

Does removing a user from the Risky Users dashboard remediate the account?

Not by itself. The action uses the risk-ticket close workflow, clears the stored risky flag and may close the ticket when configured. For a matching risky-user ticket it can also request Microsoft risk dismissal. Dismissing risk does not reset a password or remove attacker persistence. Investigate first and verify every intended action.

Which Microsoft Entra license is required?

Microsoft states that Entra ID P2 or Microsoft Entra Suite is required for full ID Protection access. Some information is more limited at other tiers. Check the current Microsoft licensing table, the user’s entitlements and the permissions required by each report or action; do not infer availability solely from an MSPControl menu.

Why can Risk History be empty?

There may be no returned detections, but missing identity mapping, permissions, licensing, retention, filters or collection failure can also explain an empty result. The current user-history query requests 90 days and the underlying risk reads are capped. Confirm evidence availability in Microsoft before interpreting an empty list.

Can VirtuBot help with the investigation?

MSPControl exposes supported identity-risk reads through API/AI and connects risk records with security-ticket workflows. Use the configured VirtuBot workflow where available, but verify the returned evidence and action results. This page does not promise autonomous remediation for every alert or customer.