Detecting Impossible Travel Without Expensive UEBA Tooling

Impossible travel detection has a reputation for being an enterprise-only feature, bundled into UEBA platforms that cost more than the rest of a security stack combined. The underlying math is not complicated, and most identity providers already give you everything you need in the raw sign-in log.

The calculation is the haversine formula — the great-circle distance between two latitude/longitude points — divided by the elapsed time between two consecutive sign-ins for the same account. If that implied speed exceeds what’s physically possible (LogTriage defaults to 500 km/h, comfortably above commercial flight speed but well below “instantaneous”), the pair gets flagged. That’s the entire algorithm. No machine learning model, no behavioral baseline period, no training data.

The harder part isn’t the math — it’s getting clean coordinates. Azure AD sign-in logs include location.geoCoordinates directly, which makes this nearly free for Entra ID. For log formats that don’t carry their own geolocation, the fallback is IP-based geolocation through a standard enrichment pipeline, which is noisier (VPN exits, mobile carrier NAT, and corporate proxies all distort it) but still catches the cases that matter: an account signing in from two countries within minutes is suspicious by any geolocation method, even an imprecise one.

It’s worth being honest about the false-positive sources too: a VPN client switching exit nodes, or a mobile user moving between cell towers near a regional border, can produce a coordinate jump that isn’t actually impossible travel. A minimum-distance filter (LogTriage defaults to 100km) screens out same-metro noise, but no implementation of this check is going to be zero-false-positive — which is exactly why it should feed into an analyst’s report as one risk factor among several, not an automatic account lockout trigger on its own.