What travel speed triggers the impossible travel detection?

500 km/h by default — fast enough to rule out any form of commercial transport while slow enough to handle consecutive sign-ins from different countries with a reasonable time gap. The threshold is configurable, and a minimum distance filter (100 km default) screens out same-city and same-metro VPN noise.

Will legitimate VPN use cause false positives?

Possibly. A user connecting through a VPN exit node in a different country will look like they signed in from that location. The minimum distance filter reduces same-city false positives, but cross-country VPN exits will still trigger if the time gap is short enough. The recommended response is to verify before acting, not block immediately.

Does impossible travel detection work for non-Azure log formats?

Yes. LogTriage falls back to IP-based geolocation from its enrichment pipeline when Azure AD's native location coordinates aren't available, so the same detection logic applies across any log format where source IP is extracted.

How do I confirm a flagged impossible travel event is real and not a VPN?

Compare the deviceDetail between the two sign-ins. A genuine location change typically also shows a different device, browser, or client app. If the device fingerprint is identical but the location jumped, VPN is more likely. If everything changed, treat it as a potential compromise.

Detecting Impossible Travel in Azure AD Sign-In Logs

Why this matters

Impossible travel is one of the highest-confidence account compromise signals available, precisely because it doesn’t depend on guessing attacker intent — it’s pure physics. If the same account signs in from Tel Aviv and then from São Paulo nine minutes later, no commercial flight makes that possible. Either the credentials are shared (a policy problem) or stolen (a security incident), and the sign-in log already contains everything you need to tell the two apart.

Two sign-ins for the same userPrincipalName with location fields implying a physically impossible travel speed
A sudden change in deviceDetail (OS, browser, trust state) alongside the location jump
riskLevelAggregated already flagged by Entra ID’s own risk engine, but not yet acted on
A change in clientAppUsed from a normal interactive browser session to a legacy or non-interactive protocol
conditionalAccessStatus showing success when the policy should have blocked the second location

How LogTriage detects this

LogTriage’s impossible travel detector groups sign-ins per user, computes the haversine distance between consecutive sign-in coordinates, and divides by elapsed time to get implied speed. Anything above 500 km/h (configurable) gets flagged — fast enough to rule out normal travel, slow enough to still catch attackers using VPN exit nodes that aren’t absurdly far apart. Azure AD’s own location coordinates are used directly; for other formats, LogTriage falls back to IP-based geolocation from its own enrichment pipeline, so the same detection logic works even outside Azure AD.

Detection / evidence checklist

Confirm both sign-in locations and the exact elapsed time between them
Check whether the account has MFA enabled, and whether MFA was satisfied on both sign-ins
Review what the account accessed between the two sign-ins — that’s your actual exposure window
Force a password reset and session revocation if compromise is confirmed
Check Conditional Access policy logic — a working policy should have blocked the impossible second sign-in

Frequently Asked Questions

What travel speed triggers the impossible travel detection?: 500 km/h by default — fast enough to rule out any form of commercial transport while slow enough to handle consecutive sign-ins from different countries with a reasonable time gap. The threshold is configurable, and a minimum distance filter (100 km default) screens out same-city and same-metro VPN noise.
Will legitimate VPN use cause false positives?: Possibly. A user connecting through a VPN exit node in a different country will look like they signed in from that location. The minimum distance filter reduces same-city false positives, but cross-country VPN exits will still trigger if the time gap is short enough. The recommended response is to verify before acting, not block immediately.
Does impossible travel detection work for non-Azure log formats?: Yes. LogTriage falls back to IP-based geolocation from its enrichment pipeline when Azure AD's native location coordinates aren't available, so the same detection logic applies across any log format where source IP is extracted.
How do I confirm a flagged impossible travel event is real and not a VPN?: Compare the deviceDetail between the two sign-ins. A genuine location change typically also shows a different device, browser, or client app. If the device fingerprint is identical but the location jumped, VPN is more likely. If everything changed, treat it as a potential compromise.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs