A Login From São Paulo That Wasn't
A financial services firm running Entra ID detects an authentication event flagged by their SIEM. The source IP resolves to São Paulo, Brazil. The account belongs to a developer who, according to HR records and VPN logs, has been working from Austin, Texas for the past three years. The security operations team treats the geolocation data as ground truth, escalates to an incident, and locks the account. Forty minutes later, the developer calls the help desk — he was logging in from a cloud IDE hosted on an AWS node in us-east-1, which routes traffic through a Brazilian CDN edge node.
The geolocation wasn't wrong, exactly. It was just answering a different question than the one the SOC thought it was asking. This is the core problem with IP geolocation in security operations: it delivers a location for the infrastructure, not necessarily for the person or process behind the connection.
What Geolocation Data Actually Measures
IP geolocation works by mapping IP address ranges to physical or administrative locations through several overlapping data sources. Regional Internet Registries such as ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC publish registration data that associates IP blocks with organizations and, by extension, with the country or region where that organization operates. Commercial geolocation databases supplement this with active probing, BGP routing analysis, latency triangulation, and user-reported data collected through browsers and mobile applications.
The accuracy ceiling for each geographic level varies significantly. Country-level accuracy from reputable commercial providers sits around 95 to 99 percent for consumer traffic under normal conditions. That number drops as the geographic granularity increases. City-level accuracy typically falls between 60 and 80 percent, and street or postal-code precision is unreliable enough that most security use cases should not rely on it for operational decisions.
For cybersecurity teams, those percentages carry real weight. A 95 percent country-level accuracy rate means that for every 100 IP-based alerts your system generates, roughly five will point to the wrong country. At enterprise scale, with thousands of authentication events per day, that volume of mislabeled geography creates both false positives and, more dangerously, false negatives.
Infrastructure Patterns That Break Geolocation Assumptions
Several categories of legitimate and malicious infrastructure routinely produce geolocation results that diverge from the actual origin of the traffic. Understanding these patterns is the first step toward calibrating how much weight to assign geolocation signals in any given detection scenario.
CDN and Cloud Egress Nodes
Content delivery networks and cloud platforms route traffic through geographically distributed edge nodes. When a developer in London runs code through GitHub Codespaces or Google Cloud Shell, the egress IP may geolocate to Virginia, Iowa, or Singapore depending on which region the platform provisioned. The AWS credential leak incidents that surfaced recently — where hundreds of exposed keys gave attackers full control over corporate accounts — demonstrated exactly this pattern in reverse: threat actors using compromised cloud credentials to spin up compute in regions that appear benign to naive geolocation filters, making their activity blend in with normal cloud egress patterns.
VPN and Proxy Routing
Both legitimate privacy tools and attacker infrastructure deliberately separate the geographic origin of a request from the IP address that delivers it. A ransomware operator sitting in Eastern Europe commonly exits through a commercial VPN node in Frankfurt or a residential proxy in Ohio. The SynkLoader malware distribution campaign using Microsoft Teams phishing relied on infrastructure obfuscated through multiple proxy layers, meaning any geolocation-based triage of the delivery IPs would have pointed investigators toward hosting providers in Western Europe rather than the actual origin. Geolocation tells you where the packet left — it does not tell you where the operator sat.
CGNAT and Shared IP Infrastructure
Carrier-grade NAT pools a large number of end users behind a single public IP address. Geolocation data for these IPs often reflects the ISP's regional operations center rather than the neighborhood or city where the actual subscriber lives. In environments where you're correlating geolocation data against expected user locations, CGNAT-sourced connections will consistently produce city-level mismatches even for completely legitimate traffic.
Anycast Routing
Anycast assigns the same IP address to multiple physical servers distributed globally, routing each request to the topographically nearest instance. DNS infrastructure, DDoS scrubbing services, and large-scale CDN providers use anycast extensively. Geolocation databases often pick one location for an anycast address — frequently whichever data center was most recently probed — and apply it universally, even though requests to that IP may actually terminate on different continents.
Blockchain-Based C2 Infrastructure
Advanced threat actors have moved toward infrastructure models that further complicate geolocation analysis. The analysis of Aeternum's blockchain-based command-and-control operations is instructive here. When C2 communications are embedded in blockchain transactions or distributed across decentralized protocols, the observable IP addresses involved belong to public blockchain nodes distributed globally. Geolocating those IPs tells you which nodes in the network you're looking at — it tells you nothing about where the operator is or where the actual malicious payload originates. Geolocation-based filtering on these IPs is essentially useless as a primary control.
Building a Calibration Framework for Operational Use
The goal isn't to stop using geolocation data — it remains a genuinely useful signal in the right context. The goal is to treat it as one data point in a weighted scoring model rather than a binary decision gate.
Establish a Baseline for Expected Geolocation Distribution
Before geolocation data can drive any detection logic, you need to know what normal looks like for your environment. Pull 90 days of authentication and network connection logs and map the observed geolocation distribution for each user, service account, and application. Flag accounts with historically stable geolocation patterns separately from accounts that routinely connect from cloud infrastructure or through VPNs. A developer who consistently authenticates from AWS us-east-1 nodes is not exhibiting suspicious behavior when they do it again — but an accounting manager who has never done so presents a different risk profile.
This baseline work also surfaces infrastructure you may not have fully inventoried. Connections that geolocate to unexpected regions often trace back to cloud services, SaaS integrations, or partner APIs that weren't formally catalogued. Discovering these during baseline analysis prevents false escalations later.
Layer Geolocation Against ASN and Hosting Context
A raw geolocation result tells you a country and sometimes a city. Pairing that with ASN data tells you whether the IP belongs to a residential ISP, a commercial cloud provider, a VPN service, or a hosting company with a poor reputation history. An authentication event geolocating to Germany that originates from a known residential ISP ASN carries different risk weight than the same geolocation from a bulletproof hosting ASN with a history of abuse complaints.
Several commercial threat intelligence platforms provide combined geolocation and ASN context in a single lookup. If you're building this capability from open sources, MaxMind's GeoLite2 provides country and city data, while RIPE's routing registry and BGP data sources such as RouteViews give you the ASN association. Neither source alone is sufficient — combining them produces materially better signal quality.
Apply Velocity and Impossible Travel Logic
Impossible travel detection remains one of the most reliable geolocation-derived signals in identity security. If an account authenticates from New York at 09:00 and from Tokyo at 09:45, the geolocation data doesn't need to be street-level accurate to flag a problem — the physics of the situation do the work regardless of city-level precision.
Implement impossible travel checks at the authentication layer for privileged accounts and any account with access to sensitive data or production infrastructure. Set the velocity threshold conservatively — a realistic minimum transit time between regions with appropriate buffer for time zone conversions and log timestamp variance. Many Entra ID and Okta deployments expose impossible travel alerts natively; the configuration task is defining what counts as impossible for your specific user population, including legitimate frequent travelers and employees who work across time zones.
Don't Use Geolocation Alone to Gate Access
Blocking authentication attempts or network connections based solely on geolocation is a policy approach that creates more operational friction than security value in most enterprise environments. Instead, use geolocation mismatch as a risk factor that triggers step-up authentication, additional logging, or analyst review — not as a hard block.
For critical systems where geo-blocking is appropriate, layer it with other signals. A connection from a country not in your expected user geography, combined with an ASN known for VPN or proxy services, combined with an account that hasn't been active in 30 days, represents a meaningfully higher risk signal than any one of those conditions alone. Build your detection logic to weight the combination, not the individual data point.
Geolocation Accuracy in Threat Intelligence Workflows
When a security operations team receives an IOC containing an IP address — whether from a commercial feed, an industry sharing group, or their own honeypot infrastructure — geolocation data shapes how that indicator gets triaged. The practical risk is that teams over-index on the geographic label and under-investigate the underlying infrastructure behavior.
A malicious IP that geolocates to a country your threat model treats as low-risk may receive less analyst attention than one geolocating to a country flagged as high-risk, even if both IPs are equally involved in active attack campaigns. Malware crypting services and the actors who sell them operate from infrastructure distributed across dozens of countries, selected specifically to avoid geographic profiling. Treating geolocation as a proxy for threat level bakes attacker evasion into your own detection logic.
The more defensible workflow treats geolocation as context for an indicator rather than an assessment of its threat level. An IP that geolocates to the Netherlands but belongs to an ASN associated with bulletproof hosting, appears in multiple abuse feeds, and has an age of less than 30 days is high-priority regardless of what country the database returns. An IP that geolocates to Russia but belongs to a well-known CDN with no abuse history probably warrants less immediate escalation than the geographic label alone would suggest.
Specific Scenarios Where Accuracy Gaps Create Operational Risk
Incident Response Attribution
During active incident response, geolocation data frequently gets used to form early hypotheses about threat actor origin or affiliation. This is understandable — teams under time pressure reach for available data. The risk is that these early hypotheses calcify into assumptions that shape the rest of the investigation.
Establish a clear policy within your IR team that geolocation-based attribution is classified as a working hypothesis until corroborated by additional technical evidence such as TTPs, malware artifacts, infrastructure reuse patterns, and linguistic analysis. The investigation of campaigns like Aeternum's blockchain-based C2 operations showed that sophisticated actors deliberately route through infrastructure in multiple jurisdictions to muddy exactly this kind of attribution analysis.
Compliance and Data Residency Verification
Organizations subject to data residency requirements sometimes use geolocation to verify that data processing stays within approved jurisdictions. This application requires higher accuracy than most security detection use cases, and the gaps are more consequential. Cloud providers offer region-locked services with contractual guarantees about data location — relying on IP geolocation to verify compliance with those guarantees is not a substitute for querying the cloud provider's own APIs for resource location data.
Fraud Detection at the Application Layer
E-commerce platforms, financial applications, and identity verification systems use geolocation as one signal in fraud scoring. The residential proxy ecosystem has grown specifically to defeat this use of geolocation, routing fraudulent transactions through IP addresses that geolocate to the same city as the victim whose credentials are being abused. Detection that relies primarily on geolocation consistency will miss this class of fraud entirely.
Keeping Geolocation Data Current
IP address assignments change. Organizations return blocks to RIRs, cloud providers reallocate ranges, and ISPs reassign addresses across regions. Geolocation databases that were accurate six months ago may be meaningfully wrong for specific IP ranges today. This staleness risk is highest for cloud provider IP ranges, which reallocate more frequently than static enterprise or ISP allocations.
For security operations using geolocation data programmatically, implement a refresh cadence for your geolocation database that matches the sensitivity of your use case. Most commercial providers offer update cycles ranging from daily to monthly. Daily or weekly updates are appropriate for high-frequency use cases such as authentication risk scoring. Monthly updates may be acceptable for lower-frequency use cases such as periodic compliance reporting.
Additionally, maintain a local override table for IP ranges that you've manually verified through direct investigation or vendor confirmation. When your incident response team determines that a specific IP belongs to a known service despite the geolocation database returning unexpected results, capture that mapping locally so subsequent automated lookups don't repeat the same mislabeling.
Integrating Geolocation Into a Mature Detection Stack
The security teams that use geolocation most effectively treat it as one layer in a signal stack rather than a standalone verdict. In practice, this means building detection rules that combine geolocation with authentication behavior, ASN classification, threat intelligence feed matches, time-of-day patterns, and device or user-agent consistency.
A SIEM rule that fires on any login from a country outside the expected user geography will generate noise. A SIEM rule that fires when a login comes from outside expected geography, from an ASN classified as hosting or VPN infrastructure, during hours inconsistent with the account's historical pattern, for an account that has recently had a password reset, generates a genuinely high-fidelity alert that warrants immediate analyst attention.
The Microsoft patch cycle that recently addressed nearly 400 security vulnerabilities is a reminder that attackers move quickly once vulnerabilities become public. Geolocation data plays a role in detecting the early scanning and exploitation attempts that follow disclosure — but only when it's correlated with the behavioral signatures of exploitation, not treated as a standalone filter.
Practical Takeaways for Security and IT Teams
- Treat country-level geolocation as reasonably reliable and city-level as directional at best. Build detection thresholds accordingly — country-level mismatches warrant investigation, city-level mismatches warrant noting in context.
- Build a geolocation baseline per user and service account before deploying any geolocation-based detection rules. Rules without a baseline generate noise that trains analysts to ignore alerts.
- Combine geolocation with ASN classification in every lookup that informs an operational decision. The hosting context of an IP is often more actionable than its geographic label.
- Apply impossible travel detection for privileged accounts as a high-priority control. This is the geolocation use case with the best signal-to-noise ratio in most enterprise environments.
- Refresh your geolocation database on a schedule that matches your use case sensitivity. Stale data is a systematic source of both false positives and false negatives.
- Maintain local override tables for IP ranges your team has directly investigated and verified. Institutional knowledge about your specific traffic patterns is more accurate than any commercial database for your own environment.
- Document geolocation-based conclusions in incident reports as hypotheses, not facts, until additional evidence corroborates the geographic inference.
Geolocation data earns its place in a security operations stack when it's used to add context and raise or lower risk scores — not when it's used as a single-factor decision engine. The teams that get the most value from it are the ones who understand precisely what it measures and exactly where that measurement stops being reliable.
