Key takeaways

The ePrivacy Directive is an EU directive on privacy in electronic communications. For website owners, its best-known rule is Article 5(3): before storing information on, or accessing information from, a visitor's device, information and consent are generally required unless the operation is solely for transmitting a communication over an electronic communications network, or is strictly necessary to provide a service the visitor explicitly requested.

Updated: 29 August 2026 · Last reviewed: 29 August 2026

That rule is broader than cookies. Depending on how they work, local storage, device fingerprinting, tracking pixels, SDK identifiers, and similar techniques can raise the same device-access question. GDPR is separate but often applies at the same time when personal data is processed. In simple terms: national ePrivacy rules usually answer whether a non-essential device operation may happen; GDPR helps determine what valid consent and accountable personal-data processing look like.

The Directive was implemented through each EU country's law. There is no single, identical national cookie rule or enforcement route across the EU. Start with the shared Article 5(3) framework, then check the national law and regulator guidance for the countries relevant to your visitors and service.

Device access and personal-data processing: two layers

Layer 1 · Device storage or access

Article 5(3) framework

Start with information stored on, or accessed from, terminal equipment. The rule is technology-neutral: cookies, browser storage, identifiers, pixels, and similar techniques can require a fact-specific review.

Concept A · transmission

Storage or access solely for carrying a communication over an electronic communications network.

Concept B · requested service

Storage or access strictly necessary to provide an information-society service explicitly requested by the user.

May lead to a separate processing review

Layer 2 · Subsequent personal-data processing

GDPR, where applicable

Where the subsequent activity involves personal data, assess its lawful basis and the applicable transparency, rights, security, retention, and accountability duties. This layer can apply alongside the device-access rule rather than replacing it.

National-law caveat: the ePrivacy Directive is implemented through national law. Country-specific rules, competent authorities, guidance, and any carefully verified national exemption matter to the assessment.

Illustrative legal-framework diagram for orientation. It is not a compliance verdict and does not determine whether a particular technology fits an exception or national exemption.

Directive 2002/58/EC, commonly called the ePrivacy Directive, concerns the processing of personal data and the protection of privacy in electronic communications. It was amended, including by Directive 2009/136/EC. It covers more than website tracking: its subject matter includes confidentiality of communications, traffic data, unsolicited communications, and public directories.

For most small-business websites, Article 5(3) is the practical starting point. It requires Member States to ensure that storing information, or gaining access to information already stored, in the terminal equipment of a subscriber or user is allowed only if the user has received clear and comprehensive information and has given consent. It has two independent exceptions: where the operation is solely for carrying out the transmission of a communication over an electronic communications network, or where it is strictly necessary to provide an information-society service explicitly requested by the subscriber or user.

“Terminal equipment” is the legal term that captures the visitor's phone, laptop, tablet, or similar device. A cookie banner is not triggered merely because a website collects personal data. It is commonly used where a site relies on consent for non-essential cookies or similar device operations; the required approach depends on the applicable national law and the technology's purpose.

The wording is intentionally technology-neutral. Replacing a cookie with another browser-storage method does not automatically remove the Article 5(3) question.

This article is general information, not legal advice. The applicable national implementation, the service offered, and the exact technical behaviour all matter.

Article 5(3) in plain English

Article 5(3) has two triggers:

  1. Storing information on the visitor's device; or
  2. Accessing information already stored on that device.

If either trigger applies, the normal route is prior information and consent. The two narrow alternatives are that the operation is solely for carrying out transmission of a communication over an electronic communications network, or that it is strictly necessary for an information-society service the visitor explicitly requested.

The important operational word is before. If an advertising, analytics, or social-media technology stores or accesses device information when a page opens, showing a banner after it has run may not address the timing issue. A practical technical explanation is available in our guide to blocking cookies before consent.

Article 5(3) does not say that every file, network request, or technical event has the same legal outcome. It sets the framework. A careful assessment asks:

  • What information is stored or accessed?
  • Is the information in the user's terminal equipment?
  • What is the purpose of the operation?
  • Is it genuinely necessary for a service the visitor explicitly asked for?
  • Which national implementation and guidance apply?
  • Does the later processing involve personal data under GDPR?

This is why calling every browser technology “a cookie” can be misleading. It is better to inventory the behaviour and purpose, then assess it.

It covers more than cookies

Cookies are small pieces of data that a website can ask a browser to retain and send back. They remain a common way to recognise a browser, retain a session, measure visits, or support advertising. But Article 5(3) is not limited to the word “cookie.”

