Device intelligence shows fraud risk concentrates on desktop sessions

At a glance

What this is: Fingerprint's 2026 Device Intelligence Report says normal traffic has shifted, with VPN usage now routine, desktop sessions concentrating the most fraud signals, and mobile signals remaining rarer but more meaningful.

Why it matters: Fraud, identity verification, and account security teams need to recalibrate risk models so they do not overreact to common privacy behaviour while still catching stacked indicators that point to abuse.

By the numbers:

• The report analysed more than 23 billion identification events across over 7 billion browsers and devices worldwide.
• In 2025, roughly 1 in 5 identification events involved VPN usage, up from about 1 in 6 the year before.
• Fingerprint says 4.4% of desktop browser identifications showed tampering in 2025, up from 2.6% in 2024.
• Rooted Android devices accounted for 0.12% of mobile identifications in 2025, while jailbroken iOS devices accounted for 0.03%.

👉 Read Fingerprint's 2026 Device Intelligence Report for the full traffic baseline

Context

Fraud detection fails when teams treat every unusual signal as suspicious and every common signal as noise. Device intelligence only works when it reflects how people actually behave at signups, logins, checkouts, and account recovery, rather than how rule sets imagine they should behave. For identity verification and fraud teams, the challenge is separating baseline privacy behaviour from indicators that genuinely change risk.

The article sits in the overlap between identity verification, trust and safety, and account security. It also has a governance angle for IAM and NHI teams because automated traffic, including AI agents and scripted workflows, increasingly resembles legitimate user behaviour unless controls look at the full session context. That makes the boundary between human activity, machine-driven activity, and abuse materially harder to govern.

Key questions

Q: How should security teams handle VPN users without blocking legitimate access?

A: Security teams should use VPN detection as a contextual risk signal, not as an automatic deny rule. Combine it with device reputation, geolocation consistency, and confidence scoring, then route uncertain sessions to step-up review. That approach preserves privacy for legitimate users while still giving compliance teams a defensible basis for enforcement.

Q: Why do desktop sessions produce more fraud signal noise than mobile sessions?

A: Desktop browsers allow more modification, virtualization, and automation tooling, so they generate more ambiguous signals. Mobile environments are more constrained, which lowers the volume of suspicious-looking behaviour. The result is that desktop often needs contextual scoring, while mobile can make rare integrity events more decisive because the baseline is cleaner.

Q: What do security teams get wrong about browser tampering and device signals?

A: They often treat each signal as a verdict instead of part of a pattern. Browser tampering, developer tools, VMs, and VPNs can all be legitimate in isolation. The mistake is failing to separate normal power-user behaviour from coordinated abuse by looking at combinations, timing, and consistency across the whole session.

Q: How should teams decide when to challenge or block an identification event?

A: Use channel-specific thresholds and response logic. On desktop, require multiple correlated signals before hard action. On mobile, even a small number of high-confidence integrity indicators may justify stronger controls. The decision should reflect expected user behaviour, business tolerance for friction, and the quality of evidence available at that point in the journey.

Technical breakdown

Why browser fingerprinting works best as a signal stack

Browser fingerprinting is not a single test. It combines browser characteristics, device traits, and runtime cues into a confidence model that can distinguish normal traffic from abuse patterns. The report shows why context matters: VPN use, developer tools, virtual machines, and tampering can each be legitimate on their own. The technical value comes from correlation, not from any one signal. That is why stronger fraud programs score events rather than block on first sight, especially in desktop environments where signal noise is higher and automation can hide behind normal user tooling.

Practical implication: treat fingerprinting as a scoring layer and require multiple correlated signals before taking strong action.

Why desktop fraud looks different from mobile integrity

Desktop browsers give attackers more room to modify execution paths, hide automation, and obscure browser identity. That makes desktop the primary battleground for tampering and bot abuse. Mobile environments are more constrained, so modification is harder and fewer signals appear overall. But the signals that do surface on mobile, such as rooted devices, emulators, app cloning, or man-in-the-middle characteristics, tend to be more decisive because the baseline is cleaner. That changes how risk teams should weight evidence across channels and why the same indicator can mean different things on desktop and mobile.

Practical implication: assign different thresholds and response logic for desktop and mobile rather than reusing one scoring model.

How AI agents and automation complicate identity verification

The report's most important governance point is that automated activity is no longer easy to classify from browser behaviour alone. AI agents, QA tooling, and abusive scripts can all produce sessions that look similar at the fingerprint layer, especially when they run in VMs or expose developer tools. That creates a classification problem for IAM and fraud teams: the question is not just whether the session is unusual, but whether the unusualness is expected, authorised, and bounded. This is where identity governance intersects with trust and safety, because automation needs lifecycle controls, not just detection rules.

Practical implication: inventory approved automation and tie it to explicit identity, device, and policy boundaries.

Threat narrative

Attacker objective: The objective is to reach high-value workflows while avoiding detection by making abusive sessions resemble normal user or automation traffic.

1. Entry occurs when attackers or scripted abuse routes traffic through desktops, VPNs, VMs, or modified browsers to blend into ordinary session patterns.
2. Escalation happens when tampering, automation, and developer tooling stack together, making the session harder for weak fingerprinting controls to classify.
3. Impact is fraudulent account creation, account takeover, or policy evasion that reaches protected workflows while appearing operationally plausible.

NHI Mgmt Group analysis

