Impossible Travel Detection With IP Location: A Practical Guide

Impossible-travel detection compares two authentication events for the same account and asks one question: could a person have moved from where the first login appears to have come from to where the second appears to have come from, in the time between them? If the implied speed is beyond anything a commercial flight can do, at least one of the two sessions was not the account holder in that place.

Identity providers ship a version of this under different names. Microsoft Entra ID Protection calls it 'atypical travel': two sign-ins from geographically distant locations, at least one of them unusual for that user given past behavior. Microsoft Defender for Cloud Apps has an 'impossible travel' anomaly policy, and Okta's Behavior Detection evaluates 'velocity', the distance and time elapsed between two consecutive sign-in attempts. Underneath, the mechanism is the same: an estimated location for each IP address, a distance, a clock and a threshold.

The calculation has three steps. Look up the estimated coordinates of the address behind each login. Compute the great-circle distance between the two points (the haversine formula is the usual choice). Divide by the time between the events to get an implied speed, and compare it with a threshold that stands for the fastest plausible travel.

The threshold is a design choice. Long-haul airliners cruise at roughly 900 km/h, so an implied speed far above that cannot be a person carrying a laptop. Implementations add a margin for the error in the location estimates, and most ignore pairs that are close together: two estimates 80 km apart inside one metro area say nothing about travel and everything about database noise.

An account authenticates at 09:00 UTC from an address whose estimated location is central London (about 51.5 N, 0.1 W). At 09:40 UTC the same account authenticates from an address placed in Manhattan (about 40.7 N, 74.0 W). The great-circle distance between those points is roughly 5,570 km. Covering it in 40 minutes implies a speed of about 8,350 km/h, around nine times the cruising speed of an airliner. Nobody made that trip, so the pair is flagged.

Change one number and the picture changes. Had the second login come at 17:00 UTC, eight hours later, the implied speed would be about 700 km/h, which a direct flight can manage, so the pair should not fire on its own. Had it come from Birmingham, 160 km from London, the 40-minute gap would imply 240 km/h: a train, and within the error of city-level geolocation anyway.

Geolocation databases do not measure devices. They infer where an address block is used from registry records, ISP-published feeds, latency measurements and corrections, and publish the result as an area with a center point. Country is usually right; city is an estimate often wrong by tens or hundreds of kilometers; the coordinates mark the center of the chosen area, not a building. MaxMind, whose data many tools use, publishes accuracy figures that vary widely by country and network type, and the accuracy guide goes through the reasons.

For impossible-travel logic the consequence is direct: the distance you compute carries the error of both endpoints. Two estimates each off by 200 km can produce a 400 km 'trip' between logins made in the same room.

VPN exits. A user who connects to a VPN between two logins appears to jump to the exit server's country in seconds, and jumps back on disconnecting. The VPN detection checklist covers the signals that identify an exit address.

Mobile carrier gateways. A phone's traffic leaves the carrier network through a gateway that can be hundreds of kilometers from the handset, so a phone that moves between gateways, or switches from Wi-Fi to mobile data, appears to teleport. Mobile carrier geolocation explains why.

Carrier-grade NAT. Many subscribers share one public address, and the address a subscriber gets can change between sessions, so consecutive logins from one household can carry two addresses with two estimated locations. See CGNAT and shared addresses.

Corporate networks. Branch offices, remote workers and cloud desktops often exit through a headquarters or data-center address registered somewhere else, so a user in one city appears wherever the company's egress lives.

IPv6 and address rotation. Dual-stack devices present an IPv4 and an IPv6 address that databases place in different cities, and IPv6 privacy extensions rotate the device half of the address on a schedule, so a login over IPv4 compared with a later one over IPv6 can show a distance that is pure database artifact; see the IPv4 versus IPv6 guide.

The alert is a probability, so the response should scale with it rather than snapping to a lock. NIST's Digital Identity Guidelines (SP 800-63B) frame authentication in assurance levels and authenticator strength, so the translation for a suspicious sign-in is to require a stronger authenticator before the session gets anything valuable. NIST's Zero Trust Architecture (SP 800-207) adds that access decisions are made continuously from context, the user, device, location and behavior together, never from one attribute.

Step-up authentication is the natural first response: ask for a second factor, preferably a phishing-resistant one, and let the session continue if it passes. Until it does, limit what the session can do; reading is safer than changing an email address or a payout account. Notify the user through a channel the attacker does not control, and reserve termination and lockout for the cases where the step-up fails or other signals confirm compromise.

Device consistency. The same browser fingerprint, device identifier or push-registered phone across both logins points to one person whose network changed; a new device on the distant login points the other way.

Login history. If the account has appeared from both locations before, or from the same VPN provider or corporate egress, the pattern is normal for this user; Microsoft's and Okta's detections both compare against the user's own past sign-ins for this reason.

Session and account context. Was the first session still active when the second began? Did the second go straight for recovery details, a new payment method or a data export, or follow a fresh password reset? Those actions are what account takeover is for, and they matter more than the kilometers.

Network type. An address classified as hosting, VPN, proxy or Tor on the distant login is a stronger signal than a residential ISP address in an unfamiliar city; the VPN and proxy checker shows which applies.

Escalate when the implied speed is impossible even after allowing for geolocation error and the distant login arrived on a new device or went straight for sensitive actions; when the address is a hosting or anonymizer range rather than a residential ISP; when the step-up challenge failed or was abandoned; when the same distant address appears across several accounts at once, the signature of credential stuffing; and when the user, asked through a trusted channel, does not recognize the activity.

Treat it as noise when both sessions share a device, when one address belongs to a VPN or corporate egress the account uses routinely, when the distance is within the expected error of city-level geolocation, or when the account has a history at both locations. Log the alert either way; a pattern of near-misses is itself worth knowing about.