Device Fingerprinting
On this page
Before implementing device fingerprinting, ensure you understand:
- Risk scoring concepts (fingerprinting feeds into scores)
- Velocity rules (fingerprinting enables device-based velocity)
- Privacy compliance requirements (GDPR, CCPA)
- Account takeover patterns you're trying to detect
- Device fingerprinting has evolved into device intelligence: hundreds of signals across hardware, browser, network, behavior, and sensor data
- Modern platforms can detect VPNs, emulators, phone farms, remote desktop tools, and anti-detect browsers
- Signals like battery state, gyroscope data, TLS fingerprints, and typing cadence reveal things transaction data alone cannot
- Vendors range from consortium-scale networks (ThreatMetrix, Iovation) to deep behavioral analytics (Sardine) to fully managed decisions (Forter)
- No single signal is definitive. The power comes from cross-layer correlation: transport + device + browser + behavior
Device fingerprinting started as a way to assign a unique ID to a browser. Modern device intelligence goes far deeper, collecting hundreds of signals across hardware, software, network, and behavior to answer questions like: Is this a real device? Is a real person using it? Have we seen this device before? Is someone controlling it remotely?
This page covers what signals exist, what they reveal, and which vendors offer what. For how to use device signals in fraud rules, see Building Fraud Rules.
How It Works
Fingerprint Types
| Type | How It Works | Persistence | Evasion Difficulty |
|---|---|---|---|
| Cookie-based | Stores a token in the browser | Low (cleared easily) | Trivial |
| Browser fingerprint | Hashes browser attributes (user agent, plugins, fonts) | Medium (changes with updates) | Moderate |
| Device fingerprint | Combines hardware signals (GPU, CPU, screen, sensors) | High (survives browser changes) | Hard |
| Probabilistic/fuzzy | Uses ML to match devices even when some attributes change | High (survives cookie clearing, incognito) | Very hard |
| Behavioral | Learns how a specific person uses a device (typing, movement) | Medium-High (builds over sessions) | Very hard to replicate |
Modern vendors combine multiple types. A good device intelligence platform doesn't rely on any single fingerprint. It cross-references all layers so that spoofing one signal creates inconsistencies in others.
Signal Categories
Device intelligence platforms collect signals across seven categories. No single category is decisive on its own. Fraud detection comes from inconsistencies between categories.
1. Browser and App Signals
The traditional fingerprinting layer. Still useful, but easily spoofed in isolation.
| Signal | What It Reveals | Fraud Relevance |
|---|---|---|
| Canvas fingerprint | Hash of rendered 2D graphics (varies by GPU, driver, OS) | Matches known emulator/headless signatures |
| WebGL fingerprint | GPU vendor and renderer string, 3D rendering output | Google SwiftShader = software GPU (headless/emulator). VirtualBox Graphics Adapter = VM |
| Audio fingerprint | Audio processing output unique to hardware/OS stack | Absent in headless browsers, identical across emulator instances |
| Font enumeration | Installed font list | Windows device claiming Linux fonts = spoofed user agent |
| Navigator properties | Plugins, languages, hardware concurrency, device memory | navigator.webdriver === true = automation (Selenium, Puppeteer) |
| User agent | Browser and OS identification | Easily spoofed, but inconsistencies with other signals are revealing |
Tools like Multilogin, GoLogin, and Dolphin Anty spoof all of these signals to make each browser profile look unique. They're widely used in fraud operations. Modern device intelligence platforms detect anti-detect browsers by looking for inconsistencies between spoofed browser attributes and harder-to-fake signals like TLS fingerprints, sensor data, and behavioral patterns.
For server-side IP lookups via API (geolocation, VPN detection, datacenter detection) with no SDK required, see Data Enrichment. This section covers deeper network signals that require a client-side SDK - WebRTC leak detection, TLS fingerprinting, and residential proxy detection via device correlation.
2. True IP and Network Intelligence
IP addresses are the most spoofed signal in fraud. Modern platforms go beyond the visible IP to find the real one.
| Technique | How It Works | What It Catches |
|---|---|---|
| WebRTC leak detection | Creates a hidden peer connection via STUN servers. UDP traffic can bypass VPN tunnels, revealing the real IP | VPN users whose real IP leaks through WebRTC |
| TLS fingerprinting (JA3/JA4) | Hashes the TLS ClientHello message (cipher suites, extensions). Each TLS client has a unique signature | User agent says "Chrome" but TLS fingerprint matches Python requests library = bot |
| ASN/datacenter detection | Maps IP to owning organization. Classifies as residential, mobile, datacenter, or hosting | Datacenter IPs are 20-50x more likely to be fraud than residential |
| Residential proxy detection | Correlates IP rotation patterns with stable device fingerprints | IP changes every request but device fingerprint stays constant = rotating residential proxy |
| Timezone vs. IP mismatch | Compares browser timezone (Intl.DateTimeFormat) with IP geolocation | IP in London, timezone set to America/Los_Angeles = VPN user who forgot to change timezone |
Several vendors offer "True IP" technology that attempts to reveal the actual IP behind VPNs and proxies. ThreatMetrix pioneered this approach with their TrueIP feature, and Sardine offers similar "True Piercing" technology (TrueIP, TrueOS, TrueLocation). The accuracy varies by technique and how the VPN is configured.
IP classification matters as much as the IP itself:
| IP Type | Example Owner | Risk Level |
|---|---|---|
| Residential | Comcast, AT&T, BT | Low (expected for consumers) |
| Mobile/Cellular | T-Mobile, Vodafone | Low (expected for mobile) |
| Datacenter/Hosting | AWS, DigitalOcean, OVH | High (real consumers don't browse from datacenters) |
| Known VPN provider | NordVPN, ExpressVPN ranges | Medium-High |
| Known proxy service | Bright Data, Oxylabs | High |
| Tor exit node | Published exit node lists | Very High |
3. Device Integrity
These signals detect whether the device itself has been tampered with, emulated, or is being controlled remotely.
| Signal | Normal Device | Fraud Indicator |
|---|---|---|
| Emulator detection | Real hardware identifiers (e.g., samsung/...) | Generic build strings (goldfish, ranchu, sdk_gphone), SwiftShader GPU, missing sensors |
| Root/jailbreak | Stock OS, normal permissions | Presence of su binary, Cydia/Magisk, SELinux permissive, writable system partition |
| Remote desktop | No remote access software active | TeamViewer, AnyDesk, Windows RDP, Zoom screen sharing detected |
| VM detection | Real GPU, normal CPU | VirtualBox/VMware graphics adapters, low CPU core count, VM-specific BIOS strings |
| Developer tools | navigator.webdriver is false | navigator.webdriver === true, empty plugins array, CDP connection active |
| Frida/instrumentation | No runtime hooks | Frida toolkit detected (commonly used to bypass security checks and manipulate API responses) |
Remote access scams are growing. A fraudster calls a victim, convinces them to install TeamViewer, then controls their device to make transactions. The transaction comes from the victim's real device and real IP, so traditional signals look clean. Detecting active remote desktop software is one of the few ways to catch this pattern.
4. Behavioral Biometrics
How someone uses a device is extremely difficult to fake at scale. This is where the newest and most powerful signals come from.
Typing and keystroke dynamics:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Typing speed | Characters per second, words per minute | Perfectly uniform timing = bot/automation |
| Dwell time | How long each key is held | Zero variance = programmatic key injection |
| Flight time | Gap between releasing one key and pressing the next | Identical intervals = scripted input |
| Segmented typing | Typing in bursts with pauses (switching to reference material) | Typing name/address in fragments while looking at a stolen data sheet |
| Copy-paste in identity fields | Whether name, SSN, or address was pasted vs. typed | Legitimate users type their own name from memory. Pasting it is a strong fraud signal |
Mouse and pointer behavior:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Movement trajectories | Cursor path between targets | Perfectly straight lines = simplest bot. Geometric patterns = scripted |
| Micro-movements | Tiny jitter when cursor is "still" | Zero jitter = bot. Humans always have hand tremor |
| Click patterns | Timing, location, frequency | Uniform click intervals = automation |
| Scroll behavior | Speed, direction, pauses | Uniform scroll with no pauses = bot |
| Guided movement | Cursor controlled by someone else (latency artifacts) | Remote access tool in use |
Mobile sensor data:
| Signal | What It Measures | What Fraud Looks Like |
|---|---|---|
| Gyroscope | Device orientation and rotation | Zero readings = emulator (no physical sensors) or phone farm device sitting on a rack |
| Accelerometer | Movement and vibration | Perfectly static = not being held by a human |
| Touch pressure | Force of finger on screen | Uniform pressure = automation. No pressure data = emulator |
| Device orientation | How the phone is held | Static at ~90 degrees = propped up on a rack, not in someone's hand |
5. Battery and Power Signals
A small but revealing signal category. Available through the Battery Status API (web) and native mobile SDKs.
| Signal | Normal User | Fraud Indicator |
|---|---|---|
| Always at 100%, always charging | Battery fluctuates throughout the day | Phone farm: devices permanently plugged into USB hubs |
| Battery level never changes across sessions | Varies naturally | Emulator (many report a static level like 0.50 or 1.00) |
| Inconsistent battery between "same user" sessions | Consistent within short timeframes | Account sharing or credential selling |
Battery data alone is a weak signal. Its value is corroborative: a device that's always charging AND has zero gyroscope movement AND has been seen on 50 accounts is almost certainly a phone farm device.
6. Phone Farm and Fraud Factory Detection
Phone farms are physical or virtual collections of devices operated at scale to simulate independent users. No single signal catches them. The detection comes from a composite profile.
| Signal | What a Farm Device Looks Like |
|---|---|
| Battery | Always at 100%, always charging (plugged into USB hubs) |
| Gyroscope/accelerometer | Zero movement (mounted on rack, not held by a human) |
| Device attributes | Same hardware fingerprint appearing across many "different" accounts |
| Factory resets | Frequent resets (every few hours/days) to create "fresh" identities |
| Device ID cycling | IMEI, Android ID, or advertising ID changes on the same hardware |
| Network patterns | Many devices sharing the same IP range or cycling through a small pool |
| Behavioral uniformity | All devices show identical interaction patterns, timing, and session flow |
| No natural idle periods | Legitimate users sleep. Farm devices may operate 24/7 |
| Physical proximity | Dozens of "independent" devices co-located in the same physical space |
7. Consortium and Reputation Data
The most powerful device intelligence signal is often the simplest: has this device been seen committing fraud before?
Consortium networks pool device reputation data across thousands of merchants. When a device is flagged as fraudulent at one merchant, every other merchant in the network sees that signal in real time.
| What Consortium Data Tells You | Example |
|---|---|
| Device has been involved in fraud before | Device flagged for chargebacks at 3 other merchants in the past 90 days |
| Device is brand new to the network | Never seen before, no history (higher risk for new accounts) |
| Device has long trusted history | First seen 2 years ago, clean history across 12 merchants (strong trust signal) |
| Device is linked to known fraud rings | Same device cluster seen in coordinated attacks across the network |
How Signals Work Together
No single signal is definitive. The power of device intelligence comes from layering and cross-referencing signals across categories. Inconsistencies between layers are the strongest indicators.
Example: Catching an anti-detect browser
An anti-detect browser can spoof canvas fingerprint, WebGL renderer, user agent, timezone, and language. But:
- The TLS fingerprint (JA3/JA4) still matches the underlying Chromium build, not the spoofed user agent
- The battery API reports a static level (emulated environment)
- Typing patterns don't match the account's historical behavior
- The IP is residential, but the ASN belongs to a known residential proxy provider
Any one of these signals alone might be explainable. All four together are not.
Example: Detecting a remote access scam
The transaction comes from the victim's real device, real IP, real location. Traditional signals look clean. But:
- Remote desktop software (TeamViewer) is active
- Mouse movements show latency artifacts consistent with remote control
- The user is on an active phone call during the session
- Typing patterns show hesitation and segmented entry (victim being coached)
Vendor Landscape
Device intelligence vendors vary significantly in what signals they collect, how large their consortium networks are, and how they deliver decisions. The table below compares vendors on capabilities, not marketing claims.
Comparison by Capability
| Capability | Sardine | ThreatMetrix | Iovation | Kount | Sift | Forter |
|---|---|---|---|---|---|---|
| Behavioral biometrics | Deep (typing, mouse, sensors, copy-paste, active calls) | Yes (BehavioSec integration) | Limited | Limited | Basic | Yes (6,000 attributes) |
| True IP / proxy piercing | Yes (True Piercing) | Yes (TrueIP, pioneer) | Basic proxy detection | Basic proxy flag | Basic | Yes |
| Emulator detection | Yes + TrueOS | Yes | Yes | Yes (PC_REMOTE flag) | Yes | Yes |
| Remote desktop detection | Yes (92% precision, protocol-agnostic) | Limited | Limited | PC_REMOTE flag | Limited | Limited |
| Phone farm detection | Yes (sensor + behavioral composite) | Via consortium | Via device reputation | Via velocity | Via velocity | Via identity graph |
| TLS fingerprinting | Yes | Yes | Limited | Limited | Limited | Yes |
| Anti-detect browser detection | Yes | Yes | Limited | Limited | Limited | Yes |
| Consortium network scale | Growing | 1.4B identities, 110M daily decisions | 5B devices, 185M fraud reports | 17.5B devices (Equifax network) | 1T+ events/year | 1.2B identities |
| Custom rule engine | Yes (4,000+ features) | Yes (60+ assertions) | Yes (business rules) | Yes (policies + UDFs) | Yes (Workflows) | No (fully managed) |
| Credit bureau data | No | No | No | Yes (Equifax) | No | No |
| Chargeback guarantee | No | No | No | No | No | Yes |
Choosing a Vendor
The right vendor depends on your biggest problem, not the longest feature list.
| If Your Primary Problem Is... | Look At |
|---|---|
| Sophisticated fraud bypassing basic rules (anti-detect browsers, residential proxies, emulators) | Sardine, ThreatMetrix - deepest signal collection and cross-layer correlation |
| Needing device reputation at scale (has this device been seen in fraud before?) | ThreatMetrix (1.4B identities), Iovation (6B+ devices) - largest consortium networks |
| Remote access / social engineering scams | Sardine - only vendor with protocol-agnostic remote desktop detection at reported 92% precision |
| Identity verification + device signals (synthetic identity, application fraud) | Kount/Equifax - unique credit bureau integration alongside device fingerprinting |
| Multi-abuse-type detection (payment fraud + promo abuse + content abuse + ATO) | Sift - independent scores for 5 abuse types, ThreatClusters for industry-specific models |
| Not wanting to manage rules at all (fully outsourced decisions with financial guarantee) | Forter - managed decisions with 100% chargeback guarantee on approved transactions |
| Budget-conscious / just getting started | Fingerprint Pro (device ID focused, lower cost), or your processor's built-in tools (Stripe Radar, Adyen RevenueProtect) |
Pricing and Accessibility
| Vendor | Entry Price | Free Tier? | Self-Serve? | Primary Use Case |
|---|---|---|---|---|
| Fingerprint | From $99/month (100K identifications) | Yes - 20,000 identifications/month | Yes | Device identification, returning visitor recognition |
| SEON | From $599/month (5K+ API calls) | Yes - 100 API calls/month | Yes | Social profiling + email/phone enrichment + device signals |
| ThreatMetrix (LexisNexis) | Enterprise quotes only | No | No | Large enterprise device intelligence, consortium reputation |
| BioCatch | Enterprise quotes only | No | No | Behavioral biometrics for banks, social engineering detection |
| NeuroID | Enterprise quotes only | No | No | Form interaction analytics, application fraud detection |
| Iovation (TransUnion) | Enterprise quotes only | No | No | Device reputation + credit bureau integration |
| Sardine | Enterprise quotes only | No | No | Deep behavioral biometrics, True IP piercing, remote desktop detection |
Budget-conscious? Fingerprint is the only device fingerprinting vendor with a meaningful free tier and self-serve onboarding. At $99/month for 100K identifications, it's accessible to most SMBs. SEON bundles device signals with email/phone enrichment starting at $599/month but is really a lightweight fraud platform, not a pure device fingerprinting tool.
Enterprise? ThreatMetrix, BioCatch, Iovation, and Sardine require sales conversations and annual contracts. If you're under $2M in annual volume, these vendors likely aren't a fit - start with Fingerprint or your processor's built-in tools (Stripe Radar, Adyen RevenueProtect).
If you use Stripe Radar or Adyen RevenueProtect, you already have basic device fingerprinting, IP intelligence, and ML scoring included. Standalone device intelligence vendors add deeper signals (behavioral biometrics, sensor data, True IP, consortium reputation) that processor tools don't collect. Whether you need a standalone vendor depends on your fraud sophistication and volume. See Processor Rules Configuration for what's included with each processor.
Use Cases
Fraud Detection
| Use Case | How Device Intelligence Helps |
|---|---|
| Card testing | Same device cycling through hundreds of card numbers = single fraud source |
| Multi-accounting / promo abuse | Same device fingerprint across multiple "different" accounts |
| Account takeover | New device + new location + new behavioral pattern on existing account |
| Fraud ring linkage | Cluster of devices with shared attributes, same IP ranges, same behavioral patterns |
| Application fraud | Emulator detected, copy-paste in identity fields, no sensor data |
| Remote access scams | Active remote desktop software, mouse latency artifacts, active phone call |
Account Security and Trust
| Use Case | How Device Intelligence Helps |
|---|---|
| Step-up authentication | Trigger MFA on unknown device (see 3DS) |
| Trusted device recognition | Returning device with clean history = lower friction |
| Session management | Limit active devices per account |
| Compelling evidence | Device fingerprint matching for Visa CE 3.0 chargeback representment |
Implementation Approaches
Build vs. Buy
| Approach | What You Get | What You Don't Get |
|---|---|---|
| In-house (FingerprintJS open source) | Basic device fingerprinting, full control, no data sharing | No consortium data, no behavioral biometrics, no True IP |
| Device ID vendor (Fingerprint Pro) | Stable device IDs, basic bot detection, good accuracy | Limited behavioral signals, smaller consortium |
| Full platform (Sardine, ThreatMetrix, Sift, etc.) | Deep signals, behavioral biometrics, consortium, rules engine | Higher cost, data sharing requirements, vendor dependency |
| Processor-included (Stripe Radar, Adyen) | Basic fingerprinting + ML scoring included in processing fees | Black-box scoring, limited device signal visibility, no cross-merchant reputation |
See vendor selection guide for evaluation criteria.
What to Ask a Vendor
When evaluating device intelligence vendors, ask:
- What signals do you collect beyond basic fingerprinting? (Behavioral biometrics, sensor data, TLS fingerprints)
- How do you handle anti-detect browsers and residential proxies? (Cross-layer correlation, not just database lookups)
- How large is your consortium network, and is it relevant to my vertical? (A billion devices is useless if none are in your industry)
- Can I write custom rules against your signals, or are decisions fully managed?
- What's the latency? (Sub-100ms is the standard for real-time decisioning)
- How do you handle privacy compliance? (Data tokenization, consent management, GDPR readiness)
Privacy Considerations
Device fingerprinting may be subject to:
- GDPR (consent requirements, legitimate interest basis)
- CCPA (disclosure requirements)
- ePrivacy Directive
- Local regulations
Consult legal before implementation. See compliance overview for related requirements.
Best Practices
- Transparency - Disclose device fingerprinting in your privacy policy
- Purpose limitation - Use only for fraud prevention and security
- Data minimization - Collect only what's needed for fraud detection
- Retention limits - Set expiration on device profiles (consortium data may have its own retention)
- Consent where required - Cookie banners, opt-in where legally necessary
- Vendor data sharing - Understand what data your vendor shares across its consortium and under what terms
Next Steps
Just getting started?
- Use your processor's built-in device fingerprinting first (Stripe Radar, Adyen RevenueProtect)
- Build velocity rules using device ID as a dimension
- Review privacy requirements before adding standalone tools
Adding standalone device intelligence?
- Choose a vendor based on your primary fraud problem
- Integrate and run in shadow mode alongside your existing tools for 30 days
- Compare the new signals against your current fraud catches and false positives
Already have device intelligence?
- Use device signals in fraud rules
- Build behavioral patterns into your review process
- Prepare device data for CE 3.0 chargeback representment
Related Topics
- Data Enrichment - Server-side IP, email, phone signals (no SDK)
- Building Fraud Rules - Using device signals in rules
- Account Takeover - ATO detection with device data
- Velocity Rules - Device-based velocity limits
- Promo Abuse - Multi-account detection
- Risk Scoring - Incorporating device signals into scores
- Behavioral Analytics - Complementary detection method
- Evidence Framework - How device data fits Tier 1/Tier 2
- Compelling Evidence - Using device data in representment
- Manual Review - When device signals trigger review
- Fraud Vendors - Full vendor landscape
- Card Testing - Bot detection patterns
- Fraud Model Feedback - How device signals improve ML
- Running Fraud Operations - Operational cadence