The Directive most teams get wrong
Most product and engineering teams building for EU users think of GDPR as the consent instrument. It is not, for fingerprinting. GDPR Article 6 governs the lawful basis for processing personal data once you have it. The act of reaching into a browser and reading device signals, whether actively via JavaScript probes or passively via server-side HTTP header analysis, is governed by Article 5(3) of Directive 2002/58/EC, also called the ePrivacy Directive or, informally, the cookie law.
Article 5(3) was introduced in the original Directive (effective 31 October 2003) and materially strengthened by amending Directive 2009/136/EC, which came into force on 25 May 2011. Before the 2009 amendment, notice and an opt-out were enough. After it, prior, informed consent became mandatory. That shift is the legal foundation on which every EU cookie banner since 2011 rests, and fingerprinting sits on the same foundation.
Article 1(2) of the Directive makes the relationship with the broader data protection framework explicit: the Directive 'particularises and complements' the Data Protection Directive (replaced by GDPR in 2018), meaning the ePrivacy rules are lex specialis. They take precedence over GDPR where both could apply to the same act of data collection.
Article 5(3) and fingerprinting: the regulatory journey
The text of Article 5(3) was drafted with cookies in mind. It prohibits 'the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user' without prior consent, subject only to the strictly-necessary exception. For years after the 2011 amendment, regulators and legal practitioners debated whether passive fingerprinting, reading values that the device broadcasts rather than writing anything back, fell within the phrase 'gaining of access to information already stored'.
Article 29 Working Party Opinion 9/2014 on the application of Directive 2002/58/EC to device fingerprinting was the first authoritative regulatory document to name fingerprinting explicitly and answer that question. The WP29 concluded that reading device characteristics constitutes accessing information stored in terminal equipment, regardless of whether any cookie or local storage object is written, and that the same consent requirements apply.
EDPB Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive confirmed and elaborated this position. The EDPB conducted a detailed technical analysis of how browsers expose device signals and concluded: 'techniques such as fingerprinting... that access information stored in the terminal equipment of end-users fall within the scope of Article 5(3).' The guidelines are binding guidance for national DPAs, and effectively removed any remaining room for argument.
The strictly-necessary carve-out: what it covers and what it does not
Article 5(3) contains one exception: 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 over an electronic communications network. The EDPB, Article 29 Working Party, and national DPAs have all interpreted this carve-out narrowly.
The word 'necessary' is given its plain meaning: there must be no reasonable alternative, and the fingerprinting must be genuinely indispensable to the service. 'Strictly' tightens this further: proportionality is required, and the processing cannot be broader than the minimum needed. 'Explicitly requested by the user' means the user consciously initiated the service interaction, not merely that they are browsing a website.
In practice, the carve-out is most reliably available to anti-fraud and security-of-service use cases, such as detecting account takeover attempts or blocking automated abuse at login or payment endpoints. It is not available for analytics, product personalisation, A/B testing, advertising frequency capping, or cross-site tracking under any reading of the text endorsed by regulators. Recital 66 of the amended Directive confirms that 'cookies can be a legitimate and useful tool' for certain purposes while requiring consent for others; the same reasoning governs fingerprinting.
Fingerprinting purpose vs. strictly-necessary carve-out
| Fingerprinting purpose | Qualifies as strictly necessary? | Consent required under Art. 5(3)? |
|---|---|---|
| Blocking known malicious devices at login | Usually yes, if scoped | Usually no, with transparent notice |
| Account takeover / credential-stuffing detection | Usually yes | Usually no, with documented LIA |
| Bot mitigation on public-facing form or API | Usually yes | Usually no |
| Session continuity for a logged-in user within a single visit | Possibly yes, if cookies are unavailable | Depends on scope |
| Product analytics and funnel measurement | No | Yes, explicit |
| A/B testing and personalisation | No | Yes, explicit |
| Behavioural advertising and retargeting | No | Yes, explicit and granular |
| Cross-site or cross-device identity matching | No | Yes, explicit and granular |
How member states transposed the Directive, and why it matters
Unlike a Regulation (such as GDPR), a Directive does not apply directly. Each EU member state was required to transpose it into national law, and there are meaningful differences in how they did so, particularly in penalty levels and enforcement priorities.
France transposed the amended Directive in Article 82 of the French Data Protection Act 1978 (Loi Informatique et Libertés). The CNIL enforces Article 82 as the primary instrument for cookie and fingerprinting cases and has published detailed cookie guidance that explicitly references fingerprinting. Italy transposed the requirements in Articles 122 and 123 of the Italian Personal Data Protection Code (Codice in materia di protezione dei dati personali), enforced by the Garante per la protezione dei dati personali. Germany transposed via the Telecommunications-Telemedia Data Protection Act (TTDSG), effective December 2021, which introduced a more explicit consent requirement than the earlier Telemediengesetz. Spain transposed via Article 22 of the Law on Information Society Services and Electronic Commerce (LSSICE).
The UK was an EU member when the 2011 amendments came into force and transposed the rules in the Privacy and Electronic Communications Regulations 2003 (PECR), enforced by the ICO. Post-Brexit PECR remains the operative UK instrument; see the UK GDPR + PECR page for the diverging UK position.
Selected national enforcement actions involving Article 5(3) and fingerprinting or cookie-equivalent tracking
- CNIL v. Google LLC and Google Ireland (December 2021, Article 82): EUR 150M fine for making it harder to refuse cookies than to accept them; the same UX standard applies to fingerprinting consent banners.
- CNIL v. Facebook Ireland (December 2021, Article 82): EUR 60M fine on the same accept/reject parity theory.
- CNIL v. TikTok (June 2022, Article 82): EUR 5M fine. The decision cited failure to provide an equally prominent refusal mechanism for tracking technologies including fingerprinting-adjacent identifiers.
- CNIL v. Microsoft Corporation (December 2022, Article 82): EUR 60M fine. Bing's cookie rejection flow was found non-compliant with Article 82 consent requirements.
- Garante v. Glovo (May 2023): EUR 3M fine for processing device and location identifiers without adequate legal basis, citing the Italian transposition of Article 5(3).
- AEPD (Spain) v. various ad-tech operators (2022-2023): multiple sanctions citing Article 22 LSSICE violations for fingerprinting-based tracking without valid consent in programmatic advertising contexts.
The pending ePrivacy Regulation, and why you cannot rely on it yet
The European Commission proposed a new ePrivacy Regulation in January 2017, intended to replace the Directive with directly applicable EU law carrying GDPR-level fines. The Regulation would have resolved years of inconsistency between member-state transpositions, introduced rules on machine-to-machine communications, and updated the consent framework for modern tracking techniques including fingerprinting.
As of June 2026, the Regulation remains stalled. Negotiations between the European Parliament and the Council have repeatedly broken down over the scope of legitimate interest as a lawful basis for tracking, browser-level consent settings, and the treatment of cookiewalls. No adoption timeline has been confirmed. The Directive therefore remains the operative instrument, and compliance must be built against national transpositions, not the proposed Regulation.
Product teams should not design consent architecture around the Regulation's proposed provisions. The EDPB has been explicit that Guidelines 2/2023 were published precisely because the Directive remains in force and fingerprinting enforcement cannot wait for a Regulation that may not arrive for years.
How Benny the Doorman fits into an ePrivacy-aware deployment
Benny is a fingerprinting SDK, not a consent management platform. The correct architecture for ePrivacy compliance is to gate the Benny API call behind your CMP's consent signal. The fingerprint script must not execute until the user has actively accepted a purpose category that covers device fingerprinting, not merely closed a banner or scrolled past a notice.
For use cases you believe qualify under the strictly-necessary carve-out, such as anti-fraud at login, the integration can proceed without a consent gate. This requires three documented safeguards: a written legitimate-interest assessment under GDPR Article 6(1)(f), a separate processing record in your ROPA that covers only the fraud purpose, and transparent disclosure in your privacy notice. The fraud-purpose data flow must be architecturally isolated from any analytics or marketing pipeline, or the carve-out does not apply.
Benny's fingerprint computation runs client-side and returns a hardware ID; no raw device signals are transmitted to Benny's infrastructure. EU controllers should still review the DPA available on request to confirm that the processing arrangement satisfies their obligations under GDPR Chapter V for any cross-border data flows.
Frequently asked questions
What is Article 5(3) of the ePrivacy Directive and why does it apply to fingerprinting?
Article 5(3) of Directive 2002/58/EC prohibits storing or accessing information on a user's terminal equipment without prior consent. Article 29 Working Party Opinion 9/2014 was the first regulatory document to name fingerprinting explicitly, concluding that reading device characteristics constitutes accessing stored information. EDPB Guidelines 2/2023 confirmed this, making the consent requirement unambiguous.
Is the ePrivacy Directive the same as the cookie law?
Yes. The ePrivacy Directive (Directive 2002/58/EC, particularly as amended by Directive 2009/136/EC in 2011) is the legal instrument that introduced the cookie consent requirement in the EU. It applies equally to any other technology that reads information from a user's device, including browser fingerprinting, which regulators have confirmed falls within its scope.
Does the strictly-necessary exception cover anti-fraud fingerprinting?
It can, if the fingerprint is used solely to detect fraud or abuse, is not repurposed for analytics or marketing, has a short retention period tied to the fraud-detection lifecycle, and is documented with a legitimate-interest assessment. The EDPB and national DPAs read 'strictly necessary' narrowly: if the same fingerprint feeds any other purpose, the carve-out does not apply to the whole pipeline.
Do penalties under the ePrivacy Directive differ from GDPR fines?
Yes. Because the Directive is transposed nationally, each member state sets its own penalty regime. There is no single EU-wide ceiling comparable to GDPR's EUR 20M or 4% of turnover rule. France, under Article 82, can impose fines up to EUR 3M per violation (with repeated infractions treated separately). German TTDSG penalties reach up to EUR 300k. Crucially, an ePrivacy violation and a GDPR violation can both be sanctioned for the same fingerprinting deployment, so total exposure can exceed either cap alone.
Does the ePrivacy Directive apply if my company is based outside the EU?
In practice, yes. The Directive is transposed into the national law of each member state, and most national DPAs apply the same extraterritorial logic as GDPR Article 3(2): if you fingerprint EU users visiting your service, you are within scope regardless of where your servers or your company are located. The CNIL's actions against US-based Google and Facebook under Article 82 establish the enforcement precedent.
What happened to the ePrivacy Regulation that was proposed in 2017?
The proposed Regulation is still stalled as of 2026. Negotiations have repeatedly broken down over contested issues including the scope of legitimate interest for tracking and browser-level consent mechanisms. The Directive remains operative. Compliance architecture should be built against the Directive and national transpositions, not against the draft Regulation's provisions.
How does the ePrivacy Directive relate to GDPR for a fingerprinting deployment?
They apply in sequence. Article 5(3) of the ePrivacy Directive governs the act of reading device signals: you need consent or a strictly-necessary justification before the fingerprint is built. GDPR Article 6 then governs the lawful basis for processing the resulting personal data. Both layers must be satisfied, but the ePrivacy layer is lex specialis and is addressed first.
Does a generic cookie banner cover fingerprinting consent?
Only if it explicitly names device fingerprinting as a distinct consent purpose, presents the rejection option as prominently as acceptance, and fires the fingerprint script only after the user affirmatively consents. A generic 'Accept all cookies' flow does not cover fingerprinting under the specific and informed requirements of Article 5(3) or the EDPB's cookie banner guidance.
Tooling
Benny the Doorman is built for this compliance posture.
Free, cookieless fingerprinting that defers to your consent management platform, runs on Indian infrastructure, and ships with a DPA addendum sized for the jurisdiction above.
Last reviewed 2026-06-06
