Device Intelligence and Fingerprinting Guide

Passwords, one-time codes and even session cookies can be stolen and replayed, so fraud and identity teams increasingly ask a second question: is this the device we expect, and is it a real one? Device intelligence answers it by combining browser, operating system, network and app attestation signals into a device identity and a risk score. The same techniques are used by advertisers to track people who have cleared their cookies, which is why regulators treat fingerprinting with suspicion and why fraudsters sell stolen fingerprints for anti-detect browsers. This guide is for fraud, CIAM and security engineering teams, and the privacy colleagues who must sign off. It explains what a fingerprint is made of, how each signal is spoofed, how to use device intelligence without breaking ePrivacy, PECR or platform rules, and how to measure whether it works.

Key takeaways

• A fingerprint is a probability, not an identity. The W3C fingerprinting guidance notes that "30-some bits of entropy would be enough to uniquely identify every individual person", but mobile devices share configurations far more than desktops, so collisions and drift are normal and must be measured.
• Consistency beats uniqueness for fraud detection. The Browser Polygraph study (IMC 2024) flagged sessions whose JavaScript engine did not match the claimed user agent, and those sessions were about five times more likely to be linked to account takeover.
• Attestation is stronger than fingerprinting on mobile. Google Play Integrity and Apple App Attest give cryptographically backed verdicts on device and app genuineness, and Apple states that "Regardless of whether a user gives your app permission to track, fingerprinting is not allowed."
• Fraud prevention does not switch off privacy law. The ICO says PECR regulation 6 "applies where fingerprinting stores information, or accesses information stored, on a device". Its strictly necessary exception lists "preventing or detecting fraud", but only if the data is used solely for that purpose.
• Use device risk to choose the friction, not to make final decisions. A new or suspicious device should trigger step-up authentication or review; blocking on a fingerprint alone punishes legitimate users who changed phones or browsers.

What device intelligence is made of

The ICO defines device fingerprinting as "collecting pieces of information about a device's software or hardware" that "can be combined to uniquely identify a particular device", and lists configuration data, CSS information, JavaScript objects, HTTP header information, clock information, TCP stack variation, installed fonts and plugins, and API use. The W3C distinguishes three forms: passive fingerprinting from data visible in requests "without the use of any code executed on the client"; active fingerprinting with JavaScript, which is "potentially detectable on the client"; and cookie-like fingerprinting, where a site sets and later retrieves state, as evercookie did by copying an identifier into HTTP cookies, ETags, the web cache, HTML5 storage and canvas-encoded PNG images so that "only one surviving copy" respawned the rest.

Fingerprinting techniques and their limits

Network, TLS and OS fingerprinting

• JA3 and JA4: JA3 concatenates the decimal values of five Client Hello fields and MD5-hashes them into "an easily consumable and shareable 32 character fingerprint". The Salesforce repository was archived on 1 May 2025. Chrome began randomising TLS extension order in early 2023, which breaks JA3; JA4 sorts ciphers and extensions so fingerprints stay stable, and uses an a_b_c format so analysts can match parts of a fingerprint. JA4 is BSD 3-Clause licensed; JA4S, JA4H (HTTP client), JA4T (TCP) and the rest of JA4+ use the FoxIO License, which restricts commercial resale.
• Passive and active OS fingerprinting: passive methods infer the operating system from TCP SYN characteristics without sending anything (p0f is the classic tool, JA4T a newer format). Active methods such as Nmap OS detection send crafted probes and match responses against a database of known stacks. Fraud teams use passive methods only; active probing of customer devices is inappropriate.
• Mismatch is the signal: a User-Agent claiming Chrome on Windows with a TLS fingerprint typical of a Python library, or a Linux TCP stack, indicates automation or an anti-detect tool.
• Web application fingerprinting works both ways: attackers fingerprint your login pages and anti-bot scripts to tune their tools. Strip version banners and avoid exposing which fraud vendor's script you load where you can.

Browser fingerprinting

