GDPR and browser fingerprinting

What GDPR says about fingerprinting

GDPR itself does not use the word 'fingerprinting'. Instead, Article 4(1) defines personal data as 'any information relating to an identified or identifiable natural person', and Recital 30 calls out 'online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers' as examples of identifying information that can be combined with other data to single someone out.

A browser fingerprint (the hash of a user's screen, fonts, audio stack, GPU, time zone and other device characteristics) falls squarely inside that definition the moment it is used to recognise the same visitor across sessions. The fingerprint does not need to reveal a name, an email or a face: identifiability under GDPR is about the ability to single out, not about formal identification.

This was first laid out in Article 29 Working Party Opinion 9/2014, which treated device fingerprinting as functionally equivalent to a cookie ID for legal purposes. The EDPB carried that view forward in Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, removing any remaining ambiguity: fingerprinting is in scope.

Article 5(3) ePrivacy: the storage-and-access rule

Article 5(3) of Directive 2002/58/EC (as amended in 2009) requires prior consent before any 'storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user'. The wording was written with cookies in mind, but it is technology-neutral. The EDPB's 2023 guidelines confirmed that reading device characteristics over the open web, even passively and without writing anything back, constitutes 'gaining of access to information already stored', and therefore requires consent.

The only escape is the narrow exception in the same article: consent is not required where the access is 'strictly necessary in order to provide an information society service explicitly requested by the subscriber or user', or for the sole purpose of carrying out the transmission of a communication. 'Strictly necessary' is read narrowly. Personalisation, A/B testing, analytics and behavioural advertising all fail the test. Specific anti-fraud and security-of-service uses can pass, but only when fingerprinting is genuinely required for that purpose and proportionate to it.

What valid consent looks like

GDPR Article 4(11) defines consent as 'any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement'. Three operational consequences for a fingerprinting deployment:

First, consent must be obtained before the first signal read. A banner that fires the fingerprint script before the user clicks 'Accept' is non-compliant by construction. The CNIL has made this a recurring enforcement theme since 2020.

Second, 'reject' must be as easy as 'accept'. The EDPB Cookie Banner Taskforce report (January 2023) lists pre-ticked boxes, hidden reject buttons, and 'legitimate interest' second-layer toggles as common dark patterns. CNIL fines against Google and Facebook in 2021/2022 cited exactly this asymmetry.

Third, consent must be granular. A single 'Accept all' that covers fingerprinting alongside basic analytics fails the 'specific' test in Article 4(11).

The anti-fraud carve-out, in practice

The single most common question from product teams is whether a fingerprint used to detect fraud needs consent. The short answer is that a narrowly-scoped, security-purpose fingerprint typically qualifies as 'strictly necessary' under Article 5(3) ePrivacy and as 'legitimate interest' under GDPR Article 6(1)(f). The longer answer is that this only holds if four conditions are met:

The fingerprint is used solely to detect fraud or abuse, not repurposed for analytics, marketing or personalisation. The retention period is short and tied to the fraud-detection lifecycle. Users are transparently informed in a privacy notice. A legitimate-interest assessment (LIA) has been documented before the deployment.

Regulators have not yet drawn a bright line around the carve-out, and several CNIL decisions have signalled that the bar will be enforced strictly: silent or 'invisible' fingerprinting deployments without a documented LIA have been treated as ordinary unconsented tracking.

Enforcement examples

Fingerprinting-specific fines under GDPR remain rare in absolute terms because regulators have so far treated fingerprinting as part of broader cookie-and-tracking enforcement. Several decisions, however, name fingerprinting explicitly or hinge on facts that apply directly:

What counts as 'a fingerprint' under EU law

Regulators have not published a closed list of signals that constitute fingerprinting. The EDPB's 2023 guidelines instead use a purpose-based test: any combination of identifiers, whether passively read or actively probed, that allows a service to recognise the same device, browser, or user across requests is fingerprinting.

In practice, this catches the obvious cases (canvas hashes, font enumeration, WebGL renderer strings, AudioContext outputs, WebRTC SDP) and the less obvious ones (IP address combined with User-Agent and screen resolution, hash of HTTP header order, TLS handshake characteristics, behaviour-based signals such as mouse movement entropy). It does not catch raw IP logging for security audit trails alone, which is generally treated as a separate processing activity under GDPR Article 6(1)(f).

Territorial reach: do we have to care if we're outside the EU?

Yes, in two situations. GDPR Article 3(2) extends the regulation to any controller or processor outside the EU that offers goods or services to data subjects in the EU, or monitors their behaviour within the EU. Fingerprinting EU visitors to your site is monitoring behaviour by definition. The ePrivacy Directive applies via national transposition in each EU member state, and the same Article 3(2) territorial test is used by most national DPAs as a practical matter.

There is no 'small business' exemption that switches off the consent obligation. The €0–€10M turnover band determines the fine ceiling, not whether the rules apply.

How Benny the Doorman fits into a GDPR-aware deployment

Benny is a fingerprinting SDK, not a consent management platform. That separation is deliberate: consent collection should live in your CMP (e.g. OneTrust, Cookiebot, Iubenda, Didomi, an in-house solution), and the fingerprint should only be requested once the CMP signals that consent has been granted for the relevant purpose category.

Concretely, this means three integration steps for a GDPR-aware deployment. First, defer the call to Benny's fingerprint API behind your CMP's consent signal for a 'fingerprinting' or 'device identification' purpose category. Second, document the lawful basis for each downstream use of the resulting hardware ID in your record of processing activities (ROPA). Third, if you are relying on the strictly-necessary anti-fraud carve-out, keep that data flow separate and document the legitimate-interest assessment.

Benny's processing is performed in-region on infrastructure in Chennai, India, with no per-call data leaving the country by default. EU controllers transferring fingerprints to that infrastructure should treat it as a third-country transfer under GDPR Chapter V; the standard SCC route is available on request alongside our DPA.