The Assumption That Gets Analysts Burned
Most security teams treat IP geolocation as a reliable signal. They build dashboards that light up maps with threat origins, feed country codes into blocking rules, and include geolocation data in incident reports as though it represents ground truth. It does not. IP geolocation is an inference, not a measurement, and the gap between what analysts assume it tells them and what it actually tells them causes real operational failures every week.
The contrarian position worth stating plainly: geolocation accuracy is often irrelevant to the question you are actually trying to answer, and when it is relevant, the data is wrong often enough to matter. Understanding where and why the data fails is not a theoretical exercise. It shapes how you investigate, how you block, and how you attribute activity to threat actors.
What Geolocation Actually Measures
IP geolocation databases work by mapping IP address blocks to physical locations using a combination of registration data from Regional Internet Registries (RIRs), routing data collected from BGP, active and passive network probes, and commercial agreements with ISPs and hosting providers. No single database has a ground-truth feed. Every vendor is making educated guesses based on the best available signals.
At the country level, commercial geolocation databases report accuracy rates between 95% and 99% in vendor-supplied benchmarks. That sounds reassuring until you do the math. A 2% error rate across hundreds of millions of IP addresses produces tens of millions of misattributed addresses. At the city level, accuracy drops considerably, with independent research consistently showing figures between 50% and 80% depending on the region and the database vendor. For some parts of the world, city-level data is essentially a coin flip.
The practical problem is that most security tooling uses city-level or regional data to trigger decisions: access controls, fraud scoring, alert triage priority, and investigation direction. Analysts working incidents often anchor their understanding of an attack on geolocation data early in the investigation, and that anchor influences every subsequent decision.
Why the Data Drifts and When It Matters Most
IP address space is not static. Blocks are reallocated, sold, transferred between organizations, and reassigned across provider boundaries faster than most geolocation vendors update their databases. A block that was assigned to a Ukrainian hosting provider in 2023 may have been sold to a US cloud reseller by 2025. The geolocation database may still point to Ukraine.
Large cloud providers and CDN operators add another layer of complexity. When an attacker provisions infrastructure on AWS, Azure, or Google Cloud, the IP address resolves to a geolocation matching a cloud data center, which may be in a different country than the attacker, the targeted organization, or the victim. The Gremlin Stealer campaigns documented in recent threat intelligence reporting illustrate this well: the malware's command-and-control infrastructure rotated through cloud-hosted IPs spanning multiple continents, making geolocation-based blocking largely ineffective at keeping pace with the operational tempo of the campaign.
Mobile carrier networks present a different problem. Carrier-grade NAT (CGNAT) means that thousands of subscribers may share a single public IP address. Geolocation of that IP resolves to the carrier's gateway infrastructure, which may be hundreds of kilometers from any individual subscriber. Analysts who flag activity from a specific city based on mobile carrier IP data are often working from meaningless coordinates.
VPNs, residential proxies, and Tor exit nodes compound every one of these problems. The recent P2P botnet monitoring reports circulating in the threat intelligence community describe infrastructure that uses compromised residential systems as relay nodes, meaning that geolocation returns an ordinary residential ISP address in a country that has nothing to do with the actual threat actor's location. The FrostyNeighbor activity tracked by several threat intelligence teams in early 2026 used exactly this model, with legitimate-looking residential IP geolocation data consistently misdirecting initial triage efforts.
The Iranian APT Case and Why Attribution Gets Complicated
Recent reporting on Iranian APT group Screening Serpens' 2026 espionage campaigns provides a useful case study in how sophisticated actors exploit geolocation assumptions. The group's infrastructure used a combination of rented servers in European hosting facilities and compromised systems in Gulf Cooperation Council countries as staging nodes. Geolocation of their operational IPs consistently returned European or Middle Eastern countries. Analysts who stopped at geolocation were working with a picture that was accurate about the infrastructure location and misleading about the threat actor's origin.
Attribution requires correlating geolocation with ASN data, hosting provider reputation, timing patterns, TLS certificate reuse, malware family signatures, and behavioral indicators. Geolocation is one input among many, and it is the input most susceptible to deliberate manipulation by competent threat actors.
The Kimwolf botmaster case that resulted in arrests in the US and Canada in 2025 demonstrates the other side of this. Law enforcement was able to arrest actual individuals because attribution went well beyond geolocation. Transaction records, registration data, malware code analysis, and signals intelligence converged on real identities. Geolocation helped narrow the search space but was not the mechanism that produced actionable leads.
Where Geolocation Remains Useful in Practice
None of this means geolocation data should be discarded. It means it should be used for the right purposes, weighted appropriately, and never treated as authoritative on its own.
Geolocation at the country level is reliable enough for broad population-level analysis. If your authentication logs show login attempts from 40 countries in six hours and your user base is entirely in three countries, geolocation is telling you something real, even if individual data points are wrong. The signal is in the aggregate pattern, not in the specific attributed location of each IP.
Geolocation helps contextualize unknown infrastructure. If a previously unseen IP makes an API call to your environment and geolocation shows it belongs to a hosting provider in a country you have no business relationship with, that context is worth noting. It is not proof of malice. It is a reason to look harder at other indicators.
For compliance purposes, geolocation supports data residency controls and access logging. The important caveat is that these controls should be layered with other signals and should be treated as probabilistic rather than absolute. A compliance auditor asking where your data was accessed from can be given geolocation data with appropriate caveats about its reliability. A security engineer building access controls that depend entirely on geolocation is building on sand.
A Practical Accuracy Assessment for Your Environment
Most organizations have never actually tested how accurate their geolocation data is for the populations they care about. This is worth fixing before the next incident.
Start with your known population. Pull the IP addresses your authenticated users have connected from over the last 90 days. If your organization has a meaningful remote work population, you should have users connecting from home ISPs across your geographic footprint. Run those IPs through your geolocation vendor's API and compare the results against what you know about those users from HR records or account profiles. The error rate you discover is your actual operational error rate for user traffic, not the vendor's benchmark figure.
Repeat this exercise with your third-party integration traffic. API calls from partners, SaaS platforms, and internal automation systems all have known origins. Map IP geolocation results against what you know from contracts and documentation. You will likely find that cloud provider IPs geolocation data varies significantly by vendor, and that some traffic from known domestic systems resolves to international locations because of how traffic is routed through cloud infrastructure.
Document the results by traffic category. User authentication traffic, API integration traffic, and bot or crawler traffic each have different geolocation reliability profiles. Your incident response playbooks should reflect those differences. An analyst triaging a suspicious authentication attempt should know that residential ISP geolocation is moderately reliable at the country level, while cloud IP geolocation is primarily useful for identifying that the traffic came from cloud infrastructure, with the actual actor location being unknown.
Enriching Geolocation Data So It Actually Helps
Geolocation alone is a one-dimensional signal. Enriched with additional context, it becomes substantially more useful.
ASN data tells you who is responsible for routing the IP block, which often tells you more than geolocation alone. An IP that geolocates to Germany but belongs to an ASN associated with a bulletproof hosting provider is a different risk profile from an IP that geolocates to Germany and belongs to Deutsche Telekom's consumer broadband ASN. The TeamPCP supply chain campaign documentation from late May 2026 includes examples where ASN-level data was the critical differentiator between infrastructure that looked legitimate and infrastructure that was part of the attack chain.
WHOIS registration history adds temporal context. Fresh IP block registrations, recent transfers between registrants, and discrepancies between registration geography and geolocation geography are all worth surfacing in your enrichment pipeline. Many threat actors set up infrastructure quickly before an operation and abandon it afterward. The registration timestamp tells part of that story.
Passive DNS data shows you what domains have resolved to the IP over time. Geolocation places the server on a map. Passive DNS tells you what names have pointed to it and gives you the pivot points to discover related infrastructure. An IP that geolocates to Singapore but has hosted domains associated with phishing campaigns targeting North American financial institutions is worth significantly more investigative attention than the geolocation alone would suggest.
Threat intelligence feeds with historical data on the IP, including prior reports of abuse, botnet association, scanning activity, or malware hosting, provide the operational context that makes geolocation data meaningful. The Ghost CMS SQL injection campaign from early 2026 involved IPs that had clean geolocation data but deep histories in threat intelligence feeds. Organizations that enriched their data properly caught the connection. Those that relied on geolocation and basic reputation scores did not.
Geo-Blocking Policies That Account for Data Uncertainty
If your organization uses geolocation for blocking, the policy needs to be designed with data uncertainty in mind. Blocking a country does not block all traffic from threat actors in that country, and it will block some traffic from legitimate users who are not in that country.
For administrative interfaces and sensitive authentication endpoints, geo-blocking based on country is a reasonable risk reduction measure when combined with other controls. The policy should block traffic from countries you have no legitimate business in, accept that this will have false positives, and provide an exception process for legitimate edge cases.
For API endpoints and public-facing services, blanket geo-blocking based on country is harder to justify operationally. The false positive rate for cloud-hosted legitimate traffic is high enough that blocking by country will disrupt integrations you care about. Block by ASN category instead, separating known hosting and proxy networks from residential and business ISPs, and apply stricter authentication requirements to the hosting and proxy category.
Document the confidence level of your geolocation data in your blocking policies explicitly. If a block rule is based on geolocation data that you know has a 15% error rate in a particular region, the block rule should include a review cadence that accounts for that uncertainty. Automated blocks should have expiration policies and human review triggers built in.
When Geolocation Data Becomes a Liability
In legal and regulatory contexts, presenting geolocation data as a precise statement of fact creates exposure. If your incident report states that an attacker was located in a specific country and your evidence is a commercial geolocation database lookup, you are asserting something you cannot demonstrate. A competent defense attorney or a regulatory examiner asking about your methodology will expose that gap.
In incident response, overconfidence in geolocation data causes teams to pursue the wrong leads and miss the right ones. If your team concludes that an incident is low priority because the geolocation suggests the traffic came from an allied country, and the actual threat actor used infrastructure in that country as a proxy, you have let geolocation misdirect your investigation.
The Chinese surveillance camera access being sold on criminal forums, a story circulating in the threat intelligence community in mid-2026, involves compromised devices that are geographically distributed worldwide. The geolocation of a compromised camera in Brazil resolving to a Brazilian residential ISP gives no information about who is accessing it or from where. Defenders relying on geolocation to detect this kind of access will miss the threat entirely because the geolocation is accurate about the camera's location and irrelevant to the attacker's location.
Operational Takeaways for Security Teams
Geolocation belongs in your enrichment pipeline as a contextual signal, not a decisioning authority. Every tool that surfaces geolocation data to analysts should include visible caveats about confidence levels based on the IP category being analyzed. Cloud IPs get low geolocation confidence labels. Mobile carrier IPs get low confidence labels. Residential broadband IPs from major markets in stable network environments get moderate confidence labels. None get high confidence labels.
Incident response playbooks should include a step that explicitly asks: what is the geolocation data telling us, and what alternative explanations fit the same data? If the geolocation says Eastern Europe and the malware family is associated with a Latin American criminal group, the discrepancy is a data point, not a contradiction to be explained away.
Regular calibration exercises, testing your geolocation data against known populations quarterly, give you an operational accuracy figure that is specific to your environment and your vendor. That figure should inform how much weight analysts give geolocation signals in triage decisions.
Finally, invest in the enrichment stack that makes geolocation meaningful: ASN data, passive DNS, WHOIS history, and current threat intelligence feeds. Geolocation tells you roughly where infrastructure lives. The rest of the enrichment stack tells you what that infrastructure has been doing and who is likely operating it. The combination is genuinely useful. Geolocation alone is a rough sketch of a much more complicated picture.
