Impossible travel: What it is, how it works, and how to defend against it

A person can't be in two places at once. It's one of the few security assumptions you can borrow directly from physics, and it turns out to be a surprisingly powerful one. Impossible travel detection uses this simple constraint to catch credential theft, session hijacking, and account takeover in real time.

This article breaks down how impossible travel detection works under the hood, why it's harder than it sounds, and how WorkOS Radar implements it as part of a broader defense layer for your application.

What impossible travel actually means

At its core, impossible travel detection compares two data points from the same user account: a login at location A at time T₁, and a login at location B at time T₂. If the physical distance between A and B can't be covered in the elapsed time (T₂ − T₁) by any reasonable means of transportation, the second login is flagged as suspicious.

For example: a user authenticates from Chicago at 2:00 PM, and someone uses the same credentials from London at 2:30 PM. Commercial flights take about eight hours. Even the most generous interpretation of that 30 minute window doesn't work. Something is wrong.

The detection isn't trying to prove a breach. It's surfacing a high confidence anomaly. The impossible part does the heavy lifting: you don't need behavioral models or risk scores to know that a human body can't cross the Atlantic in half an hour.

The core algorithm

A basic impossible travel detector follows a straightforward pipeline:

1. ‍Capture login metadata. Every authentication event records a timestamp, the user's IP address, and ideally a device fingerprint. The IP is resolved to a geographic coordinate pair via GeoIP lookup.‍
2. Maintain a location history. For each user, the system stores recent login locations as "visits," each one a tuple of (latitude, longitude, timestamp, device fingerprint, IP metadata).‍
3. Compute geo velocity on each new event. When a new login arrives, calculate the great circle distance to the most recent prior visit using the Haversine formula: d = 2r · arcsin(√(sin²((φ₂−φ₁)/2) + cos(φ₁)·cos(φ₂)·sin²((λ₂−λ₁)/2))). Then divide by the elapsed time to get an implied travel speed.
4. ‍Compare against a threshold. If the implied speed exceeds what's physically possible, typically benchmarked against commercial aviation at roughly 900 to 1,000 km/h, the event is flagged.

This gives you a working detector in a few dozen lines of code. But shipping it to production is where the real engineering begins.

Why naive implementations drown in false positives

The concept is simple. Making it accurate is not. Several common scenarios generate alerts that look like impossible travel but are perfectly benign:

• ‍VPNs and proxies. A user in New York connects through a VPN exit node in Frankfurt. Their next login, without the VPN, resolves to New York. The system sees a Frankfurt to New York jump in seconds.‍
• Mobile network roaming. A user's phone may route through a cellular gateway that geolocates to a different country than where the user physically is, especially on international roaming.‍
• Cloud and corporate NAT. Large organizations route traffic through centralized gateways. An employee sitting in Tokyo may have their traffic exit through a data center in Virginia.‍
• Shared credentials (legitimate). Service accounts or shared dashboards may be accessed from multiple locations by design.‍
• GeoIP inaccuracy. IP geolocation databases are estimates, not ground truth. Accuracy varies widely. City level precision is common for wired ISPs but can be off by hundreds of kilometers for mobile carriers.

A naive detector that fires on every geo velocity violation will produce hundreds or thousands of alerts per day in any organization of meaningful size. Security teams quickly learn to ignore them, defeating the purpose entirely.

Reducing noise: What production systems actually do

Mature impossible travel detectors layer additional context on top of the raw geo velocity check to filter out false positives:

• ‍Device fingerprinting. If both logins come from the same device fingerprint, the "travel" is almost certainly a VPN or proxy artifact, not an attacker with stolen credentials on a different machine. Matching device fingerprints can suppress the alert or lower its severity.
• ‍IP reputation and classification. Tagging IPs as belonging to VPN providers, cloud hosting, Tor exit nodes, or corporate proxies lets the detector treat those logins differently. A login from a known VPN IP followed by a login from a residential IP in the user's home city is a common, benign pattern.‍
• User behavior baselines. Learning each user's normal set of locations over time allows the system to distinguish a frequent traveler who regularly logs in from three countries from an account that has only ever been seen in one city. An "impossible" jump to a location the user visits every week is less suspicious than a jump to a country they've never accessed from.‍
• Session and authentication context. Whether the login used MFA, a passkey, or just a password matters. A geo velocity anomaly on a session that was authenticated with a hardware security key is less likely to be credential theft than one authenticated with a leaked password.‍
• ISP and ASN correlation. Comparing the internet service provider and autonomous system number between the two logins can reveal whether the "travel" is a network routing change rather than a physical relocation.‍
• Aggregation windows. Rather than comparing every pair of consecutive logins, some systems aggregate visits into sessions within a time window. If a user has ten logins from Chicago over two hours and one anomalous login from London, the system compares the London event against the Chicago cluster, not just the single preceding event.