• Canvas fingerprinting: the script draws text and shapes to a hidden canvas and hashes the pixels; differences in fonts, anti-aliasing and GPU produce a device-specific hash. WebGL fingerprinting does the same with 3D rendering and also reads renderer and vendor strings.
• Audio fingerprinting: an offline AudioContext processes a generated signal; floating-point differences across hardware and software produce a stable value without playing any sound.
• Browsers are pushing back: Firefox Enhanced Tracking Protection blocks scripts on Disconnect's fingerprinting list, and its Fingerprinting Protection (on in Private Browsing and Strict mode) adds random data to canvas read-backs and alters reported fonts, touch points, screen and CPU core counts. Chrome's User-Agent reduction cut the default User-Agent string to high-level values and moved detail into client hints: Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform by default, with high-entropy hints only on request through Accept-CH.
• Design for decay: W3C notes that "Mitigations recommended here are simply mitigations, not solutions", and in practice each browser release changes some attributes. A device model must tolerate partial matches and re-link devices whose fingerprint has drifted.

Mobile devices, emulators and attestation

Mobile app fingerprinting is more constrained than web fingerprinting, by design. Android 10 restricts non-resettable identifiers such as IMEI and serial number, third-party apps cannot read MAC addresses, and Google's guidance says the Advertising ID must not be "associated with any persistent device identifier". Apple prohibits fingerprinting outright and, since 1 May 2024, rejects apps that do not declare reasons for "required reason" APIs in their privacy manifest.

• Google Play Integrity: Google's identifier guidance says to use it "To verify that a request comes from a genuine Android device, rather than an emulator or other code spoofing another device". Verdicts include MEETS_DEVICE_INTEGRITY (genuine, certified device), opt-in MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY (certified with a security update in the last year on Android 13 and later), and MEETS_VIRTUAL_INTEGRITY, which applies only to Google Play Games for PC. An ordinary emulator returns an empty device verdict. appRecognitionVerdict shows whether the app binary is the one Google Play distributed.
• Apple DeviceCheck and App Attest: DCDevice lets your server set and query "two binary digits of data per device", for example to flag a device already judged fraudulent or one that has used a promotion. DCAppAttestService generates a key on the device that Apple attests, so your server can check that requests come from a genuine instance of your app. Apple is candid that "No single policy can eliminate all fraud" and that App Attest cannot definitively detect a compromised operating system.
• Emulator, root and hooking detection: OWASP MAS lists "Emulated or Virtual Device Detection Not Implemented" (MASWE-0053) and "Root/Jailbreak Detection Not Implemented" (MASWE-0051) as weaknesses under MASVS-RESILIENCE. Client-side checks are bypassable with instrumentation frameworks, so treat them as signals for the server, never as the enforcement point.
• Stable app identifiers: for non-advertising use, Google recommends a Firebase installation ID or a privately stored GUID, which survive only while the app is installed. That is usually enough to recognise a returning installation.

Evasion: anti-detect browsers and device spoofing

Anti-detect browsers "allow a user to distort or hide a browser's identifying information", in the words of the Browser Polygraph authors, and fraudsters load stolen victim fingerprints into them to pass risk-based authentication as the victim's own device. The paper describes stolen fingerprints traded on criminal marketplaces as cybercrime-as-a-service, and observes that "The most trivial step for configuring a fraud browser is setting the user-agent value". Emulator farms, virtual machines, residential proxy networks and app repackaging do the same job on mobile.

• Check internal consistency: the claimed browser and version should match JavaScript engine behaviour, TLS fingerprint, client hints and fonts. Browser Polygraph used coarse counts of JavaScript prototype properties, about 1 KB per fingerprint and a 6 ms average response, and in production at a large financial firm flagged 897 of more than 205,000 sessions.
• Expect limits: the same study reported recall of 67% to 84% against fraud browsers in controlled tests and noted that fraudsters who fully emulate a genuine environment were out of scope. Layer device signals with behaviour, network and account history.
• Watch for too-perfect or too-random devices: noise-injected canvas values that change on every page, a fingerprint that is identical across hundreds of accounts, or a "new" device every session all deserve scrutiny.
• Protect the collection script: integrity-check or obfuscate the client SDK and sign its payloads server-side so attackers cannot simply replay a captured good payload.

