How to Investigate Impossible Travel Alerts and Cut False Positives

An impossible travel alert fires when two of a user's logins occur in locations too far apart to be reached in the time between them. The signal is intended to detect account takeover. In practice, most of these alerts correspond to legitimate activity, which is the main reason they take so long to triage.

This article covers the common sources of false positives, a procedure for triaging an impossible travel alert, and the access policies that reduce how often the signal fires.

Five common sources of impossible travel false positives

Before escalating, it helps to know what usually causes the geographic jump. Five patterns account for most benign cases:

• VPN and proxy usage. Users route traffic through a VPN or proxy to secure a connection, which can make a single session look like logins from several dispersed locations.
• Mobile network fluctuations. Switching between Wi-Fi and cellular changes the IP rapidly, and even in-flight Wi-Fi triggers this. Watch the ASN and organization tied to mobile carriers to prune these fast.
• Shared account usage. When several people use one account across regions, the alert fires falsely. Service accounts are the worst offenders; minimize them where you can.
• Content delivery networks. CDNs route traffic through servers worldwide, so a legitimate login can appear to originate from multiple places.
• Business travel. Frequent travelers legitimately sign in from different locations in a short window. Check the employee's role for travel-heavy functions.

{{ebook-cta}}

How to investigate an impossible travel alert

A clean triage usually takes five to ten minutes. Start with IP enrichment to establish whether the source is a VPN, proxy, CDN, or mobile network, which rules out three of the five common false positives at once. Then look up the user: shared and service accounts are easy to spot by their generic names, and your record of truth will show whether the person holds a travel-heavy role, clearing the other two cases.

If the benign explanations do not hold, move deeper into the authentication and session detail:

• Was multifactor authentication used? If so, a malicious actor would have needed to hijack the session, hold separate persistence, run an MFA fatigue attack, or SIM-swap the user.
• Were there repeated MFA attempts in the four hours before a successful login, multiple geolocations or devices in one session, or newly added MFA methods? Did the user authenticate over SMS?
• What actions ran in the session? Anything resembling persistence or access to sensitive data warrants escalation.
• Did the login come from a previously seen, managed device with an MDM or EDR agent? Threat actors rarely use the user's own device, so a confirmed managed asset lowers suspicion.

By the end of that pass you can usually decide with confidence whether to escalate or resolve the impossible travel alert as a false positive.

How to reduce impossible travel alert volume

Impossible travel is one of the less reliable identity signals on its own, so the most effective step is to reduce the alert volume at the source with Conditional Access policies:

• Block logins from countries where you do not do business.
• Block anonymous VPN and proxy services from authenticating.
• Require phishing-resistant multifactor authentication, and enable number matching to reduce accidental approvals during MFA fatigue attacks.
• Prefer biometric methods such as Okta FastPass, and FIDO keys for privileged accounts.
• Avoid SMS as a factor, and remove shared account usage wherever possible.

Most impossible travel alerts are false positives caused by VPNs, mobile networks, CDNs, shared accounts, or routine travel, so triage is largely a process of ruling out the benign explanations before escalating. Tools that automate the enrichment and correlation involved, including AI SOC analysts, reduce the manual effort each alert requires. Request a demo of Prophet AI to see how it handles alert triage and investigation.

Further reading

• How to investigate an Okta security alert
• What is an MFA fatigue attack?
• Alert tuning best practices
• Alert triage and investigation best practices
• SOC metrics that matter

Frequently asked questions

What is an impossible travel alert?

An impossible travel alert fires when a user's two logins are too far apart geographically to be physically possible in the time elapsed. It is an identity signal meant to catch account takeover, but in practice the majority of cases are legitimate activity. Common triggers include VPNs, mobile network changes, shared accounts, CDNs, and business travel, so treat the alert as a starting point for triage rather than proof of compromise.

How do you investigate an impossible travel alert?

Start with IP enrichment to check whether the source is a VPN, proxy, CDN, or mobile network, which clears three of the five common false positives. Then look up the user to rule out shared or service accounts and frequent business travel. If it still looks suspicious, examine the MFA method and history, the session's geolocations and devices, and what actions ran. Typical triage takes five to ten minutes.

Why do impossible travel alerts generate so many false positives?

Most impossible travel alerts are false positives because ordinary network behavior mimics a geographic jump. VPNs and proxies relocate a user's apparent location, switching between Wi-Fi and cellular changes the IP, and CDNs route traffic through distant servers. Shared and service accounts sign in from multiple regions, and frequent travelers move quickly between locations. This is why impossible travel is one of the least efficient identity signals out of the box.

What is the difference between an impossible travel alert and an MFA fatigue attack?

An impossible travel alert is about where logins originate, flagging two sign-ins too far apart to be physical, while an MFA fatigue attack is about how an attacker gets in, flooding a user with push prompts until one is approved. They can intersect: during impossible-travel triage, repeated MFA prompts before a successful login are a strong escalation signal. Investigate the location anomaly first, then follow the authentication trail.

How can you reduce impossible travel alert volume?

Cut the volume at the source with Conditional Access policies rather than triaging every alert. Block logins from countries where you do not operate, block anonymous VPN and proxy authentication, and require strong MFA. Use number matching and biometric methods like Okta FastPass to blunt MFA fatigue, FIDO keys for privileged accounts, and remove shared account usage where possible. Fewer low-value signals lets analysts focus on real threats.