The Impossible Travel Problem
Your user signed in from New York at 9:00 AM, then from London at 9:15 AM. Physically impossible. Must be a compromised account, right?
Not so fast. In reality, 90%+ of impossible travel alerts are false positives. VPNs, corporate proxies, mobile carrier IP changes, cloud applications, and legitimate travel with cached sessions all trigger these alerts. Without automated triage, your SOC drowns in noise while real threats slip through.
Why Impossible Travel Creates So Many False Positives
Understanding why false positives happen is the first step to automating them away. Here are the most common causes:
VPN and Proxy Traffic
User connects to corporate VPN (shows as HQ location), disconnects, then uses local internet (shows as home location). Instant "impossible travel."
Mobile Carrier IP Changes
Mobile carriers route traffic through geographically distributed gateways. User's phone can appear to jump cities without moving.
Cloud App Proxies
Services like Zscaler, Cloudflare Access, and cloud-based security tools proxy traffic through global data centers, masking true location.
Cached Sessions + Travel
User's laptop has cached credentials from home (New York). Lands in London, opens laptop, and token refresh shows "instant" location change.
The Key: Correlating Multiple Risk Signals
Impossible travel alone is a weak signal. The automation magic happens when you correlate it with other risk indicators to separate real threats from noise.
Risk Signal Correlation Matrix
| Impossible Travel + | Risk Level | Recommended Action |
|---|---|---|
| Known VPN/proxy IP | Low | Auto-dismiss, log for audit |
| Familiar device + successful MFA | Low | Auto-dismiss, log for audit |
| New device, successful MFA | Medium | Monitor session, flag for review |
| New device + MFA fatigue pattern | High | Revoke session, require re-auth |
| Failed MFA + password spray source IP | Critical | Block user, force password reset |
| Tor exit node or anonymizer | Critical | Block session, investigate immediately |
| Sensitive data access post sign-in | Critical | Revoke session, quarantine account |
Automated Triage Workflow
Here's a practical workflow that filters 90%+ of false positives automatically while escalating real threats for immediate containment:
Ingest Alert
Receive impossible travel or risky sign-in alert from Microsoft Entra ID Protection, Okta, or your IdP. Extract: user, source IPs, timestamps, device info, sign-in result.
Check Known Good IPs
Query your allowlist of corporate VPNs, proxies, and cloud security egress IPs. If either IP matches, auto-dismiss with "known infrastructure" tag.
Enrich with Threat Intelligence
Check IPs against threat feeds. Flag if either IP is a known Tor exit node, VPN anonymizer, bulletproof hosting, or on a recent password spray source list.
Check Device Familiarity
Query sign-in history. Is this a device the user has used before? Familiar device + new location is much lower risk than new device + new location.
Verify MFA Status
Check how authentication succeeded. Strong MFA (FIDO2, authenticator app) is lower risk. MFA fatigue pattern (multiple failed pushes then success) is high risk.
- FIDO2 security key
- Authenticator app (single prompt)
- Windows Hello
- SMS OTP (SIM swap risk)
- 3+ push attempts before success
- MFA bypassed or not required
Calculate Risk Score and Act
Sum risk points from all checks. Route to automated action based on threshold:
Containment Actions by Severity
When automated triage identifies a real threat, containment must be immediate. Here are the actions to automate at each severity level:
Medium Risk: Soft Containment
Automated Actions
- Require step-up MFA for current session
- Send Slack/Teams notification to user
- Enable enhanced session logging
- Queue for analyst review within 4 hours
User Notification
High Risk: Active Containment
Automated Actions
- Revoke current session tokens
- Force re-authentication with MFA
- Temporarily restrict to known locations
- Alert SOC for immediate review
Analyst Tasks
- Review sign-in logs for past 24 hours
- Check for mailbox rules or OAuth grants
- Verify with user via out-of-band channel
Critical Risk: Full Lockdown
Automated Actions (Immediate)
- Revoke ALL active sessions
- Disable sign-in (block account)
- Reset refresh tokens
- Revoke OAuth app consents (last 24h)
Investigation Actions
- Collect UAL logs for forensics
- Check for data exfiltration
- Review mailbox forwarding rules
- Contact user via phone (not email)
Beyond Impossible Travel: Other Risky Sign-In Types
Impossible travel is just one signal. Here are other risky sign-in patterns to automate triage for:
| Sign-In Type | What It Indicates | Auto-Triage Check |
|---|---|---|
| Unfamiliar location | First sign-in from this geo | Check if user travel is scheduled (calendar) |
| Anonymous IP | Tor, VPN anonymizer detected | Is user in a role that requires anonymity? |
| Leaked credentials | Password found in breach dump | Force password reset, revoke sessions |
| Password spray | Many accounts, few passwords | Block source IP, notify all affected users |
| Malware-linked IP | IP associated with C2 traffic | Block immediately, isolate device |
| Suspicious inbox activity | Rules created post-login | Correlate with risky sign-in, escalate if match |
Implementation Checklist
Build your Known Good IP list
Document all corporate VPNs, proxies, cloud security egress, branch offices. Update quarterly.
Integrate threat intelligence feeds
Connect Tor exit node lists, commercial VPN IPs, password spray source feeds.
Define risk scoring thresholds
Start conservative (higher thresholds for containment), tune based on false positive rate.
Create VIP exception list
Executives and frequent travelers may need softer containment with human approval.
Test containment actions in audit mode
Run for 2 weeks logging what would happen without taking action. Validate accuracy.
Build user notification templates
Clear, non-alarming messages that explain what happened and what the user should do.
Automate Impossible Travel Triage with BitLyft AIR
BitLyft AIR comes with pre-built impossible travel and risky sign-in playbooks that integrate with Microsoft Entra ID, Okta, and other identity providers. Filter 90%+ of false positives automatically and contain real threats in seconds.
Frequently Asked Questions
What percentage of impossible travel alerts are typically false positives?
In most organizations, 90-95% of impossible travel alerts are false positives caused by VPNs, proxies, mobile carriers, and cloud services. This is why automated triage is essential—manual review at this volume is impossible.
Should we auto-block on impossible travel, or always require human review?
Never auto-block on impossible travel alone. It must be correlated with other risk signals (Tor exit node, MFA fatigue, new device) to justify automatic containment. Soft containment (require re-auth) is safer than hard containment (block account) for medium-risk scenarios.
How do we handle VIPs who travel frequently?
Create a VIP list with softer containment policies. For these users, impossible travel triggers monitoring and notification rather than session revocation. Require human approval before any disruptive action. Consider integrating with travel booking systems to pre-approve expected locations.
What's the difference between Microsoft Entra ID Protection and a third-party ITDR solution?
Entra ID Protection provides basic risk detection and Conditional Access integration, but limited customization and cross-platform visibility. Third-party ITDR solutions like BitLyft AIR offer deeper correlation, custom playbooks, multi-IdP support, and more granular automated response options.
Related Articles
ITDR: Practical Guide for Small SOC Teams
Complete identity threat detection and response implementation for lean security teams.
Microsoft Entra ID Account Takeover Playbook
Step-by-step response playbook for confirmed account compromise in Entra ID.
Automated Identity-Based Response
Containment actions that stop account takeover fast—from session revocation to full lockdown.
Guardrails to Avoid Client Impact
Approvals, rate limits, safe-mode, rollback, and blast-radius controls for safe automation.