Device Fingerprinting: How It Works and How Didit Uses It to Stop Fraud

Two accounts, two names, two documents — but the same phone, the same browser build, the same GPU. Cookies were cleared, the second signup happened in an incognito window, and the IP rotated through a VPN. To most onboarding flows those look like two different people. Device fingerprinting is what tells you they are not.

This post explains what device fingerprinting is, how it actually works, where it differs from cookies, and how Didit uses it inside Device & IP Analysis to catch duplicate devices, fraud rings, and multi-accounting during identity verification — without merging unrelated users by mistake.

Key takeaways

• Device fingerprinting builds a stable identifier for a device from its browser, hardware, and network signals — independent of cookies, so it survives storage clears, incognito mode, and app reinstalls.
• It's one of the strongest first-touch fraud signals because the things that make a device unique (GPU, screen, fonts, OS build, sensor quirks) are hard to change at scale and expensive for fraudsters to spoof convincingly.
• The high-value use case is detecting the same device behind different identities: multi-accounting, bonus and referral abuse, fraud rings, synthetic identities, and money-mule onboarding.
• Didit runs device fingerprinting automatically in every verification session as part of Device & IP Analysis ($0.03), returning a device_fingerprint, duplicate-device matches, a high-confidence recovery signal, and configurable warnings you can wire to approve / review / decline.
• Didit separates exact matches from recovered matches and guards against hash collisions, so you get the fraud signal without falsely linking shared-office or shared-WebView devices.

What is device fingerprinting?

Device fingerprinting is the practice of identifying a device — a phone, laptop, or tablet — from the combination of attributes it exposes when it connects to your app. No single attribute is unique, but the combination of dozens of them (screen resolution, GPU model, installed fonts, operating-system build, time zone, language, browser version, canvas and WebGL rendering quirks) is distinctive enough to recognize the same device again later.

The output is a fingerprint: a stable identifier derived from those signals. Unlike a username or an email address, the user never chooses it and usually doesn't know it exists. That's exactly why it's useful for fraud prevention — a fraudster can invent a new name and buy a new stolen document, but they're often sitting at the same machine.

How device fingerprinting works

Fingerprinting happens client-side: a small script or SDK runs in the browser or mobile app, reads a set of signals, and turns them into one or more hashes. The signals usually fall into a few buckets.

Browser and software signals

• User-agent string, browser family and version, installed plugins and MIME types
• Language, time zone, and locale
• Screen resolution, color depth, available fonts
• HTTP header order and TLS characteristics

Hardware and rendering signals

• GPU model and driver, exposed through WebGL
• Canvas fingerprinting — the browser is asked to render hidden text/graphics; tiny differences in GPU, drivers, and anti-aliasing produce a per-device image hash
• AudioContext fingerprinting — the audio stack processes a signal slightly differently per device
• CPU class, device memory, battery and sensor quirks on mobile

Network and behavioral signals (often paired with fingerprinting)

• IP address, geolocation, connection type, ASN
• VPN / proxy / Tor / data-center detection
• Optionally, behavioral cues like typing cadence

Those signals are combined into hashes. A robust implementation produces more than one: a persistent device identifier (stable while local storage survives), a composite hash (a deterministic grouping of signals), and a signal vector used to recover a device even when the persistent ID has been wiped.

Device fingerprinting vs cookies

Cookies and device fingerprints both recognize returning visitors, but they work differently — and that difference is why fraud teams rely on fingerprinting.

	Cookies	Device fingerprinting
Where it lives	A file the browser stores client-side	Derived from device signals; reference data stored server-side
User control	Trivially deleted or blocked	Cannot simply be deleted; survives storage clears
Survives incognito?	No	Yes (recovery signal)
Survives reinstall?	No	Often yes
Primary purpose	Sessions, preferences, analytics	Recognizing the device behind an identity

A fraudster opening 50 accounts will clear cookies, switch to incognito, or reinstall the app between attempts. Cookies reset each time; a good device fingerprint keeps pointing at the same machine.

Why device fingerprinting matters for fraud prevention

