The Trust Problem Buried Inside Every Geolocation Query
Security operations teams run geolocation lookups constantly. An alert fires, an analyst pulls the IP, and within seconds a country name appears on the screen. That country name then shapes the next ten decisions: escalation priority, block or monitor, notify or ignore, threat actor attribution. The problem is that the number sitting behind that country name is rarely discussed, and the implications of being wrong are rarely measured.
IP geolocation is a probabilistic inference, not a lookup against ground truth. The databases that power it are built from a combination of Regional Internet Registry (RIR) registration data, BGP routing tables, commercial data licensing, user-reported corrections, and in some cases latency triangulation. Each of those inputs carries its own staleness, bias, and coverage gap. When you stack them together, you get an accuracy figure that varies dramatically depending on what you are trying to resolve and at what granularity.
Understanding what that margin of error actually means in practice, and building operational workflows that account for it, is what separates teams that make confident decisions from teams that make fast ones.
Accuracy by Resolution Level: Where the Numbers Actually Stand
Country-level geolocation accuracy sits at roughly 95 to 99 percent for most commercial providers when measured against verified ground truth datasets. That sounds reassuring until you calculate what the error rate means at scale. If your environment processes 500,000 authentication attempts per month from external IPs, a 2 percent error rate translates to 10,000 misattributed origins. At country resolution, those errors tend to cluster around border regions, small island nations, and territories with complex RIR assignments.
City-level accuracy drops substantially. Depending on the provider and the region of the world, city-level geolocation accuracy ranges from 55 to 80 percent. For IPs in densely populated urban areas with well-documented infrastructure, accuracy improves. For IPs in rural regions, emerging markets, or areas with significant carrier-grade NAT (CGNAT) deployment, accuracy degrades sharply. The IP that your tool reports as originating in Frankfurt may be a CGNAT exit node serving customers across three countries.
Postal code and coordinate-level resolution is where geolocation becomes genuinely unreliable for security decision-making. Many providers default to placing unresolvable IPs at the geographic centroid of a country or region, which is why security analysts occasionally see clusters of suspicious activity appearing to originate from the exact geographic center of a country with no explanation.
The Infrastructure Gap That Skews Almost Every Reading
Three categories of infrastructure systematically degrade geolocation reliability and appear constantly in modern attack traffic.
VPNs and residential proxies register the IP in one country while the actual user operates from another. Commercial VPN providers rotate exit nodes across dozens of countries. Residential proxy networks route traffic through compromised or consenting consumer devices, meaning the geolocation is technically accurate for the device location but meaningless for the attacker's actual origin. The Gamaredon threat group, which has remained active through 2025 with updated tooling including tunnel-based infrastructure and cloud worker abuse, is a concrete example of a nation-state actor deliberately layering infrastructure across multiple jurisdictions to defeat geolocation-based attribution.
Cloud and hosting providers present a different problem. When an attacker spins up an instance in a cloud region, the geolocation reflects the data center, not the operator. An attacker in one country purchasing compute in another country appears to originate from wherever the data center sits. As ransomware groups increasingly stage their operations through cloud infrastructure, this pattern becomes more common. The headline that ransomware attacks are rising in 2025 is directly connected to infrastructure practices that make geolocation attribution systematically misleading.
Anycast and CDN infrastructure can cause a single IP address to geolocate differently depending on which provider's database you query, because the same address may be announced from multiple geographic locations simultaneously. For analysts investigating traffic hitting edge nodes, this creates genuine ambiguity that cannot be resolved through geolocation alone.
What the ToddyCat Campaign Reveals About Attribution Workflows
The ToddyCat threat actor, documented in ongoing research through mid-2025, uses email-based persistence mechanisms that blend into legitimate infrastructure. One operational pattern this group and similar actors share is deliberately selecting infrastructure with misleading geolocation profiles. By routing through regions that appear less threatening or that trigger fewer geo-based filters, they reduce the likelihood of automated blocking at the perimeter.
This is a deliberate exploitation of over-reliance on geolocation as a filtering signal. When security teams apply country-based allow or deny logic without secondary validation, they create a predictable gap that sophisticated actors specifically target. The operational lesson is that geolocation functions best as a coarse first filter, not as a final determination.
Building a Tiered Confidence Model for Geolocation Data
Rather than treating geolocation as binary, security teams benefit from assigning confidence tiers to geolocation data based on the corroborating signals available. This approach translates directly into more defensible escalation decisions and fewer false positives.
Tier One: High Confidence Geolocation
An IP qualifies for high confidence geolocation when multiple independent signals agree. This means the RIR registration, BGP origin AS, forward and reverse DNS, and at least one commercial geolocation database all point to the same country. Latency measurements, if available, are consistent with the claimed location. The IP is not associated with known VPN, proxy, or hosting provider ASNs. High confidence geolocation can reasonably inform automated policy decisions, though never as the sole input.
Tier Two: Moderate Confidence Geolocation
Moderate confidence applies when primary sources agree at the country level but secondary signals are absent or inconsistent. The IP may belong to a large ISP operating across multiple countries, or the BGP origin AS may be registered in a different country than the geolocation database reports. City-level data is present but unverified. At moderate confidence, geolocation should inform analyst prioritization, not trigger automated action.
Tier Three: Low Confidence or Unreliable Geolocation
Low confidence applies when the IP belongs to a hosting provider, known VPN or proxy service, Tor network, or CGNAT range. It also applies when databases disagree at the country level, or when the IP has recently changed geolocation assignment in database records. Low confidence geolocation is useful as context but should not drive any enforcement decision without substantial corroborating evidence.
Practical Implementation: What to Do This Week
The following steps give security operations teams a concrete path toward building more accurate geolocation workflows without requiring platform changes.
- Audit your geolocation sources. Identify every system in your environment that makes a geolocation query and what decision that query informs. This includes SIEM enrichment, WAF rules, authentication platform policies, and SOAR playbooks. Map each to a decision type and assess whether the confidence tier of the geolocation data matches the weight the decision carries.
- Cross-reference ASN data against geolocation data. Free and commercial ASN databases allow you to check whether the autonomous system that announced the IP is registered in the same country the geolocation database reports. Mismatches are a meaningful signal. Tools like the RIPE NCC's Routing Information Service (RIS) or Team Cymru's IP-to-ASN service provide this data at no cost for security research use.
- Flag hosting and proxy ASNs separately. Build or obtain a list of ASNs associated with major hosting providers, VPN services, and residential proxy networks. Traffic from these ASNs should receive a separate handling path regardless of what the geolocation says. The geolocation for a DigitalOcean exit node telling you the traffic is from Singapore is technically accurate and operationally meaningless for attribution.
- Add geolocation consistency checks to your enrichment pipeline. When enriching an alert, query at least two independent geolocation providers and log the results separately. When they disagree, flag the record automatically for analyst review rather than defaulting to one source. Disagreement itself is a threat signal worth tracking.
Practical Implementation: What to Do This Quarter
Longer-horizon improvements require process changes and tooling investment but deliver substantially better geolocation signal quality.
Integrate latency-based geolocation validation where possible. If your environment involves interactive sessions or repeated connections from the same IP, latency measurements can serve as a sanity check against stated geolocation. An IP claiming to be in London with round-trip latency consistent with East Asia is a strong indicator of proxy or VPN use. Some WAF and bot management platforms surface this data automatically. If yours does, build a rule that flags significant discrepancies.
Establish a geolocation accuracy feedback loop. When your team confirms the actual origin of a threat actor through investigation, log what the geolocation said at the time of the alert. Over six months, this produces an empirical accuracy baseline for your specific threat profile and your specific geolocation provider. That baseline is far more operationally relevant than vendor-published accuracy statistics, which are typically measured against general internet traffic, not adversarial traffic targeting your sector.
Review your geo-block policies against your actual threat model. Country-based blocking is a coarse control. Its value depends entirely on whether your adversaries use infrastructure registered in the blocked countries. As ransomware operators and nation-state actors increasingly operate through cloud providers in politically neutral jurisdictions, blanket country blocks capture less of the real threat while continuing to generate friction for legitimate users. Quarterly reviews should ask whether the block list is aligned with where observed threat activity actually originates in your enriched logs, not where it is assumed to originate based on public reporting.
Geolocation in Authentication Security: A Specific Pain Point
The current wave of credential-based attacks makes geolocation accuracy particularly consequential in authentication workflows. Recent reporting on account takeover campaigns, including attacks that used AI-assisted social engineering to compromise Instagram accounts through Meta's own support infrastructure, demonstrates that attackers frequently operate from infrastructure with plausible-looking geolocation data. A credential stuffing campaign routed through residential proxies will appear to originate from dozens of countries simultaneously, each with high-confidence geolocation, because the geolocation is accurate for the proxy devices being used.
For authentication security, this means geolocation should be one input into an impossible travel or behavioral anomaly calculation, not a standalone signal. A login from Germany is not inherently suspicious. A login from Germany followed twelve minutes later by a login from Australia from an account that has never traveled is suspicious regardless of how accurate the geolocation data for either location is. The behavioral pattern carries signal that the geographic data alone cannot provide.
Teams implementing impossible travel detection should calibrate their time window thresholds based on realistic travel times between the geolocated locations, use the actual coordinates returned by the geolocation query rather than country-level logic, and weight the confidence tier of both geolocation readings in the final risk score. A high-confidence Germany reading followed by a low-confidence Australia reading (routed through a hosting provider) is a higher risk signal than two moderate-confidence readings from adjacent countries.
Geolocation Accuracy in Incident Response and Attribution
During an active incident, geolocation data creates a specific pressure toward premature attribution. When an alert fires and the IP resolves to a country associated with a known threat actor group, analysts face a cognitive pull toward confirming that attribution rather than testing it. This is operationally dangerous.
The correct use of geolocation data during incident response is as a hypothesis generator, not a hypothesis confirmer. A Russian geolocation generates the hypothesis that the traffic may be associated with Russian-origin threat actors. That hypothesis then requires corroboration through TTPs, infrastructure relationships, malware characteristics, and targeting patterns before it should drive any attribution statement or threat actor identification. The Gamaredon group's 2025 infrastructure specifically exploits this tendency by maintaining components in multiple jurisdictions, making country-level geolocation unreliable as an attribution signal even for a well-documented group.
When documenting incidents for regulatory reporting, insurance claims, or law enforcement referrals, geolocation data should be clearly labeled with its confidence tier and source. Stating that an attack originated from a specific country based solely on IP geolocation is a misrepresentation of what the data actually shows, with potential legal and reputational consequences if the attribution proves incorrect.
Vendor Evaluation: Questions Worth Asking Before the Next Renewal
Security teams that rely on commercial geolocation providers for enrichment data should evaluate those providers against criteria that are directly relevant to security use cases rather than general-purpose geolocation accuracy.
- What is the update frequency for database records, and what percentage of records were updated in the last 30, 90, and 180 days?
- Does the provider distinguish between the IP's registered location and its likely physical location for mobile and CGNAT ranges?
- How does the provider handle IPs known to be associated with VPN, proxy, or hosting infrastructure? Are these labeled separately?
- What accuracy methodology does the provider use, and against what ground truth dataset is accuracy measured?
- Does the provider supply a confidence score per record, or only a location value?
- What coverage does the provider have for IPv6 space, and how does accuracy compare between IPv4 and IPv6 records?
The last point matters more each year. IPv6 deployment continues to expand across enterprise and consumer networks, and most geolocation databases carry substantially lower accuracy and coverage for IPv6 addresses than for IPv4. If your enrichment pipeline treats IPv6 geolocation data with the same confidence as IPv4 data, you are making decisions on a significantly weaker signal than you likely realize.
Where Geolocation Fits in a Mature Security Operation
Geolocation data is genuinely useful. It provides context that speeds analyst triage, enables coarse geographic filtering that reduces noise, and supports behavioral anomaly detection when combined with historical baselines. The operational problem is not that geolocation is unreliable, it is that the conditions under which it becomes unreliable are precisely the conditions that tend to involve sophisticated threat actors.
Mature security operations treat geolocation as one layer of a corroborated context picture rather than as a definitive data point. They maintain explicit confidence models, track accuracy empirically against their own incident data, and build geolocation disagreement itself into detection logic as a signal worth investigating. They also review their geolocation-informed policies regularly enough that those policies reflect where actual threats are observed, not where threats were expected based on older intelligence.
The teams that get burned by geolocation are the ones that stopped questioning it after the first implementation. The data looks authoritative, it appears instantly, and it carries a country name that feels like a fact. Treating it as a fact rather than an inference is where the operational risk lives.
