The rule is appealing because it needs no machine learning and no vendor. Take the last sign-in location, take this one, divide the distance by the elapsed time, and if the implied speed is impossible then one of the two was not the account holder.
It works. It also fires constantly on people who did nothing wrong, and understanding why is the difference between a useful signal and an alert channel everybody mutes.
Where the geography comes from
The location is derived from an address, and that derivation is approximate at best. Corporate networks egress through a gateway in another country. Consumer VPNs move somebody to a different continent between two tabs. Mobile carriers route large regions through a small number of exits, so a person on a train may appear to teleport without moving. Cloud-based browsers and mail scanners contribute their own datacentre coordinates.
So the signal is not really about travel, it is about the consistency of a network path — and network paths change for entirely ordinary reasons. Treating a change as evidence of compromise means accusing the person who turned on their company VPN over lunch.
The rule does not measure travel. It measures the stability of a network path, and paths move for boring reasons.
Make it one input, not the verdict
The version that earns its place combines the geographic jump with signals that are harder to explain away: a device you have never seen, a client that does not match the account's history, a sign-in outside the account's normal hours, a failed attempt shortly before the successful one. Any single one of those is weak. Together they are worth acting on.
And choose a response proportionate to that confidence. Refusing a sign-in on a location signal alone will lock out a travelling executive at the worst possible time. Requiring a second factor, notifying the account owner, and recording the event costs almost nothing when wrong and is effective when right.
- Combine with device familiarity — a known device explains most jumps
- Exclude known corporate egress ranges a customer has told you about
- Respond with step-up and notification, not refusal
- Suppress repeats: one alert per pattern, not one per request
You are keeping a location history now
To compare against the previous sign-in you have to store where people were, which is personal data with a retention period, a lawful basis and a place in your privacy notice. Store the minimum that makes the rule work — a coarse region, a timestamp, a device reference — rather than a precise coordinate you have no use for.
Give it back to the user, too. A visible list of recent sign-ins with location, device and a button to end a session turns your detection data into something they benefit from, and the account owner is invariably faster at recognising an anomaly than any rule you write.
- Coarse region, not precise coordinates; you never needed the precision
- Bounded retention, stated in the privacy notice
- Surface the history to the account owner with revocation attached
- Every detection and every step-up prompt belongs in the audit trail
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.