You just got an impossible travel alert in Microsoft 365. A user apparently signed in from two locations too far apart to have physically traveled between them in the time window. Maybe New York and Singapore within 30 minutes. Maybe London and Lagos within an hour.

This guide walks you through exactly what to do next.

What an impossible travel alert actually means

Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) uses behavioral analytics to detect sign-in activity from geographically distant locations within a timeframe that makes physical travel impossible. The system learns normal patterns over time and flags deviations.

This is one of the most common and most useful anomaly detections in the Microsoft 365 security stack. It often serves as an early indicator of:

  • Credential compromise from a phishing attack
  • Token theft where an attacker replays a stolen session token from another location
  • Account takeover where stolen credentials are being used from an attacker's infrastructure
  • Man-in-the-middle attacks where traffic is being proxied through a foreign server

It can also be a false positive. VPN usage, cloud services that route traffic through distant data centers, and mobile users switching between WiFi and cellular networks can all trigger this alert.

Your job is to figure out which one it is.

Step 1: Don't panic, but don't ignore it

Impossible travel alerts have a meaningful true positive rate. Treat every instance as potentially real until you've confirmed otherwise.

Time sensitivity: If this is actual credential compromise, the attacker may already be inside the mailbox reading emails, setting forwarding rules, or exfiltrating data. Speed matters.

Step 2: Gather the alert details

Open the alert in Microsoft Defender for Cloud Apps or Microsoft 365 Defender portal. Collect:

  • User account affected
  • Timestamp of each sign-in
  • Source IP addresses for both sign-ins
  • Geolocations mapped to those IPs
  • User agents (browser/device info) for each sign-in
  • Sign-in result (success or failure)
  • Risk level assigned by Microsoft Entra ID

Write these down. You'll need them for the investigation and for any incident report.

Step 3: Check for obvious false positives

Before escalating, rule out the common benign scenarios:

VPN or proxy usage: Does your organization use a VPN that routes traffic through a different country? Check if the foreign IP belongs to your VPN provider. Corporate VPNs with split tunneling often cause one sign-in to show the user's physical location and another to show the VPN exit node.

Cloud services: Some applications (backup tools, email clients) authenticate through servers in different regions. Check whether the "foreign" IP belongs to a known cloud service like a backup provider or a mail client syncing through a remote server.

Mobile network switching: A user moving from WiFi to a mobile carrier (or vice versa) can generate sign-ins from different geolocations in rapid succession, especially in countries where mobile carriers route traffic through central hubs.

Actual travel: Did the user recently travel? Check with them directly. If they flew from Singapore to Tokyo and signed in from both, the alert is expected.

Shared accounts: If multiple people use the same credentials (a bad practice, but common in SMBs), legitimate users in different locations will trigger this alert.

Step 4: Investigate the suspicious sign-in

If the alert doesn't match a known false positive pattern, investigate further.

Check all sign-in activity for the user in the past 24-48 hours

In Microsoft Entra ID (Azure AD):

  1. Go to Microsoft Entra admin center → Users → select the user → Sign-in logs
  2. Filter by the timeframe around the alert
  3. Look for: unusual IP addresses, unusual locations, different device types, failed sign-in attempts before the successful one

Key signals of compromise

  • Multiple failed sign-ins followed by a success (credential stuffing)
  • Sign-in from an IP address that has never been associated with this user
  • Different user agent strings suggesting a different device or browser
  • Sign-in from a known Tor exit node or anonymizing proxy
  • Successful sign-in followed by mailbox rule changes or large file downloads

Check for mailbox rule tampering

Attackers often create inbox rules to:

  • Forward all emails to an external address
  • Move security notifications to the Deleted Items folder
  • Auto-delete emails from IT or security teams

In Exchange Online:

  1. Go to Exchange admin center → Recipients → Mailboxes → select the user
  2. Check Mailbox features → Mail flow rules or use PowerShell: Get-InboxRule -Mailbox [email protected]
  3. Look for rules you don't recognize, especially those forwarding to external domains

