Speed Over Distance: Rethinking Impossible Travel

    If you've worked an impossible travel alert, you know the drill. A user signs in from Ann Arbor, then twenty minutes later from Amsterdam, and the detection fires. You dig in, and it turns out they never left their desk. Their VPN reconnected, their phone hopped carriers, or their traffic took the scenic route through a proxy on another continent.

    That isn't really the user's fault, and it isn't entirely the detection's fault either. GeoIP, the technology that turns an IP address into a spot on a map, is pretty good at telling you what country someone is in. Ask it what city, and even the best providers miss the mark more often than you'd think. And that map is constantly being redrawn. Any detection that leans entirely on it inherits that uncertainty.

    So we're changing how Blumira detects impossible travel and related identity activity. Here's why, what's coming, and what it means for you. (Spoiler: if you've tuned these detections, you're already ahead of the game.)

    So What's Wrong With Distance Bands?

    Today, our Microsoft 365 impossible travel coverage leans on distance bands: separate detections for logins 500 to 999 miles apart, 1,000 to 2,000 miles apart, and 2,001 miles and up. The thinking goes: the farther apart two logins are, the more suspicious they look. In practice, they fall short in two ways.

    They take too long. Distance bands look back over long windows of activity before comparing locations. That means they alert later than we'd like, and by the time they run, a lot of logins have piled up to compare against each other. More comparisons means more chances for GeoIP to be wrong, which means more noise.

    They only know where, not what. The bands only see where GeoIP says a session came from. They have no idea what kind of network is behind it. To a distance band, a corporate proxy, a privacy relay, or a cloud-hosted desktop looks exactly like someone hopping on a plane.

    A good share of impossible travel and new country findings turn out to be ordinary activity, which means time spent confirming that, yes, your user is still at their desk. It also means a lot of tuning: customers and managed service providers (MSPs) layering filters across three detections to quiet them down, and our team maintaining three detections that often fire on the same activity.

    Why Speed Over Distance?

    The new approach asks a better question. Instead of "how far apart are these logins?" it asks "could a person actually have made this trip in the time between them?"

    Speed-based detection. Each login is compared to the one right before it, and the detection checks whether the travel between them is physically possible. Because it doesn't have to wait out long windows, it runs more often and alerts sooner. Distance still matters, but now it's measured against time, which is how impossible travel actually works.

    Network context from our own IP reputation data. We've been building our own anonymized IP reputation dataset to answer the question GeoIP can't: what kind of network is this session actually coming from? That context helps us recognize some of the most common networks that make location data lie, so less everyday traffic masquerades as travel, while anything that looks risky still surfaces. You'll also see that context right in your findings, including the type of network and the organization behind it, so the ones that do fire are faster to triage.

    Google Workspace, JumpCloud, and 1Password impossible travel already use speed-based detection, and they'll pick up the same network context. Microsoft 365 is catching up: its distance bands move to speed-based detection, and both M365 impossible travel and new country gain network context too.

    What This Means for You

    • One detection instead of three. The three Microsoft 365 distance band detections, along with our existing M365 impossible travel detection, consolidate into a single speed-based detection. Tune once, in one place.
    • Your detection filters come with you. We're migrating your existing detection filters from the old detections to the new one. The old detections are only retired after we've confirmed your filters have carried over.
    • Custom detections aren't touched. If you've built your own impossible travel or geo-based custom detections, they stay exactly as they are.
    • Nothing for you to do. There's no opt-in and no reconfiguration. The changes roll out on our end.

    For MSPs, this applies to every organization you manage. Filters migrate per organization, so each client's tuning carries over as-is.

    What's Coming Next

    GeoIP isn't going to become perfect, and we're not pretending this change makes impossible travel and similar detections a solved problem. What it does is give these detections a better foundation: faster to alert, more accurate, more durable as the internet keeps shifting, and a lot less to maintain, for you and for us.

    This is the first of several improvements coming to our identity detections. Once these changes are live, we'll be watching how they perform closely, working with our customer experience team on your feedback, and adjusting quickly where needed. If something looks off, tell us. That's exactly what we want to hear. If something looks right, tell us that too. The more feedback we get, the better the detections get.

    These changes are rolling out soon. Keep an eye on our release notes, and if you have questions in the meantime, reach out to your Blumira contact or our support team.

    Tag(s): Blog

    Justin Kikani

    At Blumira, Justin helps to craft detection rules as part of the Incident Detection Engineering team. Prior to joining the team, he was the Director of IT at Nexus Direct, where he supported the company in its transition to a remote infrastructure. Before that, he held various IT and engineering roles, including a...

    More from the blog

    View All Posts