The Sign-In Couldn't Have Been Them: What an Impossible Travel Alert Actually Means

Someone gets an email from Microsoft or Google saying a sign-in was detected from a location they could not possibly have reached in time. Sometimes it goes to the user. Sometimes it goes to whoever administers the account. Either way, the question lands on a person: is this an attack, or is this nothing?

The honest answer is that it is usually nothing, and the version where it is something is bad enough that you check properly every time. This is how to check, in order, and what each outcome tells you to do next.

This is written for whoever received the alert - the user, the owner, the office manager. You do not need to be a technician, but you do need access to the sign-in logs, or access to someone who has it.

What the alert actually means - and what it doesn't

An impossible travel alert is a geography calculation, nothing more. The system saw two successful sign-ins from locations too far apart for a person to have travelled between them in the time elapsed, and it flagged the second one.

Three things follow from that, and all three matter:

It only fires on successful sign-ins. Whoever signed in from the second location presented working credentials - the right password, and usually a completed second factor or a session that was already trusted. The alert is not telling you someone tried the door. It is telling you the door opened.

The location is approximate. Sign-in locations are derived from IP addresses, and IP geolocation is a guess of varying quality. A phone on a mobile network can appear to be in another state. A VPN exit point can appear to be in another country. The distance in the alert is real arithmetic on imperfect data.

"Impossible" describes the travel, not the sign-in. The system has no opinion about whether the second sign-in was legitimate. That judgement is yours, and the rest of this article is how to make it.

What it usually turns out to be

Before the checks, know the field. An impossible travel alert almost always resolves to one of these:

1. A VPN. The user, or software on the user's machine, routes traffic through a VPN whose exit point is somewhere far away. Some security tools and some privacy features on phones do this automatically without the user thinking of themselves as "on a VPN."
2. A phone on mobile data. Mobile carriers route traffic in ways that make a phone appear to be in a different city or state than the person holding it. A sign-in that happens while the phone is off Wi-Fi can carry a location hundreds of miles wrong.
3. A new device, a new app, or a re-authentication. The user signed in from a new laptop, set up mail on a tablet, or an application quietly refreshed its session from a data center somewhere. The "user" in the log entry is sometimes the user's software.
4. An actual account takeover. Someone else, somewhere else, signing in with the user's working credentials. This is the least common of the four and the only one that matters, and it looks enough like the other three that you do not get to assume.

The trap is that the first three are so common that the fourth gets waved through with them. The checks below are how you tell them apart without guessing.

What to check in the sign-in logs before you act

Open the sign-in log for that account (in Microsoft 365, the Entra admin center; in Google Workspace, the admin console's audit log). Look at the flagged sign-in and the entries around it. You are answering five questions, in this order:

Does the user recognize it? Ask first, before you change anything - once you reset things, the evidence gets harder to read. Was the user travelling, on a VPN, on their phone off Wi-Fi, setting up a new device at that time? A confident "yes, that was me, I was on my phone in the car" resolves most of these. A hesitant "I don't think so?" does not.

What location and IP, and does it fit the story? The flagged location should be consistent with the explanation. A phone on mobile data explains a wrong city in the same country. It does not explain a residential provider in a country the user has never visited.

What device and application? The log records what signed in. A device the user owns and an application they use points one way. A device or browser nobody recognizes, or a legacy mail protocol the user's actual devices do not use, points the other. Older sign-in methods that skip the second factor entirely are a particular tell.

Did the second factor actually happen, and how? Look at how the sign-in satisfied MFA. A prompt the user approved on their own phone is very different from a text-message code, which is very different from a session that needed no fresh approval at all because the device was already trusted. And separately: if the user remembers approving a prompt they did not initiate, treat that as a yes to the takeover question below.

What happened after the sign-in? This is the check that settles it. Pull the activity that followed: mail read and sent, mailbox rules created, forwarding set, files opened or downloaded, new devices enrolled, authentication methods added. A sign-in followed by nothing is usually the software or the network. A sign-in followed by a new inbox rule, a forwarding address, or sent mail the user did not write is a person inside the account.

When to reset and revoke - and when not to

Force a password reset and revoke all sessions, immediately, when any of these is true: the user does not recognize the sign-in and no explanation fits; the device, application, or second-factor method in the log is unfamiliar; any activity followed the sign-in that the user cannot account for - rules, forwarding, sent mail, downloads, new authentication methods; or the user approved a prompt they did not initiate. Reset the password, sign the account out everywhere so existing sessions die with it, remove any authentication methods, rules, forwarding or connected apps nobody can explain, and then watch the account for the next few days. An attacker who loses access often tries the same door again.

Do not reset when the explanation checks out: the user recognizes the sign-in, the story matches the log (VPN exit point, mobile network, new device they were setting up), the device and application are theirs, and nothing followed the sign-in. Record it as a false positive with the reason, and move on. Resetting passwords over every VPN alert teaches people to dismiss alerts, which is how the real one eventually gets waved through.

The asymmetry to keep in mind: a needless reset costs an hour of irritation. A missed takeover costs the mailbox, and often the money, and sometimes the customers. When the checks are inconclusive - the user is unsure, the log is ambiguous, the device could be explained either way - treat it as real. "We couldn't rule it out, so we reset it" is always a defensible sentence.

What a real takeover looks like from here

If the checks say someone was in the account, the sign-in was the beginning, not the whole incident. Assume the mailbox was read - which means everything in it is known to someone outside the business, including the password resets other services email to that address. Assume sent mail may have been used, which means customers or vendors may have received messages that appear to be from the user, and payment or banking details quoted in those messages may already be under attack.

The work from that point is containment first, then scope: what the account could reach, what was read or taken, who was contacted from it, and whether any money or payment instruction moved. That sequence, and the order to do it in, is in Someone Clicked It: The First 30 Minutes After a Phishing Link - the checklist from "when it isn't contained" onward applies here unchanged. And if the mailbox held other people's personal information, the notification question from that article applies here too: it has its own clocks, and it is not one to make casually.

What to write down

Whether it resolved to nothing or to a takeover, the alert gets a record: when the alert fired, which account, the locations and times involved, what the user said when asked, what the log showed for device, application and second factor, what activity followed, what you did about it and when, and how it resolved.

The false positives are worth writing down as carefully as the real ones. Six months of "VPN exit point, user confirmed, no follow-on activity" entries is the baseline that makes the one alert that doesn't fit instantly visible - and it is the evidence that your alerts are watched, which is a question your cyber insurer and your assessors will both eventually ask.