SaaS Account Sharing Detection in 2026: IP Signals, Proxy Review, and Buyer Criteria

The buyer problem: revenue leakage without brittle enforcement

B2B SaaS account sharing is a commercial problem before it becomes a security problem. One company might have ten paid seats and forty people using one shared login. Another might route offshore contractors through a corporate gateway. A third might be legitimate global usage from a newly expanded customer. The wrong control blocks a good account. The weak control turns license policy into a suggestion.

That is why account sharing detection needs a buyer framework. It is not enough to buy a lookup endpoint and write a country mismatch rule. Teams need to know which signals are available, how ambiguous cases are handled, how proxy or VPN traffic is reviewed, how usage is exported for revenue operations, and how policy can be rolled out without surprising customers.

Live competitor research shows the market moving beyond simple location lookup. IPinfo packages city-level geolocation, privacy detection, accuracy radius, residential proxy data, and enterprise integrations by plan. MaxMind separates geolocation, anonymous IP, and fraud-risk products for compliance and access use cases. IPQualityScore frames proxy checks around fraud score, VPN, Tor, bot, transaction, and account-abuse signals. ipgeolocation.io highlights location, network, security, batch, and accuracy fields. The buying question is no longer "Can I locate an IP?" It is "Can I use network evidence responsibly inside an access and revenue workflow?"

What account sharing detection should and should not do

Good policy starts with a careful boundary. IP intelligence can reveal patterns: new countries, broad accuracy radius, registered country mismatch, unusual ASN changes, data-center style networks, corporate gateways, and privacy-network behavior when the product exposes it. Those patterns help a team decide when to observe, step up, throttle, open a revenue conversation, or send a case to fraud review.

IP intelligence should not be treated as identity proof. A traveling executive can move across countries. A remote team can share a corporate VPN. A mobile carrier can make many users look like one location. A privacy relay can hide the user in a way that is legitimate for them and inconvenient for your policy. The practical workflow is to score consistency and confidence, not to accuse a customer because one field changed.

A buyer framework for SaaS license abuse review

Evaluate vendors and implementation plans against the policy you actually need. A seat-compliance workflow usually has different tolerance than a payment-fraud workflow. License overuse can often move through observe, notify, sales follow-up, and contract review. A payment or admin takeover signal may require a stronger step-up. Use the same lookup data, but keep the action model separate.

Step-by-step workflow

Start with a list of account-sharing hypotheses. Examples include "one login appears in several regions during the same workday," "concurrent users greatly exceed paid seats," "administrative sessions appear from a new country and ASN," or "a single shared credential alternates between consumer ISP and hosting networks." Each hypothesis should define the business action before you write the rule.

1. Capture session IP, account ID, user ID, timestamp, user agent, seat count, and current account state on the server side.
2. Call the lookup API from trusted infrastructure, not from a browser that exposes an API key.
3. Store only the fields needed for policy evidence: country, registered country, ASN, AS organization, organization, timezone, and accuracy radius.
4. Compare new sessions to known legitimate account history, corporate ASN allow lists, travel patterns, and support notes.
5. Run observe-only for at least one billing cycle or enough usage to see weekday, travel, remote work, and contractor patterns.
6. Promote only the clearest reasons into policy: review for revenue operations, step-up for admin risk, or rate limit for suspicious automation.

Technical implementation

The verified public endpoint is /v1-get-ip-details. The OpenAPI example uses an API key in thex-api-key header and returns a structured response with country, registered country, ASN, AS organization, organization, and city details.

curl -X GET "https://api.ip-info.app/v1-get-ip-details?ip=8.8.8.8" \
  -H "accept: application/json" \
  -H "x-api-key: $IP_INFO_API_KEY"

A shortened verified response shape looks like this:

{
  "ip": "8.8.8.8",
  "ptr": "dns.google",
  "countryCode": "US",
  "countryCode3": "USA",
  "countryName": "United States",
  "continentCode": "NA",
  "registeredCountryCode": "US",
  "asn": 15169,
  "aso": "Google LLC",
  "organization": "Google",
  "city": {
    "name": "Mountain View",
    "region": "California",
    "latitude": 37.4223,
    "longitude": -122.085,
    "accuracyRadius": 1000,
    "timeZone": "America/Los_Angeles",
    "areaCode": "650"
  }
}

The TypeScript policy below uses the lookup as one signal. It does not block from raw country alone. It treats a familiar corporate ASN differently from an unknown network, and it returns reason codes that revenue operations or support can inspect.

type IpDetails = {
  ip: string;
  countryCode?: string;
  registeredCountryCode?: string;
  asn?: number;
  aso?: string;
  organization?: string;
  city?: {
    accuracyRadius?: number;
    timeZone?: string;
  };
};

type AccountContext = {
  accountId: string;
  licensedSeatCount: number;
  activeUsersLastHour: number;
  knownCorporateAsns: number[];
  billingCountry?: string;
  previousCountries: string[];
};

type AccountSharingDecision = {
  action: 'allow' | 'observe' | 'step_up' | 'review';
  reasons: string[];
  evidence: {
    ip: string;
    countryCode?: string;
    registeredCountryCode?: string;
    asn?: number;
    accuracyRadius?: number;
  };
};

