Home / Knowledge hub / Impossible travel
Knowledge hub
Impossible travel
Two sign-ins from places too far apart for one person to have reached.
What it means
Impossible travel is a detection rule. It compares where an account signed in last with where it signs in now, and checks whether a person could have travelled between the two in the time that passed. A sign-in from Delhi and another from London twenty minutes later cannot both be the owner.
The locations come from IP addresses, which only give an approximate place. The rule therefore raises a suspicion for review or a challenge, and does not prove misuse.
Why it matters
It is a cheap way to spot a stolen password or session in use. The real owner stays in one place and the attacker is somewhere else, and the gap between the two is visible in the sign-in log with no special tooling.
It is also noisy if used carelessly. Alerts that fire daily on harmless travellers teach staff to ignore them, so a real warning sits unread among false ones. Tuning matters as much as the rule.
How it shows up
You meet it in identity provider risk features, security monitoring tools and fraud systems. The input is the sign-in log with a time, an address and a rough location for each event.
The mistakes repeat. VPNs, mobile carriers and company proxies put honest users in odd places. Cloud addresses are geo-located wrongly. Attackers use a proxy near the victim and slip through. Only the application's sign-in is logged, not the API. Treat it as one signal, combine it with device information and respond with a challenge before a block.
Questions people ask
Impossible travel, answered
Is impossible travel proof of a breach?
No. VPNs, roaming mobile networks and inaccurate location data cause false alerts. It is a reason to look closer or to ask for another factor.
Confirm with the account owner or another signal.
How do attackers avoid it?
By using an address in the same country or city as the victim, or by reusing the victim's own session from a browser profile. Then the locations appear to match.
This is why it cannot be your only control.
What should happen when it fires?
Usually a step-up challenge, a notification to the owner and a short review by your team, not an instant lock. Lock only where the risk justifies the disruption.
Log the decision for later review.
Does it work for APIs?
Only if API sign-ins and token use are logged with an address. Many applications log web sign-ins well and API calls poorly, which leaves a gap.
Check what your logs actually capture.
How does it relate to adaptive authentication?
It is one of the signals that adaptive authentication can use to decide when to ask for more proof.
It also feeds monitoring and alerts.
Sources
Where this comes from
Related
Terms that sit next to this one
Adaptive authentication
Asking for more proof when a sign-in looks unusual.
Account takeover
An attacker ends up signed in as one of your real users.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Logging and monitoring
Recording what happens, and actually watching what gets recorded.
Browser fingerprinting
Identifying a visitor from the many small details their browser reveals.
Could one person be in both places?
Detection works best when you also know which flaws let an account be taken over. We find them and prove each by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.