Detecting Abuse at the Network Layer: IP, Proxy, and Device Signals in Practice

What the Framework Adds

None of the four building blocks is new: NIST, the relevant RFCs, and W3C guidance already cover attribution, persistence, and fingerprinting individually. What this framework adds is a split between evidence and action. Four factors answer how much confidence the observations deserve, and a fifth, enforcement reversibility, asks how costly it would be to walk the response back. That split prevents correlated vendor labels from serving as independent evidence, and it prevents an uncertain inference from imposing a durable penalty.

The five factors map to five failure modes, from mistaken attribution to disproportionate enforcement. Teams should treat the framework as a review rubric for their own rules or models, calibrated to their outcomes, not a fixed table.

Start with the Threat Model

A signal's value depends on the abuse being investigated. A hosting provider's IP address matters during automated account creation or scraping; it says much less about whether an established user authorized a transaction. Credential stuffing follows a different pattern: OWASP defines it as the automated use of stolen username-password pairs to gain access to accounts, and attackers often spread attempts across many addresses to weaken per-IP controls.

Account takeover, fraudulent registration, payment abuse, and coordinated platform manipulation each read the same signals differently. In the recovery example, the question that matters is whether the attempt is legitimate or part of an account takeover.

How IP Data Supports Detection

Detection alert - Image | Shutterstock

An IP address is available at registration, authentication, recovery, and transaction time, and its value comes from the features built on top of it:

• IP geolocation estimates country, region, city, or time zone.
• ASN and ISP data identify the network announcing the address range.
• Reputation data records prior abuse tied to an IP, subnet, or ASN.
• Network velocity measures activity across an address or network.
• Account velocity measures repeated activity against one account, even when the source IP changes.

A hosting-ASN classification paired with high account velocity and an unfamiliar device deserves real weight. The same ASN on a long-established device with normal behavior adds little. In the recovery example, unfamiliar geography and a residential proxy carry limited attribution strength on their own; unusual recovery velocity or behavior would corroborate them.

Reputation data should account for age, source, and confidence, since mobile and residential addresses get reassigned quickly and old activity shouldn't create a lasting penalty. IPv4 sharing and rotating IPv6 addresses (RFC 8981) further undercut any attempt to treat address counts as actor counts.

From Signals to Decisions

A production risk system needs a clear path from raw data to action:

• Collection gathers network, device, account, transaction, and behavioral data.
• Normalization converts provider-specific labels into stable internal features.
• Contextualization compares the event against account history, network type, and threat model.
• Decisioning applies rules and, where appropriate, statistical or machine-learning models.
• Response selection matches the action to the confidence level.
• Feedback uses confirmed abuse, authentication results, reviews, recoveries, and support outcomes to adjust thresholds. Network risk-decision pipeline

Figure 1. A production abuse-detection pipeline converts raw signals into contextual decisions and uses observed outcomes to recalibrate the system.

Normalization also surfaces when several features describe the same evidence: IP reputation, hosting-ASN classification, and proxy status often come from one vendor and one underlying observation. Treating them as three independent signals overstates confidence; group correlated features or cap their combined contribution. For the recovery attempt, corroboration has to come from independent categories, such as device continuity, account history, behavior, or transaction context, not from three labels describing the same IP.

Distinguish Proxy and Device Signals

A proxy indicator should rarely trigger an automatic block. Proxy traffic typically carries low attribution strength and variable persistence, and it can sit on a densely populated network, so stronger or irreversible action needs independent corroboration. A known data-center proxy paired with high authentication velocity supports rate limiting; a low-confidence VPN signal on an established device may call for no action at all. Recent cross-layer latency research (Ramesh et al., 2024) shows proxy detection can combine network and application-layer observations while still weighing privacy tradeoffs.

A few distinctions do real work here:

• VPN versus transparent proxy. A VPN deliberately routes traffic through another endpoint; a transparent proxy gets introduced by the access network, without the user choosing one.
• Data-center versus residential proxy. Data-center traffic often signals automation; residential traffic can look like ordinary consumer access.
• Static versus rotating proxy. Stable addresses support correlation. Rapid rotation weakens per-IP velocity checks.
• Device continuity versus identity. Similar device characteristics suggest continuity, not proof of identity.

In the recovery example, neither the residential proxy nor the new device proves who is behind the request. Browser and device characteristics can support fingerprinting, but browsers and standards increasingly limit the exposed attributes to protect privacy: device recognition has to stay probabilistic (Doty and Ritter, 2025).

Correlating Connected Activity

A site open on a browser - Image | Shutterstock

Abuse often shows up as a cluster: accounts sharing devices, networks, payment instruments, addresses, or behavioral patterns. These links carry different weights. A shared IP is weak evidence on its own, since NAT, public Wi-Fi, and mobile routing routinely route unrelated users behind a single address.

Graph-based systems need limits on how far risk propagates: a high-degree identifier, shared by hundreds or thousands of accounts, should carry less weight than a rare one. Requiring support from another category, decaying older edges, and capping propagation depth are guardrails for local validation, not universal rules.

Carrier-grade NAT illustrates the problem: RFC 65928 reserves a shared address space for provider CGN deployments, where multiple subscribers sit behind the same IPv4 infrastructure. Residential proxies create the opposite pattern: rotating IPs keep per-IP velocity low, while repeated device traits, authentication timing, endpoint sequences, and failed-password patterns can still reveal coordinated activity.

Match Enforcement to Confidence

Risk systems should escalate in graduated steps: monitoring, rate limits, additional authentication, review, temporary holds, or restriction. The less reversible the action, the stronger the evidence needs to be. NIST's Digital Identity Guidelines use risk assessment to guide assurance decisions; the same principle applies here by analogy, matching the reversibility of a response to how confident the evidence is.

Figure 2. Enforcement should become stronger only as attribution, persistence, and independent corroboration justify less reversible actions

How to Read the Ratings

The table below uses qualitative prompts, not calibrated thresholds. A rating shifts with the threat model, provider accuracy, observation window, and account history.

• Attribution strength: Low, many actors plausible. Medium, a narrower set. High, tied to verified account or device continuity.
• Signal persistence: Low, ephemeral or easily reassigned. Medium, stable over a short window. High, repeats across real history.
• Population density: Low, few plausible users share it. Medium, shared but bounded. High, broad or heavily shared infrastructure.
• Independent corroboration: Low, one source or feature family. Medium, one added category. High, several aligned.
• Response reversibility: High, easy to undo with little harm. Medium, temporary friction or a hold. Low, durable and hard to appeal.

Signal	Attribution Strength	Persistence	Population Density	Corroboration Needed	Possible Response
Geolocation change	Low	Medium	High	Device or account history	Additional authentication
Hosting ASN	Low to Medium	Medium	Medium	Velocity or behavioral evidence	Monitoring or rate limiting
Data-center proxy with high velocity	Medium	Medium	Low to Medium	Account or device evidence	Rate limit or review
Shared mobile IP reputation	Low	Low	High	Strong independent evidence	Reduce weight
New device during recovery	Medium	Medium	Low	Account history or behavior	Step-up authentication or hold

In the recovery example, limited attribution and partial corroboration favor additional authentication or a temporary hold over immediate restriction.

Framework Applied to the Recovery Scenario

• Attribution strength, Low. The residential proxy and unfamiliar geography don't establish identity.
• Signal persistence, Low or unknown. The observations are new and haven't repeated.
• Population density, High. Residential proxy infrastructure can represent many unrelated users.
• Independent corroboration, Partial. The new device adds context, but account history and behavior remain thin.
• Enforcement reversibility, High. The evidence doesn't justify an irreversible restriction.
• Recommended response. Step-up authentication or a short temporary hold, then review the outcome before escalating further.

Measure Production Impact