export function evaluateAccountSharingRisk(
  ipDetails: IpDetails,
  account: AccountContext,
): AccountSharingDecision {
  const reasons: string[] = [];
  const isKnownCorporateNetwork = ipDetails.asn ? account.knownCorporateAsns.includes(ipDetails.asn) : false;

  if (account.activeUsersLastHour > account.licensedSeatCount * 2 && !isKnownCorporateNetwork) {
    reasons.push('active_users_exceed_seat_pattern');
  }

  if (
    ipDetails.countryCode &&
    account.billingCountry &&
    ipDetails.countryCode !== account.billingCountry &&
    !account.previousCountries.includes(ipDetails.countryCode)
  ) {
    reasons.push('new_country_for_billing_profile');
  }

  if (ipDetails.countryCode && ipDetails.registeredCountryCode && ipDetails.countryCode !== ipDetails.registeredCountryCode) {
    reasons.push('observed_country_differs_from_registered_country');
  }

  if ((ipDetails.city?.accuracyRadius ?? 0) > 500) {
    reasons.push('broad_location_radius');
  }

  if (reasons.includes('active_users_exceed_seat_pattern') && reasons.length > 1) {
    return {
      action: 'review',
      reasons,
      evidence: {
        ip: ipDetails.ip,
        countryCode: ipDetails.countryCode,
        registeredCountryCode: ipDetails.registeredCountryCode,
        asn: ipDetails.asn,
        accuracyRadius: ipDetails.city?.accuracyRadius,
      },
    };
  }

  return {
    action: reasons.length > 0 ? 'observe' : 'allow',
    reasons,
    evidence: {
      ip: ipDetails.ip,
      countryCode: ipDetails.countryCode,
      registeredCountryCode: ipDetails.registeredCountryCode,
      asn: ipDetails.asn,
      accuracyRadius: ipDetails.city?.accuracyRadius,
    },
  };
}

For data or finance teams that prefer offline review, the same endpoint can enrich a sampled export. Keep the job server-side, pass keys through environment variables, and record only the policy fields you actually need.

import os
import requests

def lookup_ip(ip_address: str) -> dict:
    response = requests.get(
        "https://api.ip-info.app/v1-get-ip-details",
        params={"ip": ip_address},
        headers={
            "accept": "application/json",
            "x-api-key": os.environ["IP_INFO_API_KEY"],
        },
        timeout=3,
    )
    response.raise_for_status()
    return response.json()

details = lookup_ip("8.8.8.8")
print({
    "ip": details.get("ip"),
    "country": details.get("countryCode"),
    "registered_country": details.get("registeredCountryCode"),
    "asn": details.get("asn"),
    "organization": details.get("organization"),
})

How to handle VPN, proxy, Tor, and privacy networks

If a customer uses a VPN, proxy, Tor exit, privacy relay, or corporate tunnel, the location you see may be the egress point rather than the human. That does not make the account abusive by itself. It lowers confidence in geography-based enforcement and raises the importance of other evidence: contract terms, number of active people, device consistency, billing country, known corporate networks, and admin sensitivity.

A balanced policy uses actions with different levels of friction. "Allow" is appropriate for known, consistent patterns. "Observe" is useful when a signal is new but low-risk. "Step up" belongs on admin actions, security-sensitive settings, and payment changes. "Review" fits license conversations and suspicious patterns that should not be resolved by software alone.

Cost and procurement considerations

Account sharing review can become expensive if every page view triggers a lookup. The live pricing page states that one credit equals one IP lookup and that plans include real-time geolocation, ISP and organization detection, proxy and VPN detection, bulk lookup, API key controls, and usage notifications. Use those controls deliberately.

In practice, most SaaS teams should lookup at account creation, login, admin actions, billing changes, and a sampled stream of ordinary sessions. Cache stable results for short windows, but avoid letting stale network data drive enforcement. Use usage exports to show finance which workflows consume credits and to separate revenue-protection checks from analytics enrichment.

Policy rollout guardrails

The best rollout is deliberately boring. Start with a named policy owner, a known set of routes, and a clear review queue. Keep the first release out of customer-facing enforcement. Show support and revenue teams the evidence a case will contain: account ID, seat count, active-user count, IP, country, registered country, ASN, organization, accuracy radius, and reason codes. If that evidence would not be enough for a fair customer conversation, the rule is not ready.

Then choose thresholds by business impact. A low-priced self-serve plan might tolerate a soft in-app nudge before a sales motion. An enterprise admin session from a new country and network may deserve step-up authentication immediately. A contractor network that appears across several accounts might be normal for one customer and suspicious for another. Write the difference into policy. Account sharing detection is strongest when IP intelligence narrows the review set and humans keep context in the loop.

Internal links worth pairing with this workflow

Start by testing response shape on the live lookup demo, then compare credit economics on pricing. Developers should keep the OpenAPI reference nearby. For adjacent implementation patterns, read the API governance guide, the reason-code workflow, and the consumer privacy networks guide.

FAQ

CTA: prove the pattern before you enforce it

The safest first step is not a block list. It is a measured review. Run a real lookup, inspect country, registered country, ASN, organization, timezone, and accuracy radius, then map those fields to your own seat policy. When the response fits, create scoped API keys and start with observe-only account evidence before turning it into revenue or access action.