Back to blog
-- 11 min read

ePrivacy Article 5(3) explained: when do you need consent for analytics?

A detailed breakdown of ePrivacy Directive Article 5(3), the 'cookie law' that determines when analytics requires consent. What it says, what it means, and how different EU authorities interpret it.

What is the ePrivacy Directive?

Most people in the web analytics world talk about the GDPR as if it were the only relevant law for tracking visitors. It is not. The rule that actually decides whether you need a cookie consent banner is older than the GDPR and lives in a separate piece of legislation: the ePrivacy Directive, formally Directive 2002/58/EC, as amended by Directive 2009/136/EC.

The ePrivacy Directive regulates privacy in the electronic communications sector. Among other things, it governs the confidentiality of communications, traffic data retention, unsolicited commercial communication (spam), and — most famously — the placing and reading of information on end users' devices. That last topic is covered by Article 5(3), which is the legal source of the "cookie banner" you see on almost every website in the EU.

Because the ePrivacy Directive is a directive rather than a regulation, each EU member state implements it in national law. In France it lives in the Loi Informatique et Libertés via article 82. In Germany it is now §25 TTDSG / TDDDG. In Denmark it is the cookie bekendtgørelse. In the UK (post-Brexit) it remains in force as PECR. The underlying text is harmonised, so the analysis below applies broadly across the EU even if the exact statutory citation differs.

The full text of Article 5(3)

Here is the operative provision in full. It is worth reading slowly:

"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."

Three phrases do almost all the work in this paragraph: "storing of information, or the gaining of access," "terminal equipment of a subscriber or user," and "strictly necessary." Everything else is scaffolding. Let's take them one at a time.

The "storing or accessing information" trigger

Article 5(3) is technology-neutral. It does not say "cookies." It says "storing of information" or "gaining of access to information already stored." That phrasing is deliberately broad and covers any technique that writes data to or reads data from the user's device.

In practice this includes:

  • HTTP cookies, whether first-party or third-party
  • localStorage, sessionStorage, and IndexedDB
  • The Cache API and Service Workers
  • ETags, Last-Modified headers, and other HTTP cache tricks
  • HTTP/2 Server Push state, HSTS pinning
  • Canvas, WebGL, audio, and font fingerprinting (which technically reads information from the device)
  • Reading the user's installed fonts, plugins, or hardware capabilities
  • Reading the contents of the clipboard, battery status, or other device APIs

Notice that the trigger applies regardless of whether the stored or accessed information is personal data. Even an opaque, non-identifying token counts. And it applies regardless of whether the site actively reads the information back — merely storing is enough.

This also means the "it's not a cookie, it's localStorage" argument that some analytics vendors used to make is a non-starter. The law has never been about cookies specifically; it has always been about any form of storage or access on the user's device.

The "terminal equipment" element

