Microsoft 365 user risk: a practical guide for IT | Vahti

Written by Teemu Tapper | Sep 17, 2026, 7:47:19 AM

A risk finding associated with a Microsoft 365 user needs investigation, but does not by itself prove that the account has been compromised. Here is how to separate a finding from a conclusion, investigate a suspicious sign-in and choose the right response.

IT's working day includes user support, device issues and system maintenance. When a security finding appears against a user's account, the first question is practical: does this need immediate action, and what should we check?

The risk level alone will not give you the answer. You need to understand what the finding is based on, what has happened on the account and whether the activity fits the user's work. An investigation needs both technical information and the user's own account of events.

User risk and sign-in risk mean different things

Microsoft Entra ID Protection uses two risk concepts:

  • User risk represents the probability that a user's identity has been compromised. The assessment may be based on risky sign-ins or leaked credentials, for example.
  • Sign-in risk represents the probability that a particular sign-in was made without the user's authorisation.

These are Microsoft's risk assessments. A single suspicious event and the overall state of a user's account are different things. Microsoft explains the distinction in its guide to ID Protection risk detections.

It is also worth distinguishing between terms used by different products. Vahti's risk summary for an individual user is not the same measure as user risk in Microsoft Entra ID Protection. Assess a Vahti finding using its description and the information associated with it. A risk level shown against a user does not mean that Microsoft has confirmed an account compromise.

An example: an unusual sign-in on a finance user's account

Imagine a company with 70 employees where the person responsible for IT is investigating a suspicious sign-in on a finance user's account. The log shows a successful sign-in at 8:12 am. The country and browser shown are unusual for that user.

An unexpected country could be explained by a VPN connection, for example. IT calls the user on a known phone number. The user does not recognise the sign-in and has not started using a new browser. The review also reveals an email rule that forwards messages to an external address the user does not recognise.

In this fictional scenario, there is more to investigate than an unusual location. The findings give IT reason to suspect unauthorised access and begin securing the account. It is still necessary to establish what has been done on the account and which data has been accessed.

How IT can move from a finding to action

1. Establish what the finding relates to

Open the finding's details and record the user, the event time and the reason for the finding. Does it relate to a sign-in, an account security setting or another risk associated with the user? Also check whether the suspicious activity has just happened or the finding refers to an earlier event.

If the information points to ongoing unauthorised access, start securing the account promptly, following your company's response procedure. You do not need to wait until every detail has been investigated.

2. Check the sign-in details

Microsoft Entra's sign-in logs show the user's sign-in events. Open the event you are investigating and check:

  • whether the sign-in succeeded or was blocked;
  • which application and resource were involved;
  • what device, browser, IP address and location information is available;
  • how authentication took place and what the sign-in policies required.

Confirm the time and time zone before comparing events. A location inferred from an IP address is an estimate. It does not tell you with certainty where the user physically is. Microsoft explains these limitations in its guide to sign-in log details.

Also review the multifactor authentication (MFA) details. An MFA requirement satisfied earlier can affect what appears in the new sign-in event. A single field therefore does not tell you the full story of how authentication took place. Microsoft's guide to interpreting MFA events can help.

3. Check with the user and look for other findings

Ask the user about the time, application, device and any travel or VPN use. If you suspect that someone else has gained access to the account, do not rely solely on email or Teams messages sent to that account to verify the sign-in. Use a known phone number, for example.

Compare the user's response with the logs and other events around the same time. Their recollection helps, but does not by itself establish whether the sign-in was authorised. Microsoft's risk investigation guide recommends combining information from the user with technical findings.

In this article's example, the email rule also needs a separate review. Check changes to authentication methods and permissions granted to applications too, if the events give you reason to do so.

4. Secure the account as the situation requires

Where there are reasonable grounds to suspect unauthorised access, the necessary steps may include blocking sign-ins, revoking sessions and changing the password. Also check whether unfamiliar authentication methods or applications have been added to the account. A password change alone will not address unnecessary email forwarding, for example.

Make changes in the appropriate administration environment and follow the requirements of your company's authentication setup. Microsoft's guide to responding to a compromised account covers securing the account and reviewing its settings. The effect of revoking sessions can vary between applications. Microsoft explains the limitations in its guide to revoking user access.

5. Check the result and document your conclusion

Check that the changes took effect and monitor whether suspicious activity continues. Record what was found, what the user confirmed, what was changed and what remains unresolved. If the event turns out to be normal work activity, record the evidence supporting that conclusion.

In the example, the investigation continues after the account has been secured: which messages might the rule have forwarded, and has there been any other unauthorised activity? Simply dealing with the risk entry does not answer those questions.

How does Vahti help you assess a finding about a user?

Vahti brings together Microsoft 365 risk findings and explains in plain language what they mean and how to address them. When investigating a finding about a user, IT should start with its description: what can be concluded from the available information?

Image from Vahti's public demo. The sample user's data shown here is unrelated to the fictional sign-in scenario in this article.

The demo shows how a finding is presented before you choose what to do. An assessment of your own situation must be based on information from your own environment. The availability of Microsoft's risk reports and automated risk policies depends on licensing. Full access to ID Protection requires Entra ID P2 or Microsoft Entra Suite. Risk-based Conditional Access policies require P2. Check Microsoft's current requirements before planning risk policies.

Agree in advance who will investigate findings and who can secure an account in an urgent situation. This makes it clear who is responsible for the investigation, the necessary action and the follow-up.

Explore Vahti's interactive demo to see user findings, email rules, file sharing and application permissions. Learn more about Vahti.