Impossible Travel Explained: Detecting Account Compromise for CySA+

Impossible travel is a detection based on physics rather than signatures. A user authenticates from Boston at 14:00 and from Singapore at 14:40. No one covers that distance in forty minutes, so at least one of those sessions is not the person it claims to be.

The elegance of impossible travel is that it needs no knowledge of the attacker. It only needs two timestamps, two locations, and the speed of aircraft.

It is sometimes called atypical travel, improbable travel, or a risky sign-in depending on the platform, and it is one of the most widely deployed detections in cloud identity systems.

How the Calculation Works

The platform records the geolocated source of each successful authentication. When a new sign-in arrives, it computes the distance from the previous one and divides by the elapsed time. If the implied speed exceeds a threshold — typically somewhere around 500 miles per hour, roughly commercial aircraft cruising speed — the sign-in is flagged.

Most implementations add refinements: a familiar-location list built from the user's history, a minimum distance so short hops do not trigger, and a risk score rather than a binary verdict.

Why It Produces False Positives

This is the part that matters operationally, and the part exams probe. Impossible travel alerts are frequently benign, and knowing why is the difference between a useful detection and a disabled one.

• VPNs. A user connects to a corporate or commercial VPN and their apparent location jumps continents instantly. This is the single largest source of false positives.
• Mobile carrier routing. Cellular traffic can egress hundreds of miles from the user's actual position, and carrier-grade NAT makes it worse.
• Cloud-hosted clients. A mail client running on a cloud VM authenticates from the data centre's location, not the user's.
• Geolocation database error. IP-to-location mapping is good at country level and unreliable below it. Reassigned address ranges produce phantom relocations.
• Two devices, two paths. A laptop on office Wi-Fi and a phone on cellular can legitimately appear in different places at the same moment.
• Genuine travel with a connecting flight, where sign-ins from an airport lounge and a destination hotel compress oddly.

Because of this, mature deployments treat impossible travel as a risk signal that raises a score, not as grounds for an automatic block. Blocking outright on this signal alone locks out travelling executives and VPN users, and the pressure to disable it follows quickly.

Corroborating It

An impossible travel alert becomes actionable when something else agrees with it. The signals to check:

• A new or unrecognized device or user agent.
• A different ASN — particularly a hosting provider, VPN service or Tor exit node rather than a residential or corporate ISP.
• Legacy authentication protocols, which bypass MFA and are a strong attacker preference.
• Actions after sign-in: a new inbox rule, a password change, an MFA method added, a bulk download, or access to systems the user never touches.
• Preceding failed attempts, suggesting password spraying that eventually succeeded.
• MFA behaviour — a flurry of denials followed by an approval suggests fatigue or a vishing call.

The combination of impossible travel and a new inbox forwarding rule is close to a definitive business email compromise indicator, and it is worth recognizing as a pattern rather than two separate alerts.

What Defeats It

Worth being honest about the limitation: an attacker who routes through a VPN or proxy in the victim's own city produces no travel anomaly at all. Sophisticated operators do exactly this, and residential proxy networks make it inexpensive.

Impossible travel therefore catches the careless and the automated, which is a large share of credential-stuffing activity, but it is not a control a targeted attacker will trip. It belongs alongside geographic restrictions, device compliance and phishing-resistant MFA rather than in place of them.

Responding to a Confirmed Case

Treat it as credential compromise: revoke active sessions and refresh tokens rather than only resetting the password, since a stolen token survives a password change; reset credentials; review and remove any mail rules, MFA methods or app registrations added; check what was accessed during the window; and look for the same source address against other accounts, because credential attacks are rarely aimed at one person.

CySA+ (CS0-004) Exam Tips

• Define it precisely: two authentications from locations too far apart for the elapsed time.
• It is a detection, not a prevention.
• VPNs are the main false positive source. If a question asks why an alert fired benignly, that is the answer.
• Corroborate before acting — new device, hosting ASN, legacy auth, post-login actions.
• Impossible travel plus a new forwarding rule signals BEC.
• Revoke sessions and tokens, not just the password.
• Know the neighbours: geographic restrictions, conditional access, UEBA, and risk-based authentication.

Security+ and SecurityX Angles

Security+ (SY0-701) lists it among indicators of malicious activity and covers conditional access as the control that consumes it.

SecurityX (CAS-005) treats it as policy design — setting risk thresholds, deciding when to challenge versus block, and handling a global workforce where legitimate travel is constant and the naive version of this rule is unusable.

Key Takeaways

• Impossible travel flags sign-ins too far apart in space for the time elapsed.
• It needs no attacker knowledge — just geolocation, timestamps and arithmetic.
• VPNs, mobile carriers and geolocation error make false positives common.
• Use it as a risk signal feeding conditional access, not as an automatic block.
• Corroborate with device, ASN, legacy authentication and post-login behaviour.
• An attacker proxying through the victim's own city defeats it entirely.