TL;DR: what is device intelligence
- Browser, device, and network signals combined into a stable device ID that survives cookie clears and private windows.
- The inputs: browser fingerprint, TLS fingerprint, behavioral cadence, IP and ASN, prior history. 102+ signals collected, 40+ of them hashed into one persistent identifier.
- Where it earns its keep: account-takeover prevention, chargeback evidence, VAMP compliance, Visa CE 3.0 disputes.
Why the old approaches stopped working
Web applications were designed to identify users, not devices. The identifiers they relied on were all user-controllable, and fraud evolved to exploit that.
Third-party cookies were the first to fall. Safari began blocking them in 2020, and privacy-conscious users had been deleting first-party cookies long before that. Incognito mode creates a fresh cookie jar on every session. Any method that depends on a cookie persisting across visits breaks the moment the user clears their browser or opens a private window.
IP addresses looked like a hardware-level signal, but residential proxy networks undermined that assumption. A proxy service can rotate the originating IP address on every single request, making one device look like a different visitor each time. VPNs change the IP whenever the user connects. And shared IP addresses, used by office networks and university campuses, mean a single address might represent hundreds of people.
Session tokens solve a different problem. They track the authenticated state of a session, not the identity of the device. The moment the browser tab closes, the session ends. Session tokens are useful within a visit, but they cannot link a returning user across separate visits.
First-party cookies are more persistent than third-party ones, but they face the same fundamental issue. A user who clears their cookies, or a browser set to clear cookies on close, resets any identifier you stored. Privacy-conscious users, who overlap heavily with fraud investigators and fraudsters, do this routinely.
The pattern across all of these is the same. Each approach depended on data stored on the user's device, which meant the user controlled whether it persisted.
How device intelligence works
Device intelligence reads passive signals from the device's hardware and software environment instead of storing an identifier on the device. Those signals cannot be deleted by the user because they were never written to the browser in the first place. They are characteristics of the device itself.
The browser exposes hundreds of these signals through standard JavaScript APIs. The most meaningful ones are below.
Canvas fingerprint. When the browser renders a hidden canvas element with a specified drawing operation, the pixel output differs subtly between devices based on the GPU, the graphics driver, and the anti-aliasing implementation. Two devices with identical specifications but different driver versions produce measurably different canvas outputs. This signal is stable across browser restarts, incognito mode, and cookie clearing because it reflects hardware behavior, not stored data.
Font rendering. Each operating system and graphics stack renders installed fonts differently at the sub-pixel level. The specific set of installed fonts and how they render produces a highly distinctive signal.
WebGL fingerprint. WebGL workloads expose the behavior of the graphics card in detail. A device's WebGL fingerprint reflects the GPU model, driver version, and rendering pipeline, all of which are stable over time.
TLS handshake fingerprint TLS fingerprinting. When a browser opens a TLS connection, the negotiation handshake exposes the supported cipher suites, extensions, and their ordering. That pattern is characteristic of the software stack making the connection. A VPN client, a proxy service, or a headless browser each produces a distinct TLS handshake signature. TLS handshake fingerprint fingerprinting reads this at the network layer to identify whether a connection is coming through a VPN or proxy.
Timing patterns. The time taken for specific browser operations reflects CPU characteristics and load. Headless browser environments, which underpin automated attack tools, produce timing signatures that differ from real sessions driven by human interaction.
Screen metrics, audio context, and other environment signals. Resolution, pixel density, touch support, available audio hardware, timezone, and language settings each add signal. No single attribute is conclusive. The combination of many stable attributes is what produces a reliable identifier.
These signals are combined through a hashing algorithm to produce a device ID. The same device produces the same ID whether the user is in incognito mode, connected through a VPN, or has cleared every cookie in their browser, because none of those actions change the underlying hardware or software configuration the fingerprint reads.
What makes an implementation reliable
Not all device intelligence implementations are equally accurate. Three practical criteria are worth evaluating.
Signal breadth. An implementation that reads 10 or 20 signals produces a less stable ID than one that reads 100 or more. The more signals in the hash, the better the implementation tolerates minor changes, such as a browser update that alters one rendering attribute, without producing a false new-device reading.
Cross-incognito accuracy. A weak implementation breaks in incognito because it relies partly on stored identifiers, such as localStorage or IndexedDB values, that incognito mode resets. A strong implementation reads only passive environmental signals and therefore produces the same ID in incognito as in a standard session.
VPN stability. A device ID should not change when a user activates a VPN, because a VPN only changes the IP address. None of the browser signals described above reflect the IP. If an implementation's device ID changes when the user connects to a VPN, it is folding IP or network-layer data into the fingerprint hash, which undermines its usefulness for exactly the scenarios where VPNs are relevant.
Where device intelligence is applied
Account takeover prevention. Account takeover fraud reached $13.5 billion in losses in 2025, affecting 6 million people in the US, according to Javelin Strategy & Research. The most common attack begins with stolen credentials from a previous breach. Device intelligence identifies when a known account attempts a login from a device that has never been associated with that account, and triggers a challenge or block before access is granted. See how this plays out in account takeover prevention.
New account fraud. When one device creates dozens of accounts in quick succession, the attacker usually resets their email address and IP between each attempt. The device itself stays constant. Device intelligence exposes this pattern immediately, which is the core of signup fraud prevention.
Account sharing. For subscription businesses, device intelligence maps which device IDs authenticate against a given account over time. An account logging in from 12 distinct device IDs in a month is straightforward to flag for account sharing enforcement.
Chargeback evidence. A stable device ID recorded at checkout becomes part of the evidence packet when a transaction is disputed. The device's presence in the session is a documented fact rather than a reconstructed inference, which strengthens chargeback evidence.
How cside detects devices
cside reads more than 100 browser signals per session to generate a device identifier that stays stable across incognito mode, VPN connections, and cookie clearing. Beyond the device ID itself, each API response returns additional signals from the same script tag: it flags AI-agent and automated sessions, identifying named agents and frameworks such as OpenAI Operator, Claude for Chrome, Playwright, Puppeteer, and Selenium; it returns a VPN/proxy signal derived from TLS handshake fingerprint TLS fingerprinting; and it flags incognito sessions.
The full details of how cside implements device intelligence, including integration steps and example API responses, are on the device fingerprinting page.
Privacy and GDPR considerations
Device intelligence is sometimes conflated with invasive tracking, but the two are meaningfully different. A few points are worth understanding clearly.
Device intelligence does not require cookies and does not store any data on the user's device. The signals it reads are passive environmental characteristics, not data written into the browser.
The output is a pseudonymous identifier, not a directly identifying one. A device fingerprint ID does not reveal a name, email address, or physical location. It identifies a device configuration, which can be linked to a person only if separate account data provides that link.
Fingerprinting for fraud prevention is commonly processed under legitimate interest as the lawful basis under GDPR, because the processing is necessary to protect users and the business from fraudulent activity. Legal requirements vary by jurisdiction and use case, and any organization implementing device intelligence should obtain specific legal advice.
Operators must disclose the use of device fingerprinting in their privacy policy, describing the categories of data processed and the purpose.
Further reading
