Why do VPNs and proxies make location-based fraud controls less reliable?

Why This Matters for Security Teams

Location checks often look decisive in dashboards, but they are only one signal in a broader fraud decision. A VPN, proxy, or Tor exit node can make a session appear to come from a trusted region even when the user, device, or automation is elsewhere. That is why mature programmes treat geolocation as a risk input, not proof of legitimacy. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for combining access control, monitoring, and response instead of relying on a single attribute.

The operational problem is not that geolocation has no value. It is that fraud teams frequently over-weight IP-based location while under-weighting device state, account history, session integrity, and behavioural anomalies. Attackers and opportunistic fraud actors know this and often test controls from common egress points before escalating. In practice, many security teams encounter location spoofing only after account takeover, card testing, or abuse traffic has already bypassed the first layer of screening.

How It Works in Practice

Effective location-based fraud control starts by treating IP-derived geography as a weak signal that must be corroborated. The strongest implementations score the request against multiple layers, then decide whether to allow, step up, challenge, or block. That usually includes device fingerprint consistency, cookie continuity, login velocity, ASN and hosting-provider reputation, and whether the same account has recently shifted regions in a way that matches known fraud patterns.

Teams also need to separate user inconvenience from control failure. A traveller on hotel Wi-Fi, a mobile carrier NAT address, and a privacy-conscious customer using a consumer VPN may all look similar at the IP layer, but their risk context differs. For that reason, current guidance suggests using geolocation for risk triage rather than hard denial wherever possible. This is consistent with the broader control approach in NIST SP 800-53 Rev 5 Security and Privacy Controls, which favours layered safeguards and continuous monitoring.

In operational terms, fraud teams typically use a decision stack such as:

• Check whether the IP belongs to a known VPN, proxy, Tor, or hosting provider.
• Compare claimed region against device history, shipping data, payment profile, and account tenure.
• Look for impossible travel, rapid region switching, or login bursts from shared exit nodes.
• Escalate to step-up authentication when the location signal conflicts with other trust indicators.
• Log the decision outcome so tuning can reduce false positives over time.

These controls tend to break down when the organisation relies on IP reputation alone in high-volume, low-latency environments such as checkout, account recovery, or API abuse prevention because the decision window is too small for corroborating signals to be evaluated.

Common Variations and Edge Cases

Tighter location enforcement often increases customer friction, requiring organisations to balance fraud reduction against false declines and support overhead. That tradeoff is especially sharp for travel-heavy users, remote workers, and privacy-sensitive customers who may legitimately share the same exit characteristics as abusive traffic.

There is no universal standard for how much weight geolocation should carry. Best practice is evolving toward contextual scoring rather than binary geoblocking, because the same VPN can be benign in one flow and highly suspicious in another. For example, a new-device login from a consumer VPN may justify a challenge, while a long-standing account using the same region-consistent device may not.

Edge cases also appear in mobile and enterprise networks. Carrier-grade NAT can collapse many users into the same apparent IP, while enterprise egress gateways can make a distributed workforce look like a single source region. In those environments, location controls need stronger identity and device signals, and often additional step-up verification anchored in the principles described by the NIST control catalog. Where fraud teams do not separate shared-network behaviour from suspicious relocation, legitimate access is blocked and real abuse still slips through via cleaner infrastructure.

Related resources from NHI Mgmt Group

• Why do AI agents make fraud controls less reliable?
• Why do synthetic identities make traditional fraud controls less effective?
• Why do agents make session-based authorization less reliable?
• Why do GenAI-powered scams make traditional fraud controls less effective?