How to Investigate a Suspicious Sign-In in Entra ID

Someone signs in from an IP address in Eastern Europe at 3am. A user shows simultaneous sign-ins from London and Singapore 40 minutes apart. An account that has never signed in outside the UK suddenly authenticates from a VPN exit node in a country your business has no presence in. These are the kinds of signals that land in your inbox and require a decision: is this a compromised account or a legitimate user on a VPN?

Entra ID gives you the tools to answer that question. This guide covers what to look at, how to read the logs, and what to do when you find something that needs acting on.

Investigation Checklist

Work through each phase in order. Tick steps as you complete them - progress is saved in your browser.

Finding the Sign-In Logs

Sign-in logs in Entra ID are accessible from several places depending on whether you are looking at a specific user or reviewing sign-ins across the tenant.

For a specific user:

For all users (tenant-wide):

Sign-in logs are retained for 30 days on P1 and P2 licences. Without a premium licence, retention drops to 7 days. If you need longer retention, configure a Log Analytics workspace diagnostic setting to export logs to Azure Monitor.

Reading a Sign-In Entry

Click any sign-in entry to see the detail view. The fields that matter most for an investigation:

Red Flags to Look For

• Sign-in from a country the user has never been in and has no business reason to be in
• Anonymous proxy or Tor exit node IP - legitimate users rarely connect via Tor
• Repeated failures then success - credential stuffing or brute force that eventually found working credentials
• Sign-in at an unusual time - 3am for someone who has never worked outside 9-5 warrants investigation
• User agent mismatch - signing in from an Android device when the user only has an iPhone
• Legacy auth client - using protocols that bypass MFA (Exchange ActiveSync, IMAP, POP3)
• No MFA challenge completed - a successful sign-in that did not trigger MFA when it should have
• Service principal signing in from an unexpected IP - may indicate stolen app credentials

Impossible Travel

Impossible travel occurs when the same account shows successful sign-ins from two locations that are physically impossible to travel between in the time elapsed. Entra ID Identity Protection detects this automatically, but you can also spot it manually in the logs by sorting by timestamp and comparing consecutive sign-in locations.

Not every impossible travel alert is a compromise - VPNs, corporate proxies, and Defender ATP can generate apparent location anomalies. Always check:

• Does the user use a VPN that might have exit nodes in different countries?
• Is the user travelling? Check with the user's manager or the user directly via a channel other than email (which may be compromised).
• Did one of the sign-ins come from a known corporate IP or proxy?

If none of those explanations apply, treat it as a potential compromise and follow the containment steps in the M365 account compromised guide.

Using Identity Protection Risk Detections

Entra ID Identity Protection (requires P2) aggregates risk signals into user and sign-in risk levels and generates specific detections you can review. Navigate to:

The Risky users report shows accounts with elevated risk. The Risk detections report shows the specific signals - impossible travel, anonymous IP, password spray, leaked credentials, and others.

When an account shows a high risk detection, you can:

• Confirm compromise - marks the account as compromised and triggers remediation workflows
• Dismiss user risk - if you have investigated and confirmed it was legitimate
• Reset password and require MFA - direct remediation action from the portal

Taking Action

If the sign-in looks suspicious and you cannot confirm it was the legitimate user:

1. 1
   Contact the user out-of-band

   Call the user directly or message via Teams (from your admin account, not their account). Ask if they were signing in at that time from that location. Do not email the potentially compromised account.
2. 2
   If you cannot confirm legitimacy, revoke sessions and reset

   Follow the immediate containment steps from the compromised account guide. It is easier to apologise for a false positive reset than to deal with an active compromise.
3. 3
   Check for follow-on activity

   If the suspicious sign-in was successful, run the persistence and audit checks - inbox rules, OAuth permissions, data access - before clearing the incident.