What is device fingerprinting?

Device fingerprinting is the practice of building a durable identifier for a device by combining hardware, OS, network, and (on mobile) cryptographically attested signals. It is the technique that lets a service recognize a returning user after they clear cookies, switch browsers, or open a new incognito window, and it is what distinguishes a real iPhone from an Android emulator pretending to be one.

This article is the orientation piece. It defines the term, explains how it differs from the browser-only fingerprinting people usually mean when they say “fingerprint,” and covers what actually persists across the cleanup techniques users and attackers reach for first.

A definition that scales to fraud, not advertising

A device fingerprint is a representation of the device underneath a session, derived from properties that the application can observe directly or that the operating system attests to. The distinction matters: a browser fingerprint identifies one browser instance running on one device. A device fingerprint identifies the device itself, which may host multiple browsers, multiple browser profiles, an incognito session, or a native mobile app.

For fraud and abuse use cases, the goal is to answer one question reliably: have we seen this device before, and under what circumstances? The answer informs:

Was this login attempt from a device the account has used before?
Is this signup the 47th from the same device, all with throwaway emails?
Did this checkout come from a real consumer device or a server emulator?
Did the AI agent that just logged in arrive on the same device the user is on, or somewhere else?

The privacy-focused literature usually treats device fingerprinting as a cross-site tracking technique, which it can be when deployed by an ad network. For a single application using it on its own users, the trade-offs are different: the data stays inside one boundary, the identity exists to protect the user’s own account, and the alternative (forcing CAPTCHA or step-up on everyone) is worse for both privacy and experience.

Device fingerprinting vs. browser fingerprinting

These two terms get used interchangeably and they mean different things in practice.

	Browser fingerprint	Device fingerprint
Scope	One browser instance	The underlying device, across browsers and apps
Inputs	Headers, JS APIs, canvas, WebGL, AudioContext, TLS	All of the above plus OS-attested signals, hardware identifiers, mobile platform tokens
Stability	Drifts with browser updates	Survives browser updates, sometimes survives OS upgrades
What changes it	New browser version, profile reset, switching browsers	Device replacement, factory reset, hardware change
Where it lives	Web only	Web, iOS, Android

In practice a production system collects browser-level fingerprints on web sessions and combines them with platform-attested device identifiers on mobile sessions, then resolves both into one server-side identity for the device.

What actually persists across user “cleanup”

Most fraud operations rely on the assumption that clearing cookies, opening incognito mode, or switching VPNs will give them a clean identity. A properly built device fingerprint does not break under any of those by itself.

Cookies cleared. Cookies are stored data; clearing them removes the stored values. The fingerprint is computed fresh from environment properties on each load. Clearing cookies does not change those properties.

Incognito or private browsing. Incognito stops the browser from storing state across sessions; it does not change what the browser is. The User-Agent, screen resolution, time zone, GPU, font list, and canvas output are identical in incognito because they describe the same browser and the same device. Some browsers (Safari, Brave) restrict a small subset of high-entropy APIs in private mode; the bulk of the fingerprint survives.

Browser switch. Browser-only fingerprints reset because they are tied to one browser. Device-level fingerprints survive because the GPU, the OS-reported hardware properties, the screen geometry, the local network characteristics, and the IP all stay the same.

VPN. A VPN changes the network-layer view of the device: the IP and the IP-implied geography. It does not change the device itself. The user’s claimed time zone, locale, font set, screen geometry, and GPU all stay the same, and the contradiction between those and the new IP is itself a signal.

Factory reset (mobile). The most disruptive cleanup short of replacing the device. It resets stored identifiers, but does not change the hardware model, the screen geometry, the IMEI (where readable), the secure enclave identity, or platform-attested signals that survive across reinstalls.

Device replacement. The only reliable way to defeat device fingerprinting. Operations that need this typically run device farms of dozens or hundreds of physical devices and rotate through them. Detecting this falls back to behavioral and account-level signals rather than the per-session fingerprint.

The landmark 2010 EFF study by Peter Eckersley found 83.6% of browsers were unique on the techniques available at the time (How Unique Is Your Web Browser? PDF). Modern measurements using richer signal sets put unicity above 80% on populations of millions, with per-attribute stability over 90% across observations months apart (Vastel et al., PoPETs 2020). Those numbers hold up under cookie clearing and incognito mode.

The mobile case is different

