Impossible travel detection identifies sessions where a user's location shifts faster than physically achievable. If an account logs in from London at 09:00 and then from Singapore at 09:15, the session is flagged: no direct flight covers that distance in 15 minutes. The signal is simple. What determines whether it is useful is how the system handles VPNs, shared infrastructure, real travelers, and AI agents reusing stolen tokens.
What counts as impossible travel
The core calculation is distance divided by time. If the required speed exceeds a reasonable threshold, typically around 800 km/h as a generous upper bound for commercial flight, the movement is flagged as physically implausible.
| Scenario | Distance | Time gap | Speed | Verdict |
|---|---|---|---|---|
| London to Paris | 340 km | 25 min | 816 km/h | Flag |
| London to Manchester | 260 km | 40 min | 390 km/h | No flag |
| New York to London | 5,540 km | 2 hours | 2,770 km/h | Flag |
| Same city, VPN change | 0 km | instant | 0 km/h | Needs context |
Time is what separates this from simple geolocation. An account active in one place and then another an hour later might be a VPN switch, a mobile handoff, or a genuine traveler on a short flight. Speed resolves most ambiguity, but not all of it.
Where IP-only detection fails
Standard impossible travel logic compares two IP geolocations. That works when the IPs represent real geographic origin. It breaks in these situations:
- VPN switches change the apparent location without any physical movement.
- Residential proxies make attacker traffic look like it originates from a home connection near the target.
- Shared corporate egress puts many users in one location regardless of where they physically are.
- Mobile network roaming shifts IP country assignments as the carrier hands off cells.
False positives in these cases are expensive. A real user flagged while traveling, switching VPN servers, or connecting through a corporate network creates friction without catching an attacker.
What the browser layer adds
Device fingerprinting changes what "same user" means. Instead of asking whether the IP matches the expected location, you can ask whether the device matches the account's history, and whether the browser environment looks like a real user or an automation framework.
cside captures device intelligence from real visitors' browsers: 102+ signals including hardware fingerprint, rendering environment, automation tells, and VPN/proxy posture. Two logins from different cities may be a real traveler. The same two logins from different cities with a different device fingerprint and a residential proxy ASN is a different problem.
This combination catches what IP velocity alone misses:
- VPN-masked travel: the IP stays in one city, but the device profile changes mid-session. That shift is not physical movement, but it is a trust break.
- AI agent token reuse: an AI agent that picks up a stolen session token may replay it from a completely different geographic and network context. The location jump is immediate, and the device profile will not match the account's history.
- Real session theft: a session cookie captured via a browser-layer attack and replayed by the attacker from a different country shows as impossible travel plus a sudden device fingerprint mismatch.
Impossible travel as one signal in a session model
Impossible travel is a useful flag, not a verdict. An account that triggers it should see a step-up authentication challenge, a forced re-authentication, or a hold on high-risk actions (payout, address change, payment-method update), not an immediate block. A real traveler who confirms their identity continues without friction. A credential-stuffing session that cannot clear the challenge gets stopped.
The right model layers the signal with device fingerprint drift, network reputation (VPN and proxy score, ASN type), behavioral continuity, and post-login action velocity. cside delivers all of these as session-risk signals via API, so your fraud logic can score the full context rather than reacting to location alone.
For how impossible travel fits into a broader account takeover prevention operating model, including session scoring and post-auth controls, see the full playbook.
