Notifications
Clear all
Topic starter
06/06/2026 11:17 am
TL;DR: Impossible travel detection compares login time and location to flag credential theft, session hijacking, and account takeover, but it only works when teams layer device fingerprints, IP reputation, user baselines, and contextual response actions, according to WorkOS. The control is useful, but only if identity teams treat it as an anomaly signal, not proof of breach.
NHIMG editorial — based on content published by WorkOS: Impossible travel: What it is, how it works, and how to defend against it
By the numbers:
- A login from Chicago at 2:00 PM followed by one from London at 2:30 PM implies a travel distance commercial flights cannot cover.
- Radar analyzes over 20 device signals to build a fingerprint for each client.
- Impossible travel detectors benchmark speed against commercial aviation at roughly 900 to 1,000 km/h.
Questions worth separating out
Q: How should security teams use impossible travel detection without creating alert fatigue?
A: Use impossible travel as one signal in a layered identity risk model, not as a standalone verdict.
Q: Why does impossible travel matter for IAM programmes beyond human login security?
A: Because the same trust problem appears whenever a credential can be reused from a different context.
Q: What breaks when impossible travel rules rely on IP location alone?
A: They break in environments that use VPNs, roaming carriers, cloud NAT, or shared egress points.
Practitioner guidance
- Pair impossible travel with device fingerprinting Require the detector to compare client fingerprints, not just IP geolocation, before escalating an alert.
- Tune thresholds by user mobility profile Separate frequent travellers, remote workers, and shared operational access into different policy buckets.
- Escalate with step-up before blocking by default Use challenge actions such as email OTP or stronger authentication when the anomaly is plausible but not yet conclusive.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Implementation notes on geolocation comparison, Haversine distance, and geo velocity thresholds for sign-in events.
- WorkOS Radar configuration details for block, challenge, and notify actions tied to impossible travel detections.
- Device fingerprinting and allow-listing guidance for VPN-heavy environments and shared corporate egress paths.
- Dashboard drill-down behaviour showing the fields used to tune false positives over time.
👉 Read WorkOS's article on impossible travel detection and Radar →
Impossible travel detection: are your login signals strong enough?
Explore further
06/06/2026 11:59 am
Impossible travel is a control for stolen access, not a control for trust. The detector works because it challenges a simple identity assumption: a login observed in one place can be treated as the same actor seen again a few minutes later somewhere else. That assumption fails fast when credentials are stolen, replayed, or proxied through another network path. Practitioners should treat impossible travel as an identity-risk indicator that helps separate benign mobility from account abuse.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- A separate finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
A question worth separating out:
Q: How do you know if impossible travel detection is actually working?
A: Look for a small number of high-confidence alerts that correlate with device change, suspicious IP reputation, or follow-on account abuse, not just raw alert volume. If analysts keep dismissing the signal as a VPN artifact, the policy is too broad. Effective tuning reduces noise while still catching improbable credential use.
👉 Read our full editorial: Impossible travel detection exposes the limits of login-based trust
