How should fraud teams detect suspicious users when VPNs hide IP addresses?

Fraud teams should treat a VPN as a concealment layer, not proof of legitimacy. They need controls that correlate browser, device, and session signals so repeat abuse can still be linked across visits. Device fingerprinting, risk scoring, and step-up verification help identify users who rotate IPs, use incognito mode, or disable cookies to avoid basic blocklists.

How to spot fraud when IP address is no longer a reliable signal

VPNs, mobile carriers, and privacy tools can make ip reputation far less useful than it used to be. Fraud teams should shift from “where is this request coming from?” to “is this the same browser, device, and session behaving consistently over time?” That means combining multiple weak signals into a stronger risk picture instead of trusting any single indicator.

Good detection starts with correlation. A user who changes IPs but keeps the same device characteristics, browser configuration, timing patterns, and account behaviour may still be the same actor. This is why browser and device signals matter: they help separate legitimate network changes from repeated abuse that is trying to look fresh.

It also helps to treat privacy features as context, not innocence. Incognito mode, cookie clearing, and aggressive IP rotation can happen for legitimate reasons, but when those behaviours line up with high-risk actions, velocity spikes, or repeated failed verification attempts, they become part of the fraud story rather than a reason to dismiss it.

Which signals are more reliable than IP addresses?

Fraud teams usually get better results by combining signals that are harder to change all at once. Device fingerprinting can help cluster sessions that originate from the same browser or hardware profile. Session continuity, behavioural patterns, and transaction context can then show whether the activity is ordinary variation or a repeat pattern of abuse.

Risk scoring works best when it reflects the full context of the interaction. A single login from a VPN is not the same as a login from a VPN followed by password reset attempts, address changes, payout manipulation, or rapid account creation. The goal is to measure the pattern, not to punish a network choice.

Step-up verification is most useful when it is triggered by inconsistency. If a session looks unusual but not conclusively malicious, the safer move is to ask for stronger proof before allowing a sensitive action. That preserves conversion for normal users while adding friction only where the risk is concentrated.

Why VPN use creates a detection problem, not a detection dead end

VPNs are a concealment layer, which means they weaken IP-based blocklists and geolocation assumptions without eliminating the broader behavioural trail. In practice, that pushes fraud teams toward layered controls such as device reputation, account history, and cross-session linkage. A useful reference point is SonicWall VPN Mass Breach via Stolen Credentials, which shows how VPN access can be abused when teams rely too heavily on the perimeter signal.

That same logic is why remote access should be treated as an identity and trust problem, not just a network problem. NHIMG’s Remote Access Identity Guide covers the practical controls that matter here: MFA at the edge, device posture, ZTNA, and retirement of dormant access paths. Those controls do not remove fraud risk by themselves, but they reduce the number of low-quality assumptions a fraud model has to make.

For teams that want a broader control framework, NIST SP 800-207 Zero Trust Architecture reinforces the core principle that network location should not be treated as trust. That is directly relevant when VPNs make “known IP” a weak proxy for legitimacy.

Risk and Threat Considerations

When IP visibility disappears, the main risk is false confidence. Teams may over-block privacy-preserving users, or worse, under-detect repeat offenders who rotate network paths while reusing the same device, browser, or account behaviour. That creates a gap between perceived and actual risk, especially in onboarding, login, account recovery, and payout workflows.

Failure mechanism: Attackers and abusive users can reuse a stable device or browser profile while changing IP addresses, clearing cookies, or operating through proxy layers, which breaks simple blocklists and weakens geolocation checks.

Impact: Repeated abuse can continue across many sessions without triggering perimeter-based controls, increasing account takeover, promo abuse, payment fraud, and investigation cost.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Identity Inventory	Fraud detection depends on linking users and sessions across changing network paths.
Recommendation — Maintain reliable identity and session inventory so repeated abuse can be correlated across visits.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	VPN evasion often pairs with credential abuse and repeated authentication attempts.
	AC-7 — Unsuccessful Logon Attempts	Repeated failed logins and step-up triggers are useful fraud indicators when IPs vary.
	AU-6 — Audit Review, Analysis, and Reporting	Correlating device, browser, and session evidence requires reviewable telemetry.
Recommendation — Manage and monitor authenticators so reused access signals are harder to abuse. Tune lockout and retry controls to surface suspicious repeated access attempts. Centralize and review session telemetry to detect linked abuse across IP changes.
NIST Zero Trust (SP 800-207)	CA-07 — Continuous Diagnostics and Mitigation	VPN-concealed traffic needs continuous evaluation of context, not static trust.
Recommendation — Continuously evaluate user and device context before granting sensitive access.
MITRE ATT&CK	T1078 — Valid Accounts	Fraud rings often reuse real accounts while obscuring origin with VPNs.
	T1110 — Brute Force	IP rotation and VPN use often support repeated credential-guessing attempts.
Recommendation — Hunt for valid-account abuse that persists even when source IPs change. Detect repeated authentication abuse patterns that survive IP-based blocking.

Practitioner Guidance

What to prioritise: Link every sensitive action to a confidence score that includes device, browser, session, and account history, not just IP reputation. If the IP is new but the device and behaviour are familiar, treat it differently from a genuinely new actor.

What to verify: Before trusting an allow or deny decision, check whether your signals can still correlate the same user across sessions after cookie resets, browser changes, and VPN rotation. If they cannot, your fraud model is still too dependent on network location.

Decision rule: If a session is both high-value and low-confidence, step up verification before allowing the action. If the user repeatedly triggers that step-up across different IPs, investigate for coordinated abuse rather than isolated risk.

Practitioner takeaway: Fraud detection gets stronger when IP is demoted from a trust signal to one noisy feature among many. The practical objective is to preserve linkage across sessions well enough that changing networks does not meaningfully change the attacker’s identity.