"Terminal equipment" means the device the user is using to access the internet: phone, laptop, tablet, smart TV, console, anything. The directive draws a clear line between the network (servers, routers, the wire) and the endpoint (the user's device).

This distinction is the single most important concept for cookieless analytics. Anything that happens entirely on the server side of that line is outside Article 5(3). Anything that touches the user's device is inside it. There is no middle ground.

Server logs, hashed identifiers computed on the server, request headers parsed and discarded, geographic lookups based on IP address — none of these are "storing information on terminal equipment" or "gaining access to information already stored" on the device. They are things the server already has by virtue of receiving the HTTP request.

Cookies, localStorage, fingerprinting, device API reads — all of these cross the line into the device. They are all in scope.

The "strictly necessary" exemption

Article 5(3) contains an exemption for storage or access that is "strictly necessary" for either of two purposes:

  1. Transmitting a communication over an electronic communications network — this covers things like routing, load balancing, and TCP-level state.
  2. Providing an "information society service explicitly requested by the subscriber or user."

The second branch is the one that matters for web operators. Examples commonly accepted as "strictly necessary" include:

  • The session cookie that keeps you logged in after you actively log in
  • The cookie that stores the items in your shopping cart during checkout
  • The cookie that remembers your cookie consent choice itself (a circular but pragmatic exemption)
  • CSRF tokens that protect against cross-site request forgery
  • Load balancer stickiness cookies

Examples that are not "strictly necessary":

  • Analytics cookies, because the user did not request to be measured
  • Advertising cookies, because the user did not request to see targeted ads
  • Preference cookies for things the site can deliver without them

The test is not "is this useful to the site operator?" but "is this necessary for a service the user explicitly asked for?" Analytics fails that test on any honest reading, because visitors almost never ask to be measured.

How Data Protection Authorities interpret "strictly necessary"

The European Data Protection Board (EDPB) and individual national authorities have consistently applied a narrow reading of "strictly necessary." The authority reading that matters most in practice:

  • CNIL (France) has published detailed guidance recognising a limited "audience measurement exemption" for analytics that meets specific conditions: strictly first-party, no cross-site tracking, limited purposes, limited retention, and no sharing with third parties. Tools that meet all conditions can be deployed without a consent banner. Tools that don't, can't.
  • DSK (Germany) takes a stricter line: any analytics that stores anything on the device requires consent. Cookieless analytics that store nothing on the device are simply outside the scope of §25 TTDSG and therefore outside the consent requirement.
  • Datatilsynet (Denmark) follows the directive faithfully: the cookie rules apply to anything that stores or reads information on the device. If nothing is stored or read, the rules are not engaged at all.
  • ICO (UK) explicitly confirms in its PECR guidance that first-party analytics may qualify for exemption in limited circumstances, but the safer path is to rely on consent or on an architecture that does not involve storage at all.

Despite some tonal differences, every DPA in the EU agrees on the same legal mechanism: if you store nothing on the device, Article 5(3) is not triggered, and the consent requirement does not apply to the analytics itself.

The CNIL audience measurement exemption

CNIL's position deserves a closer look because it is the most permissive and the most explicit in Europe. Under its guidelines, analytics cookies and trackers may be exempt from consent if all of the following conditions are met:

  • The processing is strictly limited to producing anonymous statistical data
  • The data is used exclusively by the publisher or its processor
  • The data is not cross-referenced with other processing or shared with third parties
  • The tracker is limited to producing aggregated statistics
  • IP addresses are not kept beyond what is strictly necessary (typically anonymised by truncation before retention)
  • Tracking is strictly limited to a single website
  • Retention of the data does not exceed a reasonable period (CNIL has previously indicated 13 months for cookies and 25 months for the underlying statistical data)

CNIL maintains a list of analytics solutions it has reviewed and considers exempt in their default configuration. The list is not binding on other DPAs, but it is widely referenced across Europe as a practical guide.

An analytics tool that never stores anything on the device at all sits above this exemption. It does not need to qualify for the exemption because it is not engaging the consent trigger in the first place.

The relationship to the GDPR

People often conflate ePrivacy and GDPR, but they answer different questions:

  • ePrivacy Article 5(3): "Am I allowed to put data on the user's device or read data from it?" If no storage or access, not engaged.
  • GDPR Article 6: "Do I have a lawful basis for processing personal data?" Applies whenever personal data is processed, including by analytics tools that store nothing on the device but still process IP addresses.

Both must be satisfied. An analytics tool that stores nothing on the device gets past ePrivacy for free, but it still needs a GDPR legal basis for whatever personal data it processes server-side. For analytics that legal basis is typically legitimate interest under Article 6(1)(f), supported by a documented legitimate interest assessment that shows the processing is proportionate and respects the visitor's rights.

You cannot skip the GDPR analysis by being cookieless. You can skip the consent banner under ePrivacy, but you still need to document your GDPR compliance and to respect data subject rights.

What this means for analytics providers

There are three realistic architectural paths for an analytics product that wants to operate legally in the EU:

  1. Use cookies and show a banner. This is the path Google Analytics, Matomo (default mode), and most legacy tools take. The user sees a consent prompt. If they accept, you get data. If they decline (or close the banner), you get nothing.
  2. Use cookies but qualify for the CNIL-style measurement exemption. Matomo in its cookieless-but-still-fingerprinted mode tries this. It is workable but depends on precise configuration and on DPA interpretation.
  3. Don't touch the device at all. This is the path Web-Tracking.eu, Plausible, Fathom, Simple Analytics, and Pirsch have taken, each with their own implementation details. Article 5(3) is simply not triggered, and the consent question evaporates for the analytics layer.

The third path is the cleanest legally and the simplest operationally. It does require rethinking how you count unique visitors — you cannot rely on an identifier stored on the device, so you have to compute one on the server — but it sidesteps the entire cookie banner debate.

Examples: what does and does not trigger consent

To make this concrete, here are some deployment patterns and how they interact with Article 5(3):

  • A tracking script that sets a first-party _ga cookie — triggers Article 5(3), needs consent.
  • A tracking script that writes a visitor ID to localStorage — triggers Article 5(3), needs consent.
  • A tracking script that only reads the User-Agent header and sends a ping to the server — does not trigger Article 5(3). The User-Agent is in the HTTP request, not on the device. No storage, no access beyond normal network transmission.
  • A server that hashes IP + User-Agent + date on receipt and stores only the hash — does not trigger Article 5(3). Nothing is stored on the device.
  • A tracking script that uses Canvas fingerprinting to generate a visitor ID — triggers Article 5(3), because it reads information from the device (rendering characteristics).
  • A tracking script that uses navigator.sendBeacon() to send request data to the server — does not in itself trigger Article 5(3). sendBeacon is a transport mechanism, not device storage.
  • A tracking script that sets an ETag and reads it back to identify returning visitors — triggers Article 5(3). ETags are a form of storage on the device.
  • A CDN logging request headers on incoming traffic — does not trigger Article 5(3). Logs are on the server.

If your architecture fits cleanly into the "server-side only" category, you do not need a cookie banner for the analytics portion of your site. Your other third-party tools may still require one.

The bottom line

Article 5(3) is a clean, technology-neutral rule: if you store information on a user's device or read information from it, you need consent (unless it is strictly necessary for a service the user explicitly requested). If you don't, you don't.

That rule was written in 2002 and amended in 2009. It has survived the GDPR, the death of third-party cookies, the rise of fingerprinting, and the ongoing cookie banner fatigue debate, because its underlying logic is sound. The cleanest way to comply with Article 5(3) in 2026 is not to comply with it at all — by building a product that never triggers it in the first place.

Web-Tracking.eu is a cookieless analytics platform. Learn more about our approach on the no cookie banner legal explainer.