On the web, every “device fingerprint” is really a heavily-augmented browser fingerprint. On mobile, the platform provides cryptographically signed attestation primitives that are categorically stronger.

Android: Play Integrity API

The Play Integrity API gives developers a server-verifiable token attesting to three things: the app is the genuine version signed by the developer, the device is a genuine Android device running a current OS, and Google Play services are present and unmodified (Google: Play Integrity API overview). The token is signed by Google with a private key the device cannot forge, and the verdict includes whether the device is rooted, in developer mode, or running in an emulator.

This is qualitatively different from a fingerprint. A fingerprint says “this device looks like a genuine Pixel 8.” Play Integrity says “Google’s servers signed a statement that this is, at this moment, a genuine Pixel 8 running an unmodified Android image.”

Play Integrity does not replace fingerprinting. It is point-in-time, has rate limits, and does not by itself link two requests to the same device. It complements fingerprinting by letting you anchor the fingerprint to a known-good device baseline.

iOS: DeviceCheck and App Attest

Apple’s equivalents are two related primitives. DeviceCheck lets an app associate two bits of state with a given device, persistently, in a way the user cannot reset by reinstalling the app (Apple WWDC 2021: Mitigate fraud with App Attest and DeviceCheck). App Attest produces a signed attestation that the app is a genuine, unmodified instance of the developer’s binary running on real Apple hardware.

As with Play Integrity, these are point-in-time signed statements rather than identifiers. The two bits of DeviceCheck state are deliberately tiny: enough to flag “this device has been associated with abuse” without becoming a tracking identifier.

The combination of fingerprinting plus platform attestation is the durable mobile setup. Fingerprinting handles continuity (“is this the same device we saw yesterday?”), while attestation establishes that the device is what it claims to be.

What a device fingerprint is built from, in practice

A web-side device fingerprint pulls from the same five layers as a browser fingerprint: protocol signals like header order and the TLS handshake, the JavaScript environment, active probes like canvas and WebGL, behavioral data, and network infrastructure. Browser fingerprinting techniques covers each of those in depth, and device fingerprinting in JavaScript shows how a typical browser SDK collects them.

A mobile-side device fingerprint adds four layers the web does not have:

OS-reported hardware. Device model, OS version, screen resolution, RAM, available sensors. Native apps read these directly rather than through the browser’s deliberately coarsened APIs.
App environment. Installed app version, install source, package signature.
Platform attestation. Play Integrity verdicts on Android, App Attest assertions on iOS.
Mobile network identity. Carrier identity (where readable), mobile country code, eSIM presence, Wi-Fi BSSID where available.

The exact list varies by SDK, but the architecture is the same everywhere: each signal is one piece of evidence, and the device identity is the server-side resolution of all of them.

What device intelligence means

“Device intelligence” is the marketing umbrella that has replaced “device fingerprinting” in most product positioning. It usually means: device fingerprinting plus the cross-checks and the engineered classifiers that go on top.

A device intelligence platform produces three categories of output.

Identity. A stable identifier for the device, with the property that two sessions from the same device resolve to the same value across cookie clears, incognito mode and (within limits) device migrations.

Classification. A judgment about what the device is. Genuine consumer hardware vs. emulator. Real iOS vs. jailbroken iOS. Real Chrome vs. headless Chrome. Real desktop vs. anti-detect browser. Each classification is itself a signal.

Risk. A scored opinion on the session, derived from identity continuity (is this consistent with the device’s prior history?), classification (does the device look genuine?), and behavioral signals (does this look like a human?).

These three layers map naturally onto how application code uses the data. Identity is the join key in your fraud datastore, classification is what you log for audit, and risk is what you act on at the API boundary.

Privacy posture worth being honest about

Device fingerprinting deserves the scepticism it gets in the privacy literature. The same technique that lets a single app protect its own users can also be misused by ad networks to follow users across the web, and the user has limited tools to prevent it.

The principled posture is to use fingerprinting only for first-party fraud and abuse, to keep the data inside the application boundary, to log the inputs so decisions are auditable, to refuse to share the identifier with third parties, and to write a privacy policy that says so plainly. Foil’s own privacy policy and DPA are written along those lines.

What to do next

If you want the deep technical walkthrough on the web side: device fingerprinting in JavaScript and browser fingerprinting techniques.

If you are evaluating device intelligence for a specific use case, the abuse-focused articles are the right next stop: account takeover prevention, fake account prevention, promo abuse prevention.