When the Attribution Was Wrong From the Start
In early 2024, a mid-sized financial services firm flagged a series of authentication attempts originating from what their SIEM reported as Eastern Europe. The security team applied geo-based risk scoring, escalated the events to their tier-two analysts, and began drafting a report attributing the activity to a known threat cluster operating out of that region. Three days later, after pulling the actual routing data, the traffic traced back to a cloud egress node in Virginia. The threat actor was using a leased VPS to proxy requests. The geolocation database the firm relied on had the ASN registered to a European entity — correct six months prior, before the infrastructure was resold and reassigned.
The attribution was wrong. The escalation consumed analyst hours. The report had to be retracted. And the actual threat, a low-and-slow credential stuffing campaign running through rotating proxies, continued for another 48 hours before detection methods caught up.
This scenario plays out more often than most security teams acknowledge. IP geolocation is treated as ground truth in SOC workflows, SIEM rules, risk scoring models, and compliance reports. The actual accuracy of that data is rarely interrogated until something breaks.
What Geolocation Data Actually Represents
IP geolocation does not locate a device. It locates the registration point of a network block, which is a legally and administratively defined concept, not a physical one. When a commercial geolocation database returns a country and city for a given IP address, it is returning the best available match between that IP block and a set of registration records, BGP routing data, and in some cases, actively probed latency measurements.
The primary sources feeding these databases include Regional Internet Registry (RIR) records from ARIN, RIPE, APNIC, LACNIC, and AFRINIC, BGP routing tables, WHOIS data, and proprietary datasets accumulated through CDN presence, DNS probing, and user-submitted corrections. Each source carries its own lag and accuracy profile.
RIR records are the most authoritative but reflect where an address block was originally allocated or assigned, not where it routes today. BGP tables are more current but operate at the prefix level, meaning a /16 might resolve to one country while specific /24 subnets within it route through another. Proprietary datasets improve granularity but introduce vendor-specific bias and variable refresh rates.
The practical result is a system that performs well at the country level — most studies put country-level accuracy between 95% and 99% for IPv4 — and degrades significantly as resolution increases. City-level accuracy in commercial databases typically falls between 50% and 80%, depending on the region and the provider. For cloud infrastructure, VPN services, residential proxy networks, and Tor exit nodes, the figures are worse still.
Where the Margin of Error Concentrates
Geolocation accuracy is not uniformly distributed. Certain categories of IP address carry systematically higher error rates, and these categories overlap substantially with the IP ranges threat actors prefer.
Cloud and hosting providers represent one of the highest-error categories. AWS, Azure, GCP, and their smaller competitors constantly expand, reallocate, and retire address space. They also operate globally distributed infrastructure under unified ASNs. An IP registered to an AWS ASN might be tagged as US-East in a database that was last updated two months ago, while the actual endpoint is in São Paulo or Singapore. The Gamaredon group, active through 2025 and documented as leveraging cloud tunneling infrastructure, exploits exactly this ambiguity by routing C2 traffic through cloud egress points that geolocation databases associate with benign North American or European providers.
Residential proxy networks present a different problem. These services route traffic through consumer broadband connections in hundreds of countries. The IP address belongs to a real residential subscriber, the geolocation correctly identifies their country and city, and the traffic is entirely synthetic. From a geolocation standpoint, the attribution is accurate. From a threat standpoint, the attribution is meaningless, because the actual operator is elsewhere.
Mobile carrier NAT and CGNAT pools compress thousands of users behind single IP addresses. A carrier operating in one country may peer traffic through another, causing geolocation databases to assign the country of the peering point rather than the subscriber. This is a known accuracy problem in Southeast Asia, parts of Africa, and mobile-heavy markets broadly.
VPN and proxy services are deliberately designed to break geolocation attribution. Commercial VPNs often maintain exit nodes that geolocation databases tag correctly as VPN infrastructure, but the routing path, the originating user, and the actual threat context remain invisible at the IP layer.
The Operational Cost in Real SOC Scenarios
Understanding where geolocation fails matters less as an abstract technical point and more as a question of what those failures cost operationally.
False positives generated by incorrect geolocation inflate analyst queues. If a SIEM rule fires on logins from countries flagged as high-risk and the underlying geolocation data incorrectly places cloud egress traffic in those countries, the alert volume is noise. Analysts investigating those alerts are not investigating real threats. In the context of rising ransomware attack rates — a trend consistent across threat intelligence reporting throughout the first half of 2025 — that queue inflation matters. Every hour an analyst spends on a miscategorized geo-alert is an hour not spent on lateral movement indicators or anomalous authentication patterns that actually precede encryption events.
False negatives are more dangerous. An actor operating from a sanctioned or high-risk region but routing through a clean US-registered cloud provider passes geo-based risk scoring without friction. The ToddyCat group, documented using compromised infrastructure and legitimate cloud services for persistence, benefits from this dynamic. Geolocation data correctly identifies the exit point as a trusted provider and the risk score stays low.
Compliance workflows introduce a third failure mode. Organizations subject to geographic access controls, whether for regulatory reasons or customer contractual requirements, sometimes rely on geolocation to enforce those controls. Using a database with 15% city-level error rates for enforcement decisions creates both legal exposure and security gaps simultaneously.
What Database Freshness Actually Looks Like in Practice
Most commercial geolocation providers publish update frequencies in their documentation. MaxMind's GeoIP2 databases, among the most widely deployed, update at intervals ranging from weekly to monthly depending on the product tier. IP2Location, ipinfo.io, and similar services have comparable schedules. The gap between an IP reassignment event and that event appearing in a downstream database can run from days to several months.
For static enterprise infrastructure, this lag rarely matters. For cloud-hosted, dynamically allocated, or broker-resold address space, the lag is operationally significant. The financial services firm in the opening scenario hit exactly this gap: the address block had changed hands, the RIR records had updated, but the commercial database had not yet propagated the change.
Security teams should audit the update frequency of every geolocation data source in their stack and compare that against the operational tempo of their detection workflows. A database updated monthly feeding a real-time detection rule is a structural accuracy problem, not a configuration edge case.
Building More Reliable Attribution Without Over-Relying on Geolocation
The goal is not to abandon geolocation data but to deploy it at the correct layer of confidence and combine it with signals that compensate for its weaknesses.
Layer geolocation with ASN classification. An IP that geolocates to Germany but belongs to an ASN primarily associated with residential proxy services carries a different risk profile than the same IP geolocating to Germany from a residential ISP. ASN-level context often tells you more about the nature of the traffic source than the country tag does. Providers like ipinfo.io, Shodan, and Team Cymru offer ASN type classification that distinguishes hosting providers, residential ISPs, mobile carriers, and proxy infrastructure.
Correlate with behavioral signals. Geolocation data becomes more reliable as corroborating evidence than as a primary signal. If an IP geolocates to the Netherlands, the ASN belongs to a cloud provider, the login time is outside the user's typical hours, and the user agent is inconsistent with their historical patterns, the geolocation data is one piece of a converging picture. Any one of those signals alone is insufficient; together they are operationally meaningful.
Use multiple geolocation sources and compare. Deploying two or three geolocation providers and flagging discrepancies between them identifies address ranges where database accuracy is actively contested. An IP that MaxMind places in France and IP2Location places in Romania is an IP worth deeper investigation regardless of which database is correct, because the disagreement itself indicates uncertainty in the underlying data.
Probe routing directly for high-stakes decisions. For authentication events triggering elevated risk decisions, BGP-level routing data through services like RouteViews or RIPE RIS provides ground-truth routing information independent of geolocation database lag. This is operationally expensive and not appropriate for all alert volumes, but for targeted investigations or privileged access decisions, it provides accuracy that commercial databases cannot match in real time.
Treat geolocation as probabilistic, not deterministic. SIEM rules, risk scoring models, and access control policies built on geolocation data should incorporate confidence weighting. A login from an IP that two databases agree is located in a sanctioned country warrants a different response than one where databases disagree or where the ASN classification suggests proxy infrastructure regardless of the listed country.
Specific Database and Tooling Recommendations
For teams building or auditing their geolocation stack, a few practical considerations apply across environments.
MaxMind GeoIP2 Precision services offer higher accuracy than the free GeoLite2 dataset and include connection type data useful for proxy and VPN detection. The City-level database performs materially better for North America and Western Europe than for other regions, which should inform confidence thresholds in those rule sets.
ipinfo.io provides ASN ownership and type data alongside geolocation, making it particularly useful for cloud infrastructure identification. Their privacy detection endpoint specifically flags VPN, proxy, Tor, and hosting provider traffic, which addresses several of the high-error categories discussed above.
Shodan's internetdb endpoint provides real-time data on open ports, tags, and ASN context for a given IP, supplementing geolocation with observable infrastructure characteristics. An IP hosting an OpenVPN service on 1194 combined with a geolocation tag deserves less confidence in that tag than an IP with no observable proxy-relevant services.
For threat intelligence enrichment platforms, both Recorded Future and Mandiant Advantage incorporate geolocation data alongside actor attribution, infrastructure clustering, and behavioral context. These platforms apply the corroboration model natively, which is why their outputs are more operationally reliable than raw geolocation database lookups used in isolation.
Calibrating Policy Decisions to Actual Accuracy Levels
Access control and threat response policies built on geolocation need accuracy thresholds matched to their enforcement function.
Hard blocks based solely on country-level geolocation are justifiable for organizations with no operational presence or user base in a given country and where compliance or contractual requirements demand geographic restriction. Country-level accuracy at 95%+ makes this a reasonable control, provided the exceptions process for VPN and proxy users is defined and the false positive cost is understood.
Soft controls, elevated risk scoring, additional authentication challenges, or analyst review, are appropriate for city-level geolocation data or for address ranges where database confidence is lower. Enforcing a hard block based on city-level data with 60% accuracy will generate a false positive rate that impairs legitimate users at scale.
Compliance reporting that includes geolocation attribution should document the data source, its update frequency, and its stated accuracy for the relevant region. A compliance audit that later reveals the geolocation data was materially incorrect creates liability that appropriate documentation and caveating would have mitigated.
What the Current Threat Landscape Demands
Groups like Gamaredon, documented in 2025 threat reporting as actively leveraging cloud tunneling and worker infrastructure, are structurally designed to defeat geolocation-based controls. Ransomware operators routinely stage their initial access through broker infrastructure that presents clean geolocation signatures. The campaigns targeting Meta account holders through AI support channels exploit platforms with globally distributed infrastructure, rendering the originating IP geolocation nearly irrelevant to the actual threat origin.
The practical implication is that geolocation accuracy matters most for the threat actors it is least effective against. Unsophisticated actors using their own infrastructure in high-risk regions are caught by geolocation-based controls. Sophisticated actors have already mapped those controls and route around them. Security operations that treat geolocation as a sufficient attribution layer are calibrated for the less dangerous threat.
That does not make geolocation worthless. It makes it one layer among several, with defined accuracy parameters, known failure modes, and specific scenarios where it adds reliable signal. The teams that use it well understand those parameters. The teams that get caught out are the ones that stopped asking what the data actually represents.
