The Incident That Reframed the Problem
A mid-sized financial services firm received an alert flagging a series of authentication attempts originating from what their SIEM labeled as Russian IP addresses. The security team escalated immediately, began drafting an incident report, and spent two hours investigating a potential nation-state intrusion. The actual source: a VPS provider in a Chicago colocation facility, used by a local contractor whose home ISP had assigned him an address that a commercial geolocation database had confidently mapped to Moscow.
The database was wrong. The decision-making built on top of it was worse. This kind of failure happens every day across enterprise environments, and the consequences range from wasted analyst hours to blocked legitimate users to missed actual threats. For cybersecurity professionals and IT administrators, understanding exactly where IP geolocation breaks down — and how to account for that in operational workflows — is more useful than debating its accuracy in the abstract.
What Geolocation Data Actually Represents
IP geolocation databases do not observe packet routing in real time. They aggregate data from multiple sources: Regional Internet Registry (RIR) records, BGP routing announcements, user-submitted corrections, reverse DNS lookups, web crawlers, and in some commercial databases, device-level signals from opt-in telemetry. The result is a probabilistic estimate, not a definitive mapping.
The confidence level varies enormously depending on the type of IP address, the provider's data freshness, and the geographic region being queried. Country-level accuracy across major commercial providers typically sits between 95% and 99% for consumer broadband addresses in Western Europe and North America. That sounds reliable until you calculate the error volume at scale: on a service handling 10 million daily authentication requests, even a 1% error rate produces 100,000 misclassified sessions per day.
City-level accuracy drops significantly, often to 60%-80% depending on the provider and region. ISP-level accuracy varies even more. Postal code and street-level claims made by some vendors should be treated with deep skepticism in almost all operational contexts.
The Technical Reasons Databases Get It Wrong
IP Block Reassignment Lag
When ISPs reassign IP blocks — whether due to mergers, infrastructure changes, or regional redistribution — the geolocation databases that rely on RIR data inherit stale mappings. ARIN, RIPE, APNIC, LACNIC, and AFRINIC process these changes, but commercial database vendors update their records on different schedules. Some update weekly. Some update monthly. A block reassigned from a German ISP to a Brazilian one might carry its old European label for weeks in databases that haven't pulled the latest RIR exports.
Anycast and CDN Infrastructure
Anycast addressing is a fundamental challenge for geolocation. A single IP address announced via anycast routing can terminate at data centers on multiple continents simultaneously, depending on which node is closest to the requesting client. When a user's request reaches Cloudflare, Akamai, or Fastly infrastructure, the egress IP visible to your server reflects the CDN node, not the user's location. Geolocation databases that haven't specifically flagged these ranges will produce wildly incorrect results.
The same applies to large content platforms and DNS resolvers. Google's public DNS resolver at 8.8.8.8 is anycast. If your application is logging DNS resolution source IPs and feeding them into a geolocation pipeline, you'll see Google's infrastructure scattered across dozens of countries, none of which reflect the user's actual location.
Mobile Network Addressing
Mobile carriers aggregate traffic through centralized gateways. A user in rural Nebraska browsing on a major carrier's network might egress through a gateway assigned to Dallas or Chicago. The IP address logged by your web server reflects that gateway, and the geolocation database maps the gateway, not the device's physical location. This is particularly relevant for fraud detection workflows and access control policies that treat geolocation as a meaningful signal about where a human is sitting.
VPNs, Proxies, and Residential Relay Networks
This is where the accuracy problem intersects most directly with current threat activity. Commercial VPN providers maintain exit nodes in dozens of countries. The IP address logged at your perimeter will geolocate to whatever country hosts the exit node, not the attacker's actual origin. More problematically, residential proxy networks — which route traffic through compromised or rented consumer devices — will geolocate to the location of the residential ISP subscriber whose device is being used as a relay. Those addresses look indistinguishable from legitimate consumer traffic.
The cybercriminal infrastructure market makes this worse. Reports of Chinese surveillance cameras being sold with embedded backdoors, and the broader market for access to compromised devices, feed directly into residential proxy availability. When an attacker purchases 500 residential proxy sessions across 20 countries, they can generate authentication traffic that geolocates to those 20 countries with high accuracy — because the traffic literally is originating from those locations. Your geolocation data becomes accurate while simultaneously becoming useless for attribution.
Where Defenders Over-Rely on Geolocation Data
Geo-blocking as an Enforcement Mechanism
Geo-blocking at the firewall or application layer is a risk reduction measure, not a security control. Blocking inbound traffic from countries your organization has no business relationship with reduces noise and can raise the cost of opportunistic attacks. It does not stop determined adversaries with access to VPN infrastructure or residential proxies, which is most of the threat actors that matter for a mature organization.
The practical risk of over-relying on geo-blocking shows up in incident timelines. Teams that treat a geolocation block as confirmation that a threat has been stopped tend to close investigations prematurely. The WSzero DDoS family, now in its fourth version, demonstrates exactly this pattern: infrastructure is rotated across geographies specifically to invalidate location-based filtering assumptions. When the botnet operators know your filtering logic, they plan around it.
SIEM Correlation Rules That Use Country as a High-Confidence Signal
Many SIEM deployments include correlation rules that treat logins from unexpected countries as high-severity alerts. These rules produce value when they catch genuine anomalies. They produce noise when geolocation data is wrong, and they produce blind spots when attackers have already accounted for the rule by choosing appropriate proxy geography.
A more robust approach treats country-level geolocation as a low-to-medium confidence enrichment signal that raises or lowers the weight of other indicators, rather than as a standalone trigger. A login from an unusual country is more meaningful when it also involves a new device fingerprint, an unusual time window, and a credential that appeared in a recent breach dataset. Any one of those signals alone is weak; the combination is actionable.
Incident Response Attribution
The Chicago-contractor-misidentified-as-Russian example at the start of this article reflects a real pattern in incident response. Geolocation data gets treated as reliable enough for initial attribution during the first 30 minutes of a response, when analysts are under pressure to characterize the threat quickly. That initial characterization then anchors subsequent analysis in ways that are difficult to correct even after better data arrives.
CISA's recent deadline to remediate the exploited Cisco vulnerability reflects a broader pattern: many of the highest-impact vulnerabilities get exploited through infrastructure that will geolocate to hosting providers in Western countries, specifically because attackers know that North American or European source IPs face less aggressive blocking. Treating geolocation origin as meaningful for criticality scoring on known vulnerability exploitation events will consistently underweight threats coming from expected-looking geographies.
Calibrating Accuracy Expectations by Use Case
The right accuracy expectation for IP geolocation depends on what decision it's feeding. The following breakdown reflects practical operational thresholds rather than vendor marketing claims.
Country-Level Identification
For non-VPN residential and business broadband addresses in North America, Western Europe, Japan, South Korea, and Australia, country-level accuracy from major commercial providers is high enough to use as a supporting signal. For Central Asia, Sub-Saharan Africa, and parts of the Middle East, accuracy drops. For addresses associated with hosting providers, VPNs, Tor exit nodes, or mobile carrier gateways, country-level geolocation provides limited operational value regardless of region.
City-Level Identification
City-level geolocation is useful for anomaly detection when you have a baseline. If a user account has consistently logged in from a specific metropolitan area for six months and suddenly shows a different city, that delta has signal value. The absolute city label is less important than the behavioral change. This approach reduces dependence on the accuracy of any single data point and turns geolocation into a relative measurement tool rather than an absolute one.
Fraud and Access Control
For fraud detection, geolocation should feed a risk scoring model alongside device fingerprint, behavioral biometrics, session velocity, and transaction history. Teams that weight geolocation too heavily in fraud models consistently see both false positive rates (legitimate users blocked due to inaccurate location data or VPN use) and false negative rates (fraudsters using residential proxies that geolocate correctly to benign-looking locations).
Building Better Workflows Around Imperfect Data
Enrichment Layering
When an alert fires on a suspicious IP, geolocation should be one of several enrichment queries running in parallel rather than the first filter applied. ASN data, hosting provider classification, abuse history, Tor exit node status, VPN/proxy detection scores, and passive DNS history all provide signal that can confirm or contradict geolocation claims. An IP that geolocates to Germany but is registered to a known bulletproof hosting ASN operating out of Eastern Europe is a different risk profile than one that geolocates to Germany and belongs to Deutsche Telekom's consumer broadband block.
Commercial threat intelligence platforms and open-source tools like MaxMind's GeoLite2 alongside WHOIS, IPinfo, and Shodan provide complementary data that, when combined, produce more reliable operational assessments than any single source. The Insikt Group and similar structured intelligence teams build exactly this kind of layered enrichment into analyst workflows, precisely because single-source geolocation has known failure modes.
Freshness Verification
The geolocation database your organization is querying was accurate as of its last update. Know when that update happened. Enterprise deployments should query providers that offer daily or real-time updates for high-velocity use cases like authentication logging. For lower-frequency use cases like threat hunting, weekly update cycles are usually acceptable. Build database update timestamps into your enrichment metadata so analysts can see how old the data is when they're evaluating an alert.
Confidence Scoring in Alerts
Some commercial geolocation providers include a confidence score alongside their country and city outputs. These scores reflect internal indicators like whether the IP is a known proxy, how many data sources confirmed the location, and how recently the data was verified. Surfacing these confidence scores in your SIEM or SOAR alert enrichment lets analysts make faster, more calibrated decisions about how much weight to assign the location data.
When confidence scores are unavailable, proxy classification is a reasonable substitute. An IP flagged as a datacenter address, VPN exit node, or anonymous proxy should carry near-zero geolocation weight in your decision logic, because the location reflects infrastructure, not the operator behind it.
Baselining Against Known Good
For internal users and known API partners, maintaining a baseline of typical geolocation patterns over rolling 30 and 90-day windows provides more operational value than absolute location checking. A user who has always connected from the same ASN and city, suddenly appearing from a different continent, warrants investigation regardless of whether the new location is geopolitically interesting. This approach also handles the legitimate travel and remote work scenarios that generate false positives in static geo-block configurations.
Operational Implications of Recent Threat Activity
The current threat landscape reinforces why geolocation accuracy limitations matter in practice. Fraudulent OpenAI organization invites targeting cybersecurity firms were delivered through infrastructure that, in several documented cases, geolocated to US-based cloud providers — the kind of location that many organizations implicitly trust more than foreign addresses. The attack depended partly on that implicit trust reducing scrutiny.
Operation Endgame's disruption of Amadey and Stealc malware infrastructure demonstrated how botnet operators distribute their C2 infrastructure across multiple jurisdictions specifically to complicate geo-based filtering and attribution. Law enforcement actions in these operations require actual network forensics and legal processes across multiple RIRs and hosting providers — none of which rely on geolocation databases as a primary evidence source, because investigators understand the accuracy limitations that defenders sometimes ignore.
State-sponsored surveillance infrastructure, including the market for compromised camera access, creates residential and commercial IP addresses that will geolocate accurately to their physical location while being controlled by parties in entirely different jurisdictions. For defenders trying to assess whether a specific IP address represents a threat, the geolocation of the device is almost irrelevant. What matters is the behavioral pattern, the associated infrastructure, and whether the IP appears in threat intelligence feeds built on actual observed malicious activity.
Practical Takeaways for Security Teams
- Treat geolocation as a low-confidence enrichment signal that should confirm or question other indicators, not serve as a standalone trigger for high-severity alerts.
- Know your database update frequency and surface that metadata in analyst tooling. A geolocation result that's 45 days old is a different confidence level than one from yesterday.
- Implement proxy and VPN detection separately from geolocation. An IP flagged as datacenter or anonymous proxy infrastructure should be evaluated on that basis, with geolocation data deprioritized.
- Build behavioral baselines for known users and systems so that geolocation anomalies are measured relative to individual history, not compared against absolute allow/block lists.
- Validate geolocation claims against ASN data. Mismatches between the registered ASN country and the geolocation country are a useful signal for further investigation.
- Audit your SIEM correlation rules to identify any that use country-level geolocation as a primary high-confidence filter and add compensating controls or additional required signals.
- Test your providers periodically by querying known VPN exit nodes, Tor addresses, and recently reassigned blocks to assess how your current database handles these edge cases.
The Honest Assessment
IP geolocation is a useful tool that operates within well-defined limits. The errors it produces are not random: they cluster around specific address types, specific geographic regions, and specific network architectures that are overrepresented in modern attack infrastructure. Understanding where those clusters sit means you can design workflows that get value from geolocation data in the cases where it's reliable while avoiding consequential decisions in the cases where it isn't.
The teams that use geolocation well treat it as one layer in a multi-signal enrichment pipeline. The teams that get burned by it are the ones that let it function as a decision-making shortcut during the first minutes of an incident, before more reliable data sources have been queried. The difference between those two patterns is mostly workflow design and analyst training, not tooling budget.