Using device intelligence in fraud and identity decisions

• Device reputation: history attached to a device ID: past fraud confirmations, chargebacks, number of accounts seen, age of first sighting. DeviceCheck bits are a privacy-preserving version for iOS.
• Device linking: graphs connecting accounts that share devices reveal mule networks, multi-accounting and promotion abuse. Simple velocity rules, such as a cap on new accounts per device per day, work well but need tuning for shared family and kiosk devices.
• Login and account takeover: a known device with a matching fingerprint can skip step-up; a new device with a datacentre IP and a TLS mismatch should face phishing-resistant MFA. Credential stuffing, the technique behind the 23andMe breach, is automated, which is what TLS, header and consistency checks are built to catch. See the MFA Guide.
• Payments: the PSD2 regulatory technical standards (Commission Delegated Regulation (EU) 2018/389) require transaction monitoring to consider "the abnormal use of the access device or the software" (Article 2(2)(e)), and a transaction can be exempted under transaction risk analysis only if there is no "unusual information about the payer's device/software access" (Article 18(2)(c)(ii)).
• Device binding: the strongest device link is cryptographic: a key generated in secure hardware (an App Attest key, a device-bound passkey, a hardware-backed key on Android) bound to the account at enrolment. Device binding fraud then moves to the enrolment step, where attackers socially engineer support or recovery to register their own device, so protect it with the same rigour as login. See the Account Recovery and Help Desk Security Guide.

Choosing an approach

• Smaller organisations: start with the device and bot signals your CIAM platform, CDN or web application firewall already provides, plus attestation in mobile apps. A dedicated device intelligence platform pays off when fraud losses or account takeover volumes justify a data team to tune it.
• Larger organisations: run a central device ID service consumed by login, onboarding and payments, with one retention policy, one DPIA and shared fraud labels to train models.

Privacy and legal constraints

• ePrivacy Article 5(3): storing information, or "gaining of access to information already stored", on a user's terminal equipment requires consent unless it is for "the sole purpose of carrying out the transmission of a communication" or strictly necessary for a service the user explicitly requested. EU member states implement this nationally; in the UK it is PECR regulation 6.
• ICO position: the ICO guidance on storage and access technologies, finalised on 29 April 2026, says some organisations wrongly think regulation 6 does not apply to fingerprinting. Its strictly necessary exception covers "preventing or detecting fraud" and "authenticating the subscriber or user", but you must "only use it for this purpose", assess necessity "from the point of view of the subscriber or user", and get consent for fingerprinting used for online advertising. Click fraud detection is listed among advertising purposes that need consent.
• The Google policy change: when Google allowed fingerprinting by users of its advertising technology from 16 February 2025, the ICO called the change "irresponsible" and said fingerprinting is "not a fair means of tracking users online" because users cannot easily clear or block it.
• GDPR: Recital 30 recognises that online identifiers can be "used to create profiles of the natural persons and identify them", so device IDs are personal data. Recital 47 says processing strictly necessary for preventing fraud is "a legitimate interest of the data controller concerned", which supports Article 6(1)(f) as the lawful basis for the GDPR side, separate from the ePrivacy question. Automated decisions with legal or similarly significant effects engage Article 22, and large-scale device profiling normally needs a DPIA under Article 35.
• Purpose limitation in practice: keep fraud device data in a separate store, forbid its reuse for marketing or analytics, set short retention, and record the necessity assessment. See the Consent Management Guide: Cookies, CMPs and GPC.

Implementation roadmap