Offline precision and recall miss the full effect of enforcement: challenged users abandon the process, and blocked events often produce no measurable outcome. Production evaluation should track incremental fraud or loss prevented, false-positive rates among established users, challenge completion and abandonment, account recovery and support contacts, decision latency, and performance across network types, regions, and account tenure.

Controlled rollouts should pick one primary success metric, such as incremental loss prevented, with false-positive rate and challenge abandonment as guardrails, and an observation window long enough to catch delayed fraud labels and recovery outcomes. Holdout traffic helps correct for blocked-event selection bias, but when an intervention decides which outcomes even become observable, the problem is selective labels, not ordinary missing data (Kleinberg et al., 2018). Update results as delayed labels arrive, and watch for feature drift as networks, classifications, and user behavior shift.

Apply Concrete Privacy Controls

Privacy controls should follow the signal's lifecycle; the NIST Privacy Framework offers a structure for minimization, purpose limitation, retention, access, and deletion:

• Collection: gather only what's needed for fraud prevention.
• Transformation: convert raw identifiers into derived features. Precise location, for instance, can shrink to a country-change flag.
• Storage: keep raw identifiers and derived features under separate retention rules, with role-based access and appropriate hashing or tokenization.
• Decisioning: use only the features the risk decision actually needs.
• Deletion: discard raw data once it's no longer needed for feature generation, investigation, or legal requirements.

Derived features can outlive the raw data behind them, but they're still sensitive and linkable. Regional requirements vary, so retention, access, review, and appeal need privacy and legal input from the start.

Scope and Limitations

This framework is a conceptual review tool, not an empirically validated model. IP geolocation, proxy classification, reputation, and device signals vary in accuracy and stability by provider, region, and observation window, so thresholds and response policies need validation against an organization's own outcomes. A network or device association shows correlation. It doesn't establish identity, common control, or intent.

Network Evidence Is a Starting Point

Reliable abuse detection starts by weighing four evidence factors, attribution strength, signal persistence, population density, and independent behavioral corroboration, and then applying a fifth constraint: enforcement reversibility. The recovery example carries the core principle. A new device, unfamiliar geography, or residential proxy can raise risk, but none of them is identity. Weak attribution and a crowded network call for more independent corroboration, and for a first response that's easy to reverse.

The scenarios in this article are illustrative and do not describe confidential employer systems, incidents, or internal decision policies.

References

1. Mueller, N. (n.d.) Credential Stuffing. OWASP Foundation. https://owasp.org/www-community/attacks/Credential_stuffing
2. Doty, N. and Ritter, T. (2025) Mitigating Browser Fingerprinting in Web Specifications. W3C Group Note. World Wide Web Consortium. https://www.w3.org/TR/fingerprinting-guidance/
3. Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C. and Azinger, M. (2012) IANA-Reserved IPv4 Prefix for Shared Address Space. RFC 6598. RFC Editor. https://www.rfc-editor.org/info/rfc6598
4. Temoshok, D., Proud-Madruga, D., Choong, Y.Y., Galluzzo, R., Gupta, S., LaSalle, C., Lefkovitz, N. and Regenscheid, A. (2025) Digital Identity Guidelines. NIST Special Publication 800-63-4. National Institute of Standards and Technology. https://pages.nist.gov/800-63-4/sp800-63.html
5. Gont, F., Krishnan, S., Narten, T. and Draves, R. (2021) Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. RFC 8981. RFC Editor. https://www.rfc-editor.org/info/rfc8981
6. National Institute of Standards and Technology. (2020) NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. https://www.nist.gov/privacy-framework/privacy-framework
7. Ramesh, R., Winter, P., Korman, S. and Ensafi, R. (2024) CalcuLatency: Leveraging Cross-Layer Network Latency Measurements to Detect Proxy-Enabled Abuse. Proceedings of the 33rd USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity24/presentation/ramesh
8. Kleinberg, J., Lakkaraju, H., Leskovec, J., Ludwig, J. and Mullainathan, S. (2018) Human Decisions and Machine Predictions. Quarterly Journal of Economics, 133(1), 237-293. https://www.nber.org/papers/w23180