Impossible Travel Alerts: Why They Fire and What to Check First

An alert sits at the top of the queue looking like it has already been decided. The same account signed in from Warsaw at 09:12 and from Chicago at 09:31, and no aircraft covers that gap. The wording reads as a finding rather than a question.

It is a question. Underneath the alert is one division: distance over time. What makes the answer soft is not the arithmetic but both of the numbers going into it, and knowing which part is shaky is the difference between paging someone at midnight and closing the ticket in two minutes.

What the alert is claiming#

Take two sign-in events for one account. Each carries an IP address and a timestamp. Geolocate both addresses, measure the great-circle distance between the two resulting points, divide by the elapsed time, and compare the implied speed against the fastest a person could plausibly move.

The bound everyone picks lands in the same place. Okta's behavior detection uses a Velocity condition with a default threshold of 805 km/h, which is 500 mph. Our own impossible travel calculator uses 800 km/h. Both figures sit around an airliner's cruising speed, which is deliberately generous: no real journey averages that door to door once you count getting to an airport and out of one again. The threshold is meant to be unreachable rather than finely tuned.

Exceed it and one person did not make both connections. That is a genuine signal, and the things it points at are serious ones: a shared password, a stolen session cookie, an attacker who already has working credentials. The claim holds, though, only if each address describes where a human being physically was. That assumption is doing every bit of the work.

Two names, two different detections#

Before triaging one of these, find out which engine produced it. The vocabulary is inconsistent between vendors, and in Microsoft's stack two similarly named detections are genuinely different things.

Microsoft Entra ID Protection ships Atypical travel, which appears in the Graph API as unlikelyTravel. It looks for two sign-ins from geographically distant locations where at least one of the locations is also unusual for that user given past behaviour, and it weighs the elapsed time against how long the trip would take. It is calculated offline rather than in real time, it requires an Entra ID P2 licence, and it will not fire for a brand new user until a learning period has passed: the earliest of 14 days or 10 logins.

Entra also surfaces a detection literally called Impossible travel, with the risk event type mcasImpossibleTravel. That one is not Entra's own work. It comes from Microsoft Defender for Cloud Apps, where the same-named anomaly policy compares user activities across sessions rather than sign-ins alone, and it needs the Defender for Cloud Apps licensing to appear at all.

Okta's version is a behaviour condition rather than a standalone alert. It sits alongside location rules such as sign-in from a new country, and it is normally consumed by a policy that steps up authentication rather than by an analyst reading a queue.

So "impossible travel" in a ticket title tells you almost nothing about what was compared, over what window, or how much filtering it already survived. Establish that first.

The input nobody checks#

An IP geolocation database does not know where a device is. It records which addresses an operator registered and where, infers a location from that, and usually returns a city centroid. Alongside the coordinates it publishes an accuracy radius, which is the vendor's own statement of how far off that point may be.

MaxMind, whose GeoLite2 data sits behind a great many of these lookups, puts country-level accuracy at roughly 99.8%. City level is a different story: for US addresses the published figure is about 66% accurate within 50 km of the stated city. Mobile addresses are harder still. MaxMind notes that addresses used in mobile networks may serve phones across a large distance, and for those it deliberately returns coarser data rather than pretending to know a city. Our guide to how IP geolocation actually works covers where all of that data comes from.

Now put that error into the division. A location error of 150 km across a five-minute gap implies roughly 1,800 km/h of movement. Nobody moved. The uncertainty moved, and a tool reporting a single point estimate turns it into an accusation.

The trap is worst exactly where these alerts are most common: the shorter the time gap, the more the geolocation noise dominates. Two sign-ins forty seconds apart produce an impossible speed from almost any pair of city-level fixes.

Our calculator carries the uncertainty through the arithmetic rather than discarding it. It works out a speed range from the distance plus and minus the combined accuracy radii, then returns one of three verdicts instead of two. Not plausible means even the most generous reading of the data exceeds the threshold. Plausible means even the least generous reading stays under it. Cannot tell means the range straddles the threshold, so the accuracy radii alone would decide the answer. When a lookup comes back with no accuracy radius at all, it assumes 200 km, because unknown precision has to widen the band rather than narrow it.