Browser storage in modern websites

Single-page applications and progressive web apps may use browser storage rather than, or alongside, ordinary cookies:

  • localStorage can retain values between browser sessions;
  • sessionStorage retains values for a browsing session;
  • IndexedDB can hold larger structured data sets; and
  • Cache Storage and service-worker features can retain resources for offline or performance purposes.

The presence of one of these technologies is not enough to decide whether consent is needed. A cache used to deliver a page feature a visitor chose may be assessed differently from a persistent identifier used to recognise that visitor for marketing. The point is that “we do not use cookies” is not a complete answer.

Pixels, tags, and embedded services

A tracking pixel is often a tiny image or script that causes a request to a third party. The pixel itself may be only one part of a flow that reads identifiers, sets cookies, or links a browser to other information. Tag-manager containers can also publish multiple services, each with different behaviour.

Video players, maps, chat tools, social widgets, A/B-testing services, and session-recording tools deserve the same pre-launch review. An embedded service can make third-party requests before the visitor interacts with it. Whether an exemption applies depends on the actual function and the national legal context, not the vendor's category label.

Fingerprinting and device signals

Fingerprinting can combine characteristics exposed by a device or browser—such as screen properties, language settings, rendering behaviour, or configuration—to distinguish it from others. EU data-protection guidance has treated device fingerprinting as relevant to the Article 5(3) framework. It should not be assumed that avoiding stored cookies avoids the rule.

For a small team, the practical lesson is straightforward: list all scripts, plugins, embeds, and storage mechanisms, not just the cookies displayed in a browser menu. A cookie and tracker scan can help identify items to investigate, but its results are diagnostic. They cannot decide whether a particular use is legally exempt or confirm legal compliance.

ePrivacy Directive vs GDPR: how the two layers work

The ePrivacy Directive and GDPR are different instruments. They frequently apply to the same website journey, but they do different jobs.

Question ePrivacy framework, implemented nationally GDPR
What is the central concern? Privacy of electronic communications and device storage/access Processing of personal data
Website example May the site place or read a non-essential identifier on a device? May the organisation process identifiable data generated by that identifier?
Main rule for non-essential device access Consent is generally required, subject to the limited Article 5(3) exception and national law A lawful basis, transparency, rights, security, and accountability duties may apply
What makes consent valid? Article 5(3)'s reference to Directive 95/46/EC is read as a reference to GDPR under GDPR Article 94(2) Consent must be freely given, specific, informed, and unambiguous; Article 7 adds conditions
Who enforces it? Authorities and routes set by national implementation Data-protection supervisory authorities under GDPR, subject to its mechanisms

The EU's data-protection framework describes the ePrivacy rules as lex specialis for matters specifically regulated there. That does not mean GDPR disappears. Where personal data are processed, GDPR can still govern the processing that follows and the standard of consent.

Why “legitimate interests” is not a shortcut for trackers

GDPR recognises several lawful bases, including legitimate interests in certain circumstances. That does not itself open the Article 5(3) door to non-essential storage or access on a device. For that device operation, consent is generally the starting point unless one of Article 5(3)'s two exceptions applies under the applicable national rule.

After a valid device-access analysis, a business may still need to assess the GDPR basis and other GDPR duties for personal data processing. Do not collapse the two questions into one. Our simple GDPR guide explains the broader personal-data framework.

Where consent is the basis, it should be an active, informed choice. A banner's wording and buttons matter, but the site's actual behaviour matters too. A visitor who refuses non-essential tracking should not find that the relevant tags still run because of a plugin, hard-coded script, or embed.

National regulator guidance can be more specific about banner design and local expectations. Make acceptance and refusal understandable, give clear purpose information, and provide a usable way to revisit a decision. Avoid assuming that a design accepted in one market will settle the question in another.

The Article 5(3) exceptions: transmission and requested service

Article 5(3) has two separate exceptions. The first concerns storage or access that is solely for carrying out transmission of a communication over an electronic communications network. The second is often called the “strictly necessary” exemption. Its wording is narrower than “useful to the business” or “important to conversion”: the storage or access must be strictly necessary to provide an information-society service explicitly requested by the user.

Common examples that may be capable of fitting the exemption, subject to the facts and national guidance, include:

  • retaining a login session after the visitor signs in;
  • remembering items in a shopping basket during a requested purchase flow;
  • using security measures needed to protect a requested service;
  • balancing technical load to deliver the requested page; and
  • retaining the visitor's cookie preference so the site can honour it.