1. Define the use cases and the legal position first: which decisions (login, sign-up, payment, recovery) device signals will influence, the ePrivacy or PECR exception relied on, the lawful basis, retention and a DPIA.
2. Collect passively, score silently: deploy collection in shadow mode for four to eight weeks, joining device IDs to confirmed fraud and account takeover labels without changing any decision.
3. Measure the device model: estimate how often one device gets several IDs and how often different devices share one, by platform and browser.
4. Pilot step-up, not blocks: route the riskiest decile to step-up authentication in one channel, compare fraud and abandonment against a control group.
5. Add attestation in apps: integrate Play Integrity and App Attest server-side verification, starting in report-only mode, then enforce on high-risk actions.
6. Roll back cleanly: keep every device rule behind a feature flag with a fail-open default for login, so an SDK outage or browser change does not lock out customers.

Detection and measurement

Log each decision with the device ID, the signals that drove the score, the action taken and the eventual outcome, so rules can be audited and challenged. Useful KPIs:

• Account takeover and fraud rate per 10,000 logins or transactions, before and after enforcement.
• Step-up rate and step-up pass rate for genuine users, a proxy for friction.
• False positive rate: legitimate users challenged or blocked, confirmed through complaints and appeals.
• Device ID stability (same device, same ID across sessions) and collision rate (different devices, same ID), tracked per browser release.
• Share of mobile sessions with a valid attestation verdict, and the trend in empty or failing verdicts.
• Model drift: time since last retraining against fresh fraud labels; Browser Polygraph saw accuracy hold for about three and a half months before retraining was needed.

Framework mapping

Common failure patterns

• Treating the fingerprint as a hard identifier: blocking all logins from "unknown" devices locks out customers after every phone upgrade or browser update.
• Trusting the client's verdict: root or emulator checks evaluated only in the app, or attestation tokens accepted without server-side verification, are bypassed with instrumentation tools.
• Purpose creep: fraud device data quietly reused for marketing attribution, which removes the strictly necessary argument the ICO allows only for single-purpose use.
• Relying on the User-Agent: the easiest attribute to spoof, and one Chrome has deliberately reduced.
• Static rules never retrained: browser releases and new anti-detect builds erode accuracy within months.
• Weak enrolment of trusted devices: strong device binding at login undone by a help desk that will register a new device on a phone call.

Practitioner checklist

• Document each use case, the ePrivacy or PECR exception relied on, the GDPR lawful basis and retention, and complete a DPIA.
• Combine passive network and TLS signals with client signals and check them for consistency.
• Use JA4 rather than JA3 for TLS fingerprinting of modern browsers.
• Integrate Play Integrity and App Attest with server-side verification in mobile apps.
• Use device risk to drive step-up authentication, not silent blocking.
• Run new models in shadow mode and measure stability, collisions and false positives before enforcing.
• Separate fraud device data from marketing systems and forbid reuse.
• Protect device enrolment and recovery as strongly as login.
• Retrain models and review rules at least quarterly.

Standards and references

• EUR-Lex: Directive 2002/58/EC (ePrivacy Directive), consolidated text
• ICO: Guidance on the use of storage and access technologies, What are storage and access technologies?
• ICO: Our response to Google's policy change on fingerprinting
• W3C: Mitigating Browser Fingerprinting in Web Specifications
• Android Developers: Play Integrity API integrity verdicts
• Apple Developer: DeviceCheck
• FoxIO: JA4+ network fingerprinting
• ACM IMC 2024: Browser Polygraph, Efficient Deployment of Coarse-Grained Browser Fingerprints for Web-Scale Detection of Fraud Browsers

Related NHI Mgmt Group resources: Identity Fraud Prevention Guide · Customer IAM (CIAM) Guide · Consent Management Guide: Cookies, CMPs and GPC · GDPR Compliance Guide for Security Teams · Token and Session Security Guide. This guide summarises EU and UK rules on device fingerprinting, the GDPR and PSD2 provisions relevant to fraud prevention, and Apple and Google platform policies as they stood in October 2026, and is not legal advice.