The alert isn't the end. Response matters

Detecting an impossible travel event is only half the problem. What you do with the alert determines whether it actually protects the user.

The most common response strategies form a spectrum from least to most disruptive:

• ‍Log and monitor. Record the event for later investigation but take no immediate action. Useful during tuning, but provides no real time protection.‍
• Notify. Send an email or push notification to the user and/or an admin. The user can self report if the activity wasn't them. This adds awareness without blocking legitimate access.‍
• Challenge. Require the user to complete step up authentication: an OTP sent to their email, an SMS code, or a biometric check. This verifies that the person behind the second login actually controls the account, without fully blocking them.‍
• Block. Reject the authentication outright. The user sees a failure message and must contact an administrator. This is the nuclear option. It provides high security, but also high friction if it's a false positive.

The best systems let you configure which response applies to which detection, and often combine impossible travel signals with other risk indicators before choosing an action.

How WorkOS Radar detects impossible travel

WorkOS Radar is a security layer built on top of AuthKit, WorkOS's customizable login box, powered by Radix. It collects signals from every authentication event and runs them through a detection engine that identifies abusive or anomalous behavior, including impossible travel.

Here's what makes Radar's approach worth examining:

• ‍Zero integration overhead. Radar works with AuthKit out of the box. If you're already using AuthKit for authentication, enabling Radar is a configuration toggle in the WorkOS dashboard. No additional SDK calls, no webhook plumbing, no separate infrastructure.‍
• Device fingerprinting as a foundation. Radar analyzes over 20 device signals to build a fingerprint for each client. This fingerprint is the backbone of Radar's detection logic: it lets the system distinguish between a user switching VPNs (same device, different IP) and an attacker using stolen credentials (different device, different IP). For impossible travel specifically, fingerprinting is what keeps the false positive rate manageable.‍
• Geolocation tracking across authentication requests. Radar tracks the geolocation of each authentication attempt. When subsequent requests come from locations that are geographically distant and the elapsed time makes physical travel impossible, Radar flags the event. The detection is continuous. It's not sampling or batching; every sign in is evaluated against the user's recent location history.‍
• Configurable response actions. When Radar detects impossible travel, you choose the response: block the attempt, challenge the user with an email OTP, or notify users and admins. Challenging with an OTP is particularly effective here because it verifies account ownership without completely locking out a legitimate user who happens to be traveling with a VPN.‍
• Part of a layered detection stack. Impossible travel in Radar doesn't operate in isolation. It sits alongside bot detection, brute force protection, credential stuffing defenses, unrecognized device alerts, stale account monitoring, and repeat sign up detection. These detections compose. An impossible travel event from an unrecognized device on a stale account paints a very different picture than a geo velocity anomaly from a known device.‍
• Custom restrictions and allow lists. Radar supports custom rules for specific user identifiers: IP ranges, user agents, devices, or individual users. If you know your engineering team uses a VPN that exits in three countries, you can allowlist those IPs so they don't trigger impossible travel alerts. The allow list takes precedence over all other rules, giving you an escape hatch for patterns you've verified as legitimate.‍
• Real time dashboard and event drill down. Every Radar event, including impossible travel detections, surfaces in a real time dashboard with filtering by detection type, action taken, user ID, or email. Clicking into an event shows the full metadata: device fingerprint, location, user agent, and IP. This isn't just for audit. It's how you tune your configuration over time, identifying patterns that should be allowed or blocked.

Closing thoughts

Impossible travel detection succeeds because it's grounded in a physical constraint that attackers can't easily circumvent. You can proxy your IP through another country, but you can't make your stolen credentials appear on the victim's device in the victim's city. When paired with device fingerprinting and layered alongside other behavioral signals, it becomes one of the highest signal detections available in identity security.

If you're building an application with AuthKit, Radar gives you impossible travel detection, along with a full suite of authentication threat protections, without bolting on a separate security product. Enable it from the dashboard, configure your response actions, and let the physics do the work.

Learn more at workos.com/radar or explore the Radar documentation.