The Assumption That Quietly Undermines Geolocation-Based Decisions
Most cybersecurity teams treat IP geolocation as settled science. An IP address resolves to a country, a city, sometimes a postal code, and the security stack makes a decision based on that data. Block the request, flag the session, or let it pass. The process feels deterministic, which is exactly why it creates risk when teams assign it more weight than it can bear.
The reality is that IP geolocation is a probabilistic inference, not a fact lookup. The databases powering most geolocation services map IP ranges to physical locations using a combination of regional internet registry records, BGP routing data, user-submitted corrections, and inference from surrounding allocations. Each layer introduces error, and those errors compound in ways that matter enormously when a team is trying to assess whether a connection originates from a threat actor in a sanctioned region or a legitimate remote worker.
Recent threat activity reinforces why this matters. The reconnaissance campaign documented in late July 2025, where an SSH bot profiled hardware resources before deploying a cryptominer, showed how adversaries deliberately source their initial probe traffic from IP ranges that geolocate cleanly to low-suspicion regions. The geolocation looked benign. The behavior told a different story. Teams relying primarily on geographic attribution missed the campaign's early footprint entirely.
Where the Data Actually Comes From and Why That Creates Gaps
Understanding geolocation accuracy starts with understanding the data pipeline. Commercial geolocation providers aggregate several source types: WHOIS and RDAP records from ARIN, RIPE, APNIC, and other regional registries; active and passive DNS data; BGP routing table snapshots; and proprietary correction datasets built from user feedback and direct ISP partnerships.
The problem is that none of these sources update continuously in lockstep with real-world IP allocation changes. Large ISPs reassign address blocks frequently. Cloud providers like AWS, Azure, and Google Cloud rotate addresses across regions constantly. A block that geolocated to Virginia last month may physically route through Oregon today while the geolocation database still points to its previous assignment. For enterprise security teams, this creates a category of false positives and false negatives that accumulates silently.
Accuracy also degrades significantly at the city and postal code level. Country-level geolocation for well-maintained IP ranges in developed internet infrastructure regions tends to be reasonably reliable, typically above 95% accuracy for major providers. City-level accuracy drops considerably, with published research suggesting figures between 50% and 80% depending on the region and provider. In parts of Africa, Southeast Asia, and Central Asia, country-level accuracy itself can fall below 80% due to sparse registry data and inconsistent routing documentation.
The Mirage Kitten campaign targeting the Middle East and Africa region illustrates this directly. Attribution frameworks that leaned heavily on geolocation data to characterize that threat actor's infrastructure ran into the exact coverage gaps that make geolocation least reliable in those geographies. Threat actors operating in or through regions with weaker geolocation coverage exploit that gap as a structural advantage.
Cloud Infrastructure Has Changed the Equation Permanently
Before cloud computing normalized elastic, globally distributed infrastructure, IP geolocation carried more operational weight because most IP addresses stayed attached to a physical network location for extended periods. A server in Frankfurt stayed in Frankfurt. An ISP in Seoul kept its assigned blocks pointed at Seoul.
Cloud infrastructure broke that model comprehensively. An attacker spinning up resources in a major cloud provider's environment can provision compute in any region in minutes. The resulting IP address will geolocate to that region accurately enough, but the attacker's physical presence is irrelevant to where the infrastructure lives. Chinese-speaking threat actors documented this quarter using AI-augmented tooling to orchestrate autonomous cyberattacks from cloud-provisioned infrastructure distributed across multiple regions specifically to fragment any geolocation-based attribution.
From a defensive standpoint, this means a connection geolocating to the United States or Western Europe carries no meaningful assurance about the actor behind it. The Cybercriminals selling access to Chinese surveillance cameras demonstrate the same principle in reverse: those devices generate traffic that geolocates to their physical deployment locations, but the command-and-control actors behind the access broker market could be anywhere. Geolocation tells you where the packet physically entered the internet, not who sent it or why.
IT administrators managing access controls need to account for this when designing geolocation-based policies. A rule blocking all traffic from certain countries provides some reduction in attack surface, but it provides no security guarantee, and it will generate operational friction for legitimate users traveling, using VPNs, or connecting through global CDN infrastructure that routes through unexpected regions.
Practical Accuracy Benchmarks Security Teams Should Work With
Rather than treating geolocation as accurate or inaccurate in binary terms, security teams benefit from working with accuracy estimates that reflect real-world measurement:
- Country-level accuracy: 95-99% for North America, Western Europe, Australia, and Japan. 85-95% for most of Asia and Latin America. 70-85% for parts of Africa and Central Asia. These figures vary by provider and degrade over time between database refresh cycles.
- City-level accuracy: 50-80% globally, with significant variation. Dense urban areas with well-documented ISP infrastructure tend toward the higher end. Rural areas, regions with limited ISP diversity, and areas served by mobile carriers operating large NAT pools tend toward the lower end.
- Postal code and coordinate accuracy: Useful as a rough signal only. Treat any decision that relies on sub-city geolocation as operating with substantial uncertainty.
- Mobile carrier IP ranges: Particularly unreliable. Carrier-grade NAT means thousands of users may share a single IP address, and that address's geolocation may reflect a carrier's network operations center rather than any user's physical location.
- VPN, proxy, and Tor exit node IP ranges: Geolocation data for these addresses reflects where the exit node sits, which has no relationship to where the user is located.
These benchmarks should inform how much weight any security control places on geographic signals. A control treating city-level geolocation with the same confidence as a verified identity attribute is miscalibrated in a way that will produce consistent errors.
The Operational Scenarios Where Accuracy Gaps Cause the Most Damage
Several specific operational scenarios surface repeatedly where geolocation accuracy limitations produce security failures worth examining directly.
Allowlisting Based on Geographic Origin
Some organizations configure policies that apply reduced scrutiny to traffic originating from their primary operating countries, reasoning that domestic traffic carries lower risk. This logic fails when adversaries provision infrastructure domestically or through domestic cloud regions. It also fails when legitimate foreign traffic geolocates incorrectly as domestic, bypassing controls it should have encountered.
The three-step terminal access attack chain documented against Siemens ROX II systems is a useful reference here. That attack sequence began with reconnaissance that would have appeared geographically unremarkable to any system applying location-based trust levels. The geographic signal provided no meaningful security value at any step in the chain.
Blocking Campaigns Against Known Threat Regions
Organizations under active threat from specific regional actors sometimes implement broad geographic blocks against source regions. These blocks provide some friction but create two operational problems. First, they misclassify traffic from those regions that geolocates to other regions due to database inaccuracies or attacker infrastructure choices. Second, they create false confidence that traffic passing the geographic filter is lower risk, when that traffic may be precisely the component of an adversary's operation that has been engineered to bypass geographic controls.
Ransomware groups provide the clearest examples. Ransomware activity rarely geolocates cleanly to any single region because the operational infrastructure spans multiple jurisdictions by design. The groups responsible for the ransomware campaigns currently dominating incident reports maintain infrastructure in cloud providers and compromised hosts distributed globally. Geographic filtering captures almost none of that attack surface.
Fraud Detection and Access Anomaly Scoring
Security teams frequently use geolocation to score authentication anomalies: a user whose last login geolocated to London suddenly authenticating from an IP geolocating to Singapore raises a flag. This application is more operationally sound than hard blocks, but it still requires calibrated expectations. A login from Singapore that actually originates from a VPN exit node in Singapore while the user sits in London is a false positive. A login from a domestic IP that geolocates correctly while the attacker uses a locally provisioned cloud instance is a true threat that geolocation scoring misses entirely.
Interpol's ongoing work leveraging international frameworks to curtail fraud payments demonstrates that effective fraud prevention requires behavioral and financial intelligence layers, not just geographic signals. The same principle applies at the network perimeter: geolocation is one input into a scoring model, not the decision itself.
Building a Geolocation Strategy That Reflects Actual Accuracy
The practical question for security teams is not whether to use geolocation data but how to integrate it with appropriate weight given its real-world accuracy characteristics. The following approach reflects how mature security operations teams calibrate geolocation as a signal.
Use Multiple Geolocation Providers and Compare Results
Different commercial geolocation databases disagree on a measurable percentage of IP addresses, particularly in underserved regions and for recently allocated blocks. Running the same IP against two or three providers and flagging disagreements as low-confidence resolutions allows the security stack to apply different handling to high-confidence versus uncertain geolocation results. Most commercial threat intelligence platforms support provider federation; the configuration overhead is low relative to the signal quality improvement.
Weight Geolocation by Region Reliability
Build your scoring logic to reflect actual regional accuracy differences. A geolocation resolving to a major US ISP with stable allocation history carries more confidence than the same geolocation signal for a mobile carrier range in a region with known database coverage gaps. This weighting can be implemented in SIEM logic or threat scoring engines without requiring custom geolocation infrastructure.
Pair Geolocation with ASN and Infrastructure Context
An IP address that geolocates to Germany but resolves to a cloud provider's autonomous system, a hosting company with a history of abuse complaints, or a known VPN provider's ASN is a different signal than an IP geolocating to Germany within a major residential ISP's address space. ASN context significantly improves the accuracy of geographic risk assessments by identifying when geographic signals are likely to be misleading because the underlying infrastructure is designed for geographic opacity.
Treat Geolocation Signals as Features, Not Decisions
Security controls that make hard allow or deny decisions based solely on geolocation are structurally misaligned with the actual accuracy characteristics of the data. Effective deployment uses geolocation as a feature in a broader decision model alongside behavioral signals, authentication history, device posture, timing patterns, and threat intelligence context. A connection from an unusual geography that also exhibits normal behavioral characteristics for that user account and authenticates with valid multi-factor credentials deserves different treatment than the same geographic signal combined with anomalous access timing and credential stuffing patterns.
Audit Your Geolocation Database Refresh Rates
Many security teams deploy geolocation databases and allow them to run for months or years without refresh. Database vendors update their records on varying schedules, but the operational infrastructure security teams defend changes faster than many refresh cycles accommodate. Automate geolocation database updates on a weekly or bi-weekly basis at minimum, and schedule quarterly audits of the provider's documented accuracy metrics for the specific regions relevant to your threat model.
Integrating Geolocation Into Threat Intelligence Workflows
The SSH bot campaign profiling hardware before deploying mining software illustrates a workflow lesson worth internalizing: geolocation data becomes most useful when it is correlated against threat intelligence about where specific campaigns are known to be staging infrastructure, rather than used as a standalone geographic filter.
When a threat intelligence feed attributes a specific IP range to an active campaign, the geolocation context for that range becomes part of the attribution picture rather than a primary signal. If the range geolocates to a region inconsistent with where the campaign's operators are believed to be based, that inconsistency is itself a useful data point about the campaign's infrastructure strategy.
Security operations teams running threat hunts benefit from using geolocation to generate hypotheses rather than conclusions. An authentication event from an unexpected country prompts a hunt workflow examining behavioral context, session characteristics, and correlated events, not an automated block. The hunt workflow determines the response. The geolocation data starts the conversation.
Microsoft's record patch volume this cycle, addressing 570 security flaws, is a useful reminder that defenders are managing an enormous volume of potential exposure points simultaneously. Geolocation-based controls that generate high false positive rates consume analyst time that could address confirmed threats. Calibrating geolocation to its actual accuracy levels reduces that false positive burden and keeps analyst attention on signals that carry more discriminative value.
What Security Teams Should Expect From Geolocation Going Forward
Geolocation accuracy for well-documented, stable IP ranges will remain reasonably reliable at the country level. The coverage problem is unlikely to resolve quickly for several structural reasons: IP allocation practices continue to evolve, IPv6 adoption creates new geolocation coverage challenges because IPv6 ranges are allocated differently than IPv4 blocks, and the proliferation of cloud infrastructure means an increasing share of internet traffic originates from addresses whose geographic location reflects cloud region placement rather than any operationally meaningful attribute.
The Xcode supply chain campaign and its infrastructure patterns, the AI-augmented autonomous attack tooling attributed to Chinese-speaking threat actors, and the distributed botnet campaigns targeting enterprise networks all share a structural feature: their operators understand geographic attribution limitations and build infrastructure strategies that exploit those limitations. Defenders who treat geolocation as a strong signal will consistently find themselves behind operators who understand the signal's weaknesses better than the defenders do.
The security teams operating most effectively with geolocation data are those who understand it as a probabilistic, regionally variable, infrastructure-dependent signal that performs best when it confirms other suspicious signals rather than when it stands alone as a primary control. Building security architecture around that accurate understanding of the data produces controls that are both less likely to block legitimate traffic and more likely to catch the threats that geolocation-based controls in isolation consistently miss.
