Why Travel Allowlists Cause More Pain Than Protection

“Only allow log‑ins from known places” sounds great, but falls apart in practice.

This week, I wanted to dive into a “feature” of many detection systems that ends up harming security teams more than helping them: travel allowlists.

On paper, the premise behind travel allowlists is simple: Only let users log in from places we expect.

Folks often have a story associated with these - user based in Texas, sudden login from Nigeria, feels like common sense that we should alert on it.

There’s just one small problem: users log in to their accounts from unexpected places all the time. We frequently see users log in from coffee shops, airports, and even their Teslas.

Worse, it’s become easier than ever for attackers to appear like they’re in the legitimate user’s location - right down to the zip code.

In practice, maintaining allowlists becomes a logistical nightmare for security teams and creates dangerous detection blindspots.

Let’s dive into a real-life example.

Executive from Remote-First Company Traveling to NYC

Here are logins for an executive who works at a remote-first company in Illinois.

On June 20-21, they log in from Chicago → Dallas → New York (that New York login from mtnsat holdings llc is the plane wi-fi).

It looks like this user is traveling to New York, with a layover in Dallas.

The Security Team’s Dilemma

If we were maintaining an allowlist for this tenant, this user’s “home base” location would be Illinois, so all logins from Illinois would be allowed by default.

Let’s say the executive submitted an allowlist exception for New York from June 20th to June 21st.

Unless they had extraordinary foresight, they probably didn’t remember to mention their layover in Dallas.

What happens now?

• We get an alert that the user logged in from an unauthorized location: Dallas.

• We review the user’s metadata and see they’re an executive who is supposed to be traveling to New York.

• Now we’re tasked with a tricky dilemma:

  • On one hand, we don’t want to lock the user out incorrectly since they’re an executive. Maybe they’re logging in from Dallas to tweak a powerpoint in SharePoint before an important customer meeting.

  • On the other hand, since they’re an executive, they’re more likely to be targeted by attackers. If this is a compromise and we don’t quickly nip it in the bud, it could be a disaster.

• Should we sit tight and monitor for more IOCs? Maybe it will become clearer whether its an attack or not within the next few minutes.

• We can try reaching out to the user to confirm their activity, but we know they’re traveling, so they may be unresponsive. If they don’t respond, what’s our next step?

One Solution: Broader Allowlist Exceptions for Executives

The messy reality is that executives tend to travel a lot, and incorrectly locking them out causes serious business disruption. False positives are costly.

But, executives are also high value targets for attackers. False negatives are costly too.

However, false positives are far more frequent. 9 times out of 10, that executive logging in from Dallas is benign activity.

So, security teams often end up giving executives a broader allowlist exception.

This reduces the constant upkeep associated with repeatedly adding and removing the executive from allowlists, and it reduces any blowback the security team gets from higher ups about false lockouts.

Every once in a while though, that Dallas login is actually an attacker who knows they can sneak past an allowlist by routing their traffic through a major city. Here’s an attacker logging in from Secaucus, New Jersey (a common transit location).

It's not fun explaining that the malicious login from Dallas went unnoticed because the company’s executives travel to Dallas frequently.

Takeaway: Travel Allowlists Aren’t the Answer

Allowlists rely on a faulty assumption: activity from an unusual location is likely an attack.

In practice, remote work and frequent travel, particularly from executives, makes it hard to confidently say “someone shouldn’t be in this location”.

Allowlists end up being the worst of both worlds, particularly if you’re a service provider who has to maintain individual allowlists for each customer.

You damage customer trust by unnecessarily disrupting business or missing an attack, and your team gets burnt out with the constant upkeep involved.

Instead of treating “unusual location” as a silver bullet to detect an attack, you should treat it as one signal among many.

We’re big believers of this ethos at Petra. Reach out on LinkedIn if you’d like to learn more about how we solve it.