Microsoft 365 impossible travel: investigate and respond
What triggers impossible travel and atypical travel alerts in Microsoft 365 and Entra ID, how to rule out VPN false positives, the sign-in log fields to check, and the response steps when it is real.
An impossible travel alert fires when the same account signs in from two locations too far apart to travel between in the time that passed: Singapore at 09:00 and Lagos at 10:10. It is one of the most common account-takeover alerts in Microsoft 365, and also one of the most common false positives. This is how to tell them apart quickly.
Where the alert comes from
- Microsoft Defender for Cloud Apps (and Defender XDR): the "Impossible travel" anomaly policy, which learns each user's behaviour first.
- Microsoft Entra ID Protection (P2): the "Atypical travel" sign-in risk detection, which raises the sign-in or user risk.
- Your own rules in Sentinel or another SIEM built on
SigninLogs.
Common false positives
- VPNs and secure web gateways (Zscaler, Netskope, consumer VPNs) that exit in another country.
- Mobile carriers that route data through a regional hub in another country.
- Cloud-hosted desktops (AVD, Windows 365, Citrix) in a different region from the user's laptop.
- Background clients such as Outlook mobile, whose sign-ins can come from Microsoft's own infrastructure.
The test: is the "far away" IP owned by a known VPN, carrier or cloud provider your organisation uses, and does the session look like the user's usual device?
What to check in the sign-in logs
Entra admin center > Identity > Monitoring & health > Sign-in logs, filter by the user and the alert window.
| Field | Suspicious when |
|---|---|
| IP address and ASN | Hosting provider, VPS or anonymiser you don't use; IP seen across many unrelated tenants |
| Application | OfficeHome or Exchange Online straight after a phishing email; Azure portal or PowerShell for a non-admin |
| Client app / user agent | Legacy protocols (IMAP, SMTP), python-requests, axios, an unusual browser |
| Authentication details | MFA satisfied "by claim in the token" from a new device (token theft), or many MFA denials before a success (push bombing) |
| Device | Not compliant, not joined, new OS |
| Conditional Access | "Not applied": a gap in your policies |
Adversary-in-the-middle phishing (Evilginx-style kits) steals the session cookie after the user completes MFA. The giveaway is a sign-in from a hosting provider IP, seconds after the user's real sign-in, with MFA marked as already satisfied.
KQL for Sentinel
SigninLogs
| where TimeGenerated > ago(2d) and UserPrincipalName =~ "[email protected]"
| project TimeGenerated, IPAddress, Country = tostring(LocationDetails.countryOrRegion),
AppDisplayName, ClientAppUsed, UserAgent, ResultType, AuthenticationRequirement,
ConditionalAccessStatus, RiskLevelDuringSignIn
| order by TimeGenerated ascIf it is real: respond in this order
- Revoke sessions so stolen tokens stop working: user > Revoke sessions, or
Revoke-MgUserSignInSession -UserId [email protected]. - Reset the password and require MFA re-registration if a method may have been added by the attacker. Remove unknown authentication methods.
- Check the mailbox for new inbox rules (forwarding, moving to RSS Feeds or Archive, deleting), external forwarding and sent items. BEC attackers set these up within minutes.
- Check app consents granted by the user (Enterprise applications > User consent) and revoke unknown ones.
- Search the audit log for what the session did: file downloads, sharing links, mail sent.
- Close the gap: require MFA for all users, block legacy authentication, and consider phishing-resistant MFA (passkeys) for admins and finance.
Prevent the next one
Most impossible travel incidents trace back to the same few gaps: users without MFA, legacy authentication still allowed, risky app consent open to everyone, and no Conditional Access for risky sign-ins. A posture scan finds all of them in a minute.
Run the Microsoft 365 Posture Scanner →
M365 Sign-in Review flags impossible travel, password spraying, legacy auth and MFA fatigue from an Entra ID export, in your browser.