Most account-level fraud has one tell in common: one device behind many identities. Fingerprinting surfaces it at the earliest possible point — signup or onboarding — before money moves.

• Multi-accounting — one person running many accounts to evade limits, bans, or eligibility rules.
• Bonus, referral, and promo abuse — the same device farming sign-up bonuses, free trials, or referral payouts under different names.
• Fraud rings — coordinated networks operating dozens of accounts from a shared set of devices or infrastructure.
• Synthetic identity onboarding — fabricated identities created in volume, often from a small pool of devices.
• Money-mule onboarding — many "different" people onboarding from the same machine.
• Account takeover (ATO) — a login or step-up from a device that has never been associated with the legitimate user.

Spotting suspicious setups matters too: virtual machines, automation frameworks, emulators, or impossible signal combinations (a "mobile" user agent with a desktop GPU) are themselves red flags.

How Didit uses device fingerprinting: Device & IP Analysis

Didit runs device fingerprinting automatically inside every verification session as part of Device & IP Analysis — combining the device fingerprint, duplicate-device recovery, IP intelligence, and geolocation into one risk surface. There's no separate integration to build: the Web and Mobile SDKs collect the signals in-band during the hosted KYC flow, and the result lands on the decision payload under ip_analyses[].

What Didit captures

Didit sends a privacy-safe v2 fingerprint payload from the verification client:

Signal	What it's for
Persistent device ID	First-party identifier for exact same-device detection while storage persists.
Composite hash	Stable grouped-signal hash for deterministic duplicate checks, with collision safeguards.
Signal vector	Device and browser/app attributes vectorized for high-confidence recovery.
Platform context	Browser, OS, app, hardware, WebGL/canvas, media, locale, time zone, and mobile integrity signals.

In parallel it enriches the connection: IP geolocation, VPN / proxy / Tor / data-center detection, optional expected-IP pinning, and IP blocklist checks.

The matching model

The hard part of device fingerprinting isn't catching the obvious reuse — it's catching reuse after the fraudster resets, without falsely linking innocent users who happen to share a WebView pool or an office network. Didit separates the layers so you can tune your response safely:

Layer	What it detects	Posture
Exact persistent ID	The same first-party device identity in another user's session.	Strongest signal → DUPLICATED_DEVICE_FINGERPRINT.
Composite hash	The same deterministic device hash across users.	Guarded by collision detection so common browser/WebView pools are suppressed.
v2 recovered device	Persistent ID changed, but rich signals match a previous device with high confidence.	Conservative → DEVICE_RECOVERED_HIGH_CONFIDENCE, only after hard gates pass.
IP reuse	The same IP across users.	Contextual — shared offices, households, and mobile carriers can be legitimate.

That recovery layer is what catches the storage-clear / incognito / reinstall trick: even when the persistent ID changes, the v2 model can link the session back to a device it has seen before.

The warnings you act on