Desktop-heavy fraud is now a signal stacking problem, not a single-indicator problem. The report shows that the highest-risk activity clusters on desktop because desktop environments tolerate more modification, virtualization, and automation tooling. That means teams should stop asking whether a signal is suspicious in isolation and start asking whether several low-to-medium signals align into a coherent abuse pattern. The governance lesson is straightforward: risk scoring must reflect context density, not checkbox detection.

VPN normalisation creates a verification trust gap. Once a common privacy control becomes baseline behaviour, it loses much of its value as a fraud discriminator. That does not make VPN traffic safe, but it does mean identity and fraud teams need to reweight it against stronger evidence such as device integrity, velocity, and session consistency. The practical conclusion is that verification policy must be calibrated to expected user behaviour, not to outdated anomaly assumptions.

AI agents widen the boundary between legitimate automation and abuse. A browser session created by a bot, a QA job, or an AI agent can look similar at the telemetry layer, which creates governance debt for teams that still depend on simple bot versus human distinctions. This is where identity and access control matter: approved automation needs explicit lifecycle ownership, scope, and revocation paths. Practitioners should govern automation as a managed identity class, not a special case.

Mobile integrity signals are small in volume but high in decision value. The report reinforces a useful pattern for fraud programs: a rare mobile compromise indicator often deserves more weight than a common desktop privacy signal. That is because the technical constraints of mobile reduce the ambient noise. Teams should therefore align challenge logic to channel-specific evidence quality, or they will either over-friction legitimate desktop users or underreact to high-confidence mobile compromise.

What this signals

Device intelligence is becoming a governance problem as much as a fraud problem. Teams that rely on one signal to separate normal from abusive traffic will keep misclassifying privacy behaviour, especially as VPN use becomes routine and automation grows more human-like. The practical shift is toward evidence stacking, channel-specific thresholds, and cleaner ownership of approved bots and AI-driven workflows.

Signal density, not signal rarity, is the new decision model. The report shows that desktop sessions accumulate more ambiguous signals, while mobile sessions produce fewer but stronger ones. That means fraud programmes should stop copying the same response logic across channels and start aligning challenge intensity to the quality of evidence available at the point of decision.

For identity programmes that now support AI agents or other non-human workflows, the lesson is that machine-driven traffic needs explicit governance boundaries. The more legitimate automation resembles abuse at the telemetry layer, the more important lifecycle ownership, allowlisting, and revocation become. That is where identity control and trust-and-safety control begin to overlap.

For practitioners

• Recalibrate VPN treatment in decisioning rules Remove VPN presence as a standalone suspicion trigger in most flows, then use it as context alongside device integrity, velocity, and account history. Preserve stricter handling only where geo-compliance or location enforcement is a real requirement.
• Build separate scoring for desktop and mobile sessions Use different thresholds, evidence weights, and response paths for desktop and mobile because their baseline noise profiles are not comparable. Desktop should require stacked signals before hard blocks, while rare mobile integrity signals can justify faster intervention.
• Inventory approved automation and AI agent traffic Create explicit allowlists for QA jobs, internal bots, and AI-driven workflows, then bind them to named owners, scoped permissions, and revocation procedures. That reduces confusion when sessions show VM, developer tool, or browser tampering traits.
• Tune fraud responses to signal combinations, not single anomalies Define escalation rules for patterns such as tampering plus virtualisation, or emulator plus account creation, instead of relying on one indicator. This is the fastest way to separate ordinary privacy behaviour from genuinely abusive sessions.

Key takeaways

• VPNs are now ordinary enough that they should rarely be treated as fraud evidence on their own.
• Desktop remains the highest-value environment for fraud detection because risky behaviour clusters there and requires signal stacking.
• Fraud teams need separate playbooks for desktop, mobile, and approved automation or they will keep misclassifying normal traffic.

Key terms

• Device Intelligence: Device intelligence is the practice of interpreting signals from a device to assess whether a session or transaction is likely legitimate. It goes beyond fingerprinting by combining device context with behavioural, identity, and payment evidence to support a risk decision.
• Browser Fingerprinting: Browser fingerprinting is the process of identifying a browser or device by combining many attributes that are difficult to spoof all at once. It is most useful as a probabilistic signal, not a unique identifier, because legitimate users can share similar traits and privacy tools can change the output.
• Signal Stacking: Signal stacking is the practice of combining multiple weak or moderate indicators into one stronger decision. In fraud and trust-and-safety programmes, it reduces false positives by requiring context across device, network, and session behaviour before escalating a case.
• Integrity Signal: An integrity signal is evidence that a device, app, or session may have been modified, intercepted, or automated. Common examples include tampering, rooting, emulation, and man-in-the-middle characteristics. These signals are valuable because they often change the confidence level of a transaction more than a privacy signal does.

What's in the full report

Fingerprint's full report covers the operational detail this post intentionally leaves for the source:

• Region, platform, and browser-runtime breakdowns that help teams tune fraud thresholds by environment
• Detailed segment analysis of browser tampering, virtual machine usage, and developer-tool patterns across desktop traffic
• Mobile integrity signal breakdowns, including rooted Android, jailbroken iOS, app cloning, and man-in-the-middle detection
• Benchmark data on suspect-score distributions that can support internal risk calibration and policy tuning

👉 Fingerprint's full report adds the regional, platform, and runtime breakdowns behind these fraud signals

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a practical base for governing automation and access at scale.