Check for OAuth app grants

Attackers sometimes consent to malicious OAuth apps during a session to maintain persistent access even after a password reset.

In Microsoft Entra:

  1. Go to Enterprise applications → filter by the user
  2. Look for applications with broad permissions (Mail.Read, Files.ReadWrite.All) that weren't approved by IT

Step 5: Contain the threat

If you find evidence of compromise, act immediately:

Revoke all active sessions:

Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

Or in Microsoft Entra admin center: User → Sign-in sessions → Revoke all sessions

Reset the user's password. Use a strong, unique password. Do this from an admin account, not from the user's potentially compromised session.

Require MFA re-registration if you suspect the attacker enrolled their own MFA device. In Microsoft Entra: User → Authentication methods → review and remove any unrecognized methods.

Block the suspicious IP address via Conditional Access if it's clearly malicious:

  • Microsoft Entra → Security → Conditional Access → Named locations → add the IP as a blocked location

Remove unauthorized inbox rules found in Step 4.

Revoke OAuth app permissions for any suspicious applications.

Check for data exfiltration

  • Review SharePoint/OneDrive file access logs for unusual download volumes
  • Check email sending logs for mass forwarding or large attachment sends
  • Review Teams/SharePoint sharing activity

Step 6: Communicate

Notify the user. Let them know their account was flagged for suspicious activity and what actions you've taken. Ask them to verify any recent activity you're unsure about.

Notify your team/leadership if you confirmed compromise. Depending on your organization's size and the data involved, you may have regulatory notification obligations (PDPA in Singapore requires notification within 3 calendar days for notifiable breaches).

Document everything. Timestamps, IPs, actions taken, communications sent. This documentation is critical for compliance and for improving your response process.

Step 7: Prevent recurrence

After containment, shore up the gaps that allowed this to happen:

Enable Conditional Access policies

  • Block sign-ins from countries where your organization doesn't operate
  • Require MFA for all sign-ins (not just "risky" ones)
  • Block legacy authentication protocols (a common bypass for MFA)
  • Require compliant devices for access to sensitive resources

Review MFA coverage

  • Is MFA enforced for all users, including admins?
  • Are you using phishing-resistant MFA methods (FIDO2 keys, Windows Hello) for privileged accounts?
  • Are push-based MFA methods protected against MFA fatigue (number matching enabled)?

Implement sign-in risk policies

  • In Microsoft Entra → Security → Conditional Access → create a policy that requires MFA or blocks access when sign-in risk is medium or high

Set up automated alerts

  • Configure Microsoft Defender for Cloud Apps to send email notifications for impossible travel detections
  • Integrate with your SIEM or security monitoring tool for centralized alerting

When this alert needs escalation

Escalate to a security professional or incident response team if:

  • The compromised account has admin privileges
  • You find evidence of data exfiltration (especially customer data or financial data)
  • Mailbox rules were forwarding email to external addresses for an extended period
  • Multiple users are affected (indicating a broader phishing campaign)
  • You suspect the attacker has persistent access through OAuth apps or other backdoors
  • The breach may trigger regulatory notification requirements under PDPA, GDPR, or other frameworks

How SecurityPulse handles this

For teams without a dedicated security analyst, this entire investigation, from alert triage to containment, can take 2-4 hours per incident. Multiply that by the number of alerts per week and it becomes unsustainable for a lean IT team.

SecurityPulse automates this workflow end-to-end. When an impossible travel alert fires, SecurityPulse:

  1. Pulls the sign-in context (IPs, geolocations, user agents, risk scores)
  2. Cross-references against known VPN ranges, cloud service IPs, and the user's historical sign-in patterns
  3. Checks for correlated indicators (inbox rule changes, OAuth grants, file access anomalies)
  4. Classifies the alert as true positive, likely false positive, or needs human review
  5. For confirmed threats: automatically revokes sessions, triggers password reset, and generates a complete incident report

The same investigation that takes an IT generalist 2-4 hours takes SecurityPulse under 60 seconds.

Related resources