Each entry in ip_analyses[] carries a device_fingerprint, the device brand/model/browser/OS, a matches[] array of duplicate sessions (grouped by vendor_data so the same user isn't flagged against themselves), and a set of configurable warnings:

Warning	Meaning	Default action
DUPLICATED_DEVICE_FINGERPRINT	Same persistent device reused under a different identity	Approve (configurable)
DEVICE_RECOVERED_HIGH_CONFIDENCE	Recovered device after storage/incognito/reinstall	Approve (configurable)
DEVICE_FINGERPRINT_IN_BLOCKLIST	Device matches your blocklist	Forces Decline
DUPLICATED_IP_ADDRESS	Same IP across users	Approve (configurable)
PRIVATE_NETWORK_DETECTED	VPN, proxy, or Tor	Review (configurable)
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	Document country ≠ IP country	Review (configurable)
EXPECTED_IP_ADDRESS_MISMATCH	Live IP ≠ the IP you pinned at session creation	Decline (configurable)

You configure each category independently in the Business Console — approve, route to manual review, or hard-decline — and consume the result via webhooks, the decision API, the dashboard, or the verification PDF. See the full warning catalogue.

A worked example

Here's a Declined decision: an IP blocklist hit, masked traffic, and a reused device all on one session.

{
  "ip_analyses": [
    {
      "status": "Declined",
      "device_brand": "Generic",
      "device_model": "Linux PC",
      "browser_family": "Chrome",
      "device_fingerprint": "fp_re-used_a13c",
      "warnings": [
        { "risk": "IP_ADDRESS_IN_BLOCKLIST" },
        { "risk": "PRIVATE_NETWORK_DETECTED" },
        { "risk": "DUPLICATED_DEVICE_FINGERPRINT" }
      ],
      "matches": [
        {
          "match_type": "device_fingerprint",
          "matched_value": "fp_re-used_a13c",
          "device_info": { "brand": "Generic", "model": "Linux PC", "os": "Linux", "platform": "desktop" }
        }
      ]
    }
  ]
}

The device was already enrolled under a different vendor_data, the traffic is masked, and the IP is on your blocklist — three independent reasons to stop the session before it becomes an account.

Privacy and compliance

Device fingerprinting sits inside privacy law (GDPR, ePrivacy, and similar regimes treat device identifiers as personal data). Didit's implementation is designed to be privacy-safe: it collects a fingerprint for fraud prevention — a legitimate-interest purpose tied to the verification you're already running — rather than for cross-site advertising. Signals are vectorized and hashed, matching is gated to avoid pooling unrelated users, and the whole feature runs only within the consented verification session. Didit is the only identity provider formally attested by an EU member-state government (Spain's Tesoro / Banco de España / SEPBLAC sandbox) as safer than in-person verification.

How to integrate with Didit

Device & IP Analysis is session-only — there's no standalone endpoint to call. It runs automatically on every session:

1. (Optional) In the Business Console, set strict-mode actions per risk — e.g. decline on VPN, review on duplicate device, decline on country-vs-document mismatch.
2. Create a session — POST /v3/session/ with your workflow_id, vendor_data (always send a stable per-user value so duplicates are scoped correctly), and callback.
3. Open session.url for the user — the SDK collects the fingerprint and IP in-band.
4. Read the result — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated, and parse ip_analyses[].

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_WORKFLOW_ID",
    "vendor_data": "user-123",
    "callback": "https://yourapp.com/post-kyc"
  }'

Full reference: the Device & IP Analysis overview, the report schema, and the data models.

Frequently asked questions

How much does device fingerprinting cost with Didit?

It's part of Device & IP Analysis at $0.03 per check, and it runs inside the verification session — no separate integration. Didit also gives you 500 free verifications every month.

Can fraudsters defeat device fingerprinting?

They try — VMs, anti-detect browsers, spoofed user agents, storage resets. Didit counters this on two fronts: the recovery model links a device back even after the persistent ID changes, and masked-traffic / suspicious-setup signals (VPN, Tor, data-center IP, impossible signal combinations) are surfaced as their own warnings. No single signal is decisive, which is why Didit returns a layered set you combine per your policy.

Will it falsely link two unrelated users?

Didit guards against this deliberately: composite hashes are suppressed by a collision guard for common WebView/browser pools, recovered-device matches require high-confidence gates, and matches are scoped by vendor_data so the same user is never flagged against themselves.

Do I need to handle the case where there's no fingerprint?

Yes — ip_analyses[] can come back empty if the user blocked the SDK's fingerprinting script with a privacy extension or content blocker. Decide up front whether to fail-closed or fall back to your other risk signals.

Does this work on mobile as well as web?

Yes. The Web and Mobile SDKs both collect the v2 fingerprint, including mobile integrity signals where available.

Ready to get started?

Device fingerprinting is one signal in Didit's broader fraud surface — paired with IP intelligence, document verification, biometrics, and AML screening, all composable in one workflow.

• Learn the feature → Device & IP Analysis docs
• See it in the platform → User Verification
• Check the price → Pricing — Device & IP Analysis at $0.03, 500 free verifications/month
• Start free → business.didit.me