Where the premise breaks outright#

Geolocation error is the soft failure. These are the hard ones, where the address never described a person's location in the first place and no amount of error bars recovers the situation.

• A VPN or proxy. The user appears wherever the exit node is. Connecting or disconnecting looks identical to instantaneous travel. Check both addresses with the VPN and proxy check before reading anything into a verdict.
• Carrier-grade NAT. Mobile operators share one public address among many subscribers and can move a subscriber between egress points without the subscriber going anywhere. RFC 6598 set aside 100.64.0.0/10 for the inside of those deployments, and our explainer on NAT covers what the arrangement takes away.
• Corporate egress. A laptop on the office network reports the office. The same laptop on home broadband an hour later reports a different city. Both readings are correct and neither is a journey.
• Roaming and satellite links. These frequently geolocate to the operator's home country rather than to wherever the subscriber is standing.
• Private and reserved addresses. An RFC 1918 address has no physical location at all; see the private ranges explained. Our calculator refuses to assess a pair containing one instead of guessing.

None of these is exotic. Between them they describe a large slice of an ordinary workforce on an ordinary Tuesday, which is why a travel verdict is a triage aid rather than evidence.

What the platform already filtered out#

Knowing what the vendor suppressed before the alert reached you changes how much weight it deserves.

Defender for Cloud Apps applies a seven-day learning period per user, and it computes location at country or region granularity, so it raises nothing for two activities in the same country or in bordering ones. A sensitivity slider controls three layers of suppression: system, tenant and per-user. Below the highest setting, travel is trusted when the addresses on both sides are considered safe, such as when both are tagged corporate. It also skips failed logins and non-interactive logins entirely.

Entra's atypical travel does something similar in spirit, ignoring VPNs and locations used regularly by other people in the same organisation.

Two consequences follow. An alert that reaches your queue has already cleared several filters, so it deserves more attention than the raw arithmetic would suggest. And the false positives that remain are, by construction, the awkward ones the filters were never built to catch.

A triage order that holds up#

1. Recover the raw pair. Both addresses, both timestamps, in a form you can read. The alert summary is a rendering; the underlying sign-in log is the evidence.
2. Ask what the addresses are before asking where they are. Run each through the VPN and proxy check and the IP infrastructure classifier. A hosting, VPN or Tor exit on either side means the travel question was never answerable.
3. Then do the arithmetic, with error bars. Paste the pair into the impossible travel calculator. Any verdict from it should be read as "this pair is worth a closer look" and never as a conclusion.
4. Look at what the session actually did. An inbox rule created, an MFA method registered, an OAuth grant, a mass download. Behaviour settles these cases; geography rarely does.
5. Widen to the rest of the day. Pull every address the account touched and rank them, which is what our log IP triage tool is for. One impossible hop in an otherwise ordinary day is easy to miss by eye, and a pattern of hosting addresses is more telling than any single pair.

Notice that steps one and two both come before the distance calculation. That ordering is the entire lesson.

The most useful answer is often "I cannot tell"#

Analysts are trained to reach a verdict, and a tool that declines to give one can feel like a tool that has failed. The opposite is true here.

For most short gaps the honest answer really is that the data cannot decide. Reporting that plainly costs you nothing, because the follow-up action is the same as for a weak positive: check what the addresses are, check what the session did, move on. Reporting a false "impossible" costs an hour of investigation and, eventually, an analyst who stops reading this alert class at all. Alert fatigue is usually described as a volume problem. More often it is a precision problem that produced the volume.

What a travel verdict is worth#

Treat a "not plausible" result the way you would treat any other single indicator: as a reason to enrich and look closer, not as a finding you can write up. The same logic applies to an address that turns up in a firewall log, and what an indicator of compromise actually tells you covers that side of it. On its own, one indicator establishes very little.

What makes travel alerts feel more conclusive than they are is that the underlying arithmetic is unarguable. Distance over time is not in dispute. The dispute is whether either point was ever where the database said, and on a workforce with phones, VPNs and home broadband, the answer is frequently no.

Check what the addresses are first. The geography is the last question worth asking, not the first.