These are examples, not blanket approvals. Duration, purpose, data flow, and alternative technical designs may matter.

What usually needs closer scrutiny

Analytics, behavioural advertising, social-media marketing pixels, cross-site recognition, audience measurement, session replay, and experimentation tools are commonly non-essential to the service a visitor explicitly requested. A business may regard them as valuable, but value to the operator is not the Article 5(3) test.

There are nuanced national positions on some audience-measurement uses and other technologies. Do not generalise an exemption from one country's regulator to every EU market. If the question affects a core revenue flow, get advice tailored to the service and jurisdictions.

Why national implementation matters

An EU directive sets an objective that Member States implement through national law. Unlike an EU regulation, Directive 2002/58/EC does not itself create one uniform cookie rule that applies in exactly the same way in every Member State.

National laws, competent authorities, procedural rules, and guidance can differ. France, for example, has a national cookie rule in Article 82 of its Data Protection Act. Germany's rules include section 25 of the Telecommunications Digital Services Data Protection Act (TDDDG). Other countries use their own legislation and regulator guidance.

That does not mean a cross-border site has no shared baseline. Article 5(3), the GDPR consent standard, and EU-level guidance provide an important common framework. But a site owner should avoid statements such as “EU law always requires this exact button layout” without checking national sources.

Which country's rules should you consider?

Start with where you offer the service and where your visitors are located, as well as the national reach of the applicable law. A business established outside the EU should not assume that its location ends the analysis when it serves EU users. The facts of targeting, services, communications, and processing matter.

For planning, review country-specific information for markets you actively serve, such as Germany. For a wider overview, see our cookie consent guide by country. These resources are a starting point, not a substitute for jurisdiction-specific advice.

What happened to the proposed ePrivacy Regulation?

In January 2017, the European Commission proposed an ePrivacy Regulation intended to replace the Directive. A regulation would have applied directly across Member States, rather than requiring national transposition. Negotiations continued for years without a final adopted text.

The Commission's 2025 work programme listed the proposal among planned withdrawals, and the Commission withdrew it in February 2025. As of the review date for this article, the proposal identified as COM(2017) 10 is withdrawn. The withdrawal did not repeal Directive 2002/58/EC or the national laws that implement it.

The safe practical conclusion is not that cookie rules are about to vanish, nor that a replacement has been agreed. Continue to design and review against the current Directive-based and national framework. Treat announcements, rumours, or draft ideas about future “cookie banner” rules as proposals unless and until an official instrument is adopted and applicable.

A practical review for your website

You do not need to become a privacy lawyer to improve a website's starting position. You do need to understand what your site does before a visitor has made a choice.

1. Build a technology inventory

List every analytics tool, ad pixel, tag-manager tag, social widget, video, map, chat tool, testing tool, and plugin. Include first-party code and vendor-provided snippets. Identify cookies, but also local storage, IndexedDB, service workers, and device-recognition techniques where relevant.

Ask your developer or agency what each item does, which domains receive requests, and whether it can load before consent. Repeat this exercise after redesigns, campaign launches, or plugin changes.

2. Test before interacting with the banner

Use a fresh browser profile or private session. Visit key pages without clicking anything. Inspect storage and network activity, then test the refusal path and refresh. Repeat on mobile and on campaign pages that may use a different template.

This is a technical check, not a legal conclusion. It can show whether a claimed blocking rule is actually working. For a step-by-step approach, read how to audit website cookies.

3. Review the choice and information

Can a normal visitor understand what each optional category does? Is the way to refuse visible and usable? Does the detailed layer identify purposes and relevant third parties clearly enough to support an informed decision? Can visitors change their decision later?

Then compare the browser's behaviour to the choice made. A well-written banner cannot cure a tag that continues to load contrary to the recorded preference.

4. Keep a change process

Assign an owner for new marketing and embedded tools. Record the banner version, categories, vendors, technical tests, and changes made. If you rely on consent, establish how your team can retrieve evidence of the choice and the information shown at the time.

A small release checklist is often more realistic than a one-time “compliance project.” See cookie consent best practices for an implementation-oriented checklist.

Where ConsentEase can help

If you are unsure what your site loads, run the free scanner as an inventory step. It can help surface cookies, trackers, and potential pre-consent activity for your team to review. It does not provide a legal determination, account for every national rule, or guarantee compliance.

Once you understand your requirements, compare the available options on our pricing page. Whatever tool you choose, test the live site after installation and whenever its tags or templates change.

Sources