What happens when fraudsters use incognito mode and VPNs together?

Incognito mode and VPNs can hide the obvious identifiers that many teams rely on, but they do not erase browser and device characteristics. If security controls depend only on IP address, cookies, or session history, attackers can keep returning under new appearances. Stronger identity signals are needed to preserve continuity across visits.

How Incognito Mode and VPNs Change the Fraud Signal

Used together, incognito mode and a VPN can strip away some of the easiest identifiers, especially the visible IP address and the local browser state many fraud controls lean on. That makes the first visit look cleaner than it really is. The problem is that these tools change the surface, not the underlying device and browser profile that advanced controls can still inspect.

The practical consequence is that fraud teams that treat IP, cookies, or a saved session as the main continuity signal will lose visibility quickly. A returning actor can appear as a “new” visitor even while the browser build, device traits, timing patterns, and interaction behavior remain consistent enough to link activity.

That is why this is less about concealment than about control fragility. If the detection model assumes one identifier equals one person, fraudsters can rotate those identifiers faster than the system can reconcile them.

What Still Gives the Fraudster Away

Incognito mode prevents easy local persistence, but it does not make the browser stateless in the way many people assume. The browser still exposes a combination of characteristics that can be used for continuity, including configuration details, rendering behavior, platform traits, and other signals that are difficult to change quickly without breaking normal use.

A VPN mainly changes network attribution. It can make two sessions look geographically and operationally different at the IP layer while leaving the rest of the environment intact. That means a fraud workflow that relies on “new IP equals new user” is too shallow, especially when the same device returns repeatedly through different exit nodes.

More robust decisions come from correlating multiple weak signals into a stronger risk picture. The important question is not whether one identifier changed, but whether the broader pattern still matches a known device, known behavior, or known abuse path.

Why This Matters for Fraud Controls and Identity Continuity

Fraudsters combine privacy tools because they are trying to break continuity. When a control stack depends on single-point identifiers, the attacker only has to defeat one layer to appear legitimate again. That is why stronger identity signals, step-up checks, and device-linked risk scoring are more effective than treating IP reputation as a primary gate.

For teams that want a security model rather than a blocklist, NIST SP 800-207 Zero Trust Architecture reinforces the same principle: trust should be continuously evaluated, not granted because a request arrives from a familiar address or session pattern. The most useful fraud defense is the one that can tolerate changing network appearance without losing continuity of the actor.

That is also why remote access journeys need stronger entry controls than “does the browser look new.” NHIMG’s Remote Access Identity Guide is directly relevant here because VPN use, dormant accounts, MFA, device posture, and replacement access paths all affect whether a returning actor can be distinguished from a legitimate one.

Risk and Threat Considerations

When fraud systems over-weight IP address, cookies, or session history, incognito mode plus VPN use creates a predictable evasion path. The actor can repeatedly re-enter the service while shedding the most obvious continuity markers, which increases account takeover risk, synthetic identity reuse, and repeated abuse of onboarding or login flows.

Failure mechanism: The control fails when it treats network identity and browser state as sufficient proof of continuity, allowing the same actor to reappear with a fresh IP and empty local storage while retaining the same device- and behavior-level footprint.

Impact: Fraud review becomes noisier and slower, legitimate users may face more friction, and attackers gain extra room to test credentials, probe controls, or keep recycling sessions until a weaker path succeeds.

Standards & Framework Alignment

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

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 — Physical Devices and Systems Inventory	Device continuity helps distinguish returning fraud actors from new visitors.
	PR.AA-05 — Authenticator Management	Fraudsters evade weak session and access assumptions when authentication continuity is brittle.
	DE.CM-09 — Network Monitoring	Repeated access through VPNs requires monitoring for anomalous network and session patterns.
Recommendation — Inventory and correlate device signals that persist across sessions. Strengthen authentication so changing IPs do not reset trust. Monitor for repeated abuse patterns across changing network paths.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Stronger identity proofing and authentication reduce reliance on IP and cookie continuity.
	IA-5 — Authenticator Management	Fraud controls depend on managing authenticators and session continuity securely.
	AU-6 — Audit Record Review, Analysis, and Reporting	Correlation across changing IPs and sessions depends on reviewing access evidence.
Recommendation — Require stronger identity checks than network location alone. Rotate and govern authenticators so reused access is harder to disguise. Analyze logs for repeated activity that survives IP and cookie changes.
NIST Zero Trust (SP 800-207)	SP 800-207 — Zero Trust Architecture	Continuous verification is needed when network appearance can be changed cheaply.
Recommendation — Verify every request with stronger context than the source IP.

Practitioner Guidance

What to verify: Check whether your fraud model still links repeated visits when IP, cookie, and session data all change at once. If it does not, your continuity model is probably too dependent on disposable signals and needs stronger device, interaction, and risk-scoring inputs.

Decision rule: If a request looks “new” only because the browser is in private mode or the IP is different, treat that as a weak signal, not a clean bill of health. Escalate when the same device, timing pattern, or behavioral profile keeps reappearing under different network appearances.

Practitioner takeaway: The goal is not to defeat incognito mode or VPNs, it is to make them insufficient on their own by basing trust on continuity that survives routine identifier churn.