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.
Platform capabilities
Manage Microsoft cloud services, Windows devices, security, documentation, backup, and support from one self-hosted platform.
Microsoft Entra risky users
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.
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
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.
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.
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.
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.
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.
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
The dashboard, per-user risk history, API/AI reads and response controls serve different parts of the investigation.
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.
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.
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.
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.
Interpretation and coverage
| 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
Common questions
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.
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.
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.
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.
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.
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.
Self-hosted. Free license available. No credit card required.