Impossible travel

Catch sign-ins from two places too far apart to be the same person.

Find it at Domains → (your domain) → Impossible Travel

Each sign-in is compared with the previous one. If the distance between them could not be covered in the time that passed — a sign-in in London an hour after one in Singapore — that is flagged as an anomaly. It is one of the clearest signals a password has been stolen, because the real user and the attacker are signing in from different places.

On an anomaly

Log only (observe)

The sign-in proceeds and the anomaly is recorded. Start here to see how often it triggers.

Require Google Authenticator

After the password, the user must also pass their authenticator.

Rolling it out safely

1 Turn detection on with the action left on Log only.
2 Leave it a week, then look in User Logs for travel_anomaly entries.
3 Check that anyone flagged is enrolled in Google Authenticator.
4 Only then switch the action to Require Google Authenticator.

Check authenticator enrolment first

A user with no authenticator set up is refused outright when this is on. Confirm your people are enrolled before switching from Log only.

What counts as impossible

The check needs both a long distance and a speed no flight could manage. A sign-in in London two hours after one in Delhi is impossible; the same pair three days apart is not. Moving around on one journey will not trigger it.

It needs a previous sign-in to compare against

There is nothing to measure a brand-new account against, so the check starts protecting someone from their second sign-in onward.

Why thresholds are generous

Location from an IP address is approximate, so the check only flags journeys that are clearly impossible rather than merely fast. VPNs are the usual cause of a false alarm, which is another reason to observe before enforcing.

Setting the policy above is only the first of three steps. The policy says WHAT the rule is; a user is only covered once they are opted in, and a group is how you opt in a whole team at once.

Applying it to people

1 Set the policy on the domain, using the page above.
2 For one person: open their user record and set Impossible Travel to On.
3 For a team: put them in a group, and set the policy on the group instead.
4 Leave the action on its observe setting, then check User Logs before enforcing.

The Security block on a user record. Impossible Travel is the switch that puts this person under the policy — without it, the domain setting does not reach them.

The same control on a group. Use this when a team needs a stricter action, such as requiring an authenticator from the rest of the domain.