Artifact GuideEU

EU ePrivacy Directive Article 5(3) terminal equipment test

This test applies when a website, app, SDK, tag, connected device, email pixel, or analytics script stores information on a user's device or reads information already there.

Based on Article 5(3), EDPB technical-scope guidance, consent guidance, the cookie-banner taskforce report, and WP29 exemption analysis.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

Apply the operation by operation. Identify the information, the subscriber's or user's , the public communications-network context, and whether the operation stores information or gains access to information already stored. Cookies, local storage, SDK identifiers, tracking pixels, URL identifiers, browser APIs, device sensor outputs, and IoT reporting can qualify, but a technology name alone does not decide the result.

Section 1

Run the Article 5(3) trigger test

Start with the operation, not the label used by the vendor. The final EDPB Guidelines 2/2023 identify three key elements: information, of a subscriber or user (including its public communications-network context), and storage or gaining access. Storage and access are separate triggers, so the same assessment should catch both writing an identifier and reading a value that another party, the user, the device maker, or software already placed on the device.

Information is not limited to personal data. The test should therefore cover analytics IDs, advertising IDs, cached values, HTTP headers used for tracking, ETags, HSTS abuse, authentication tokens, device sensor results, and values generated locally by scripts or apps. For IP-only tracking, document how the address or other value originates from and is made available by the ; the mere receipt of an IP address should not be replaced with a blanket conclusion detached from the EDPB's technical scenario.

  • Identify every write operation: cookies, local storage, session storage, SDK storage, cache entries, tracking links, tracking pixels, and client-generated identifiers.
  • Identify every read operation: cookie reads, browser or OS API calls, device identifiers, private files, sensor outputs, contact or location APIs, and locally generated profile or fingerprint values.
  • Record whether client-side code, an SDK, email HTML, a tag manager, a browser API call, or an IoT instruction causes the device to send the value back over a network.
  • Treat the Article 5(3) test as technical-scope analysis first; later personal-data processing may also need a GDPR assessment.
Section 2

Classify pixels, URLs, local identifiers, APIs, and IoT flows

Tracking pixels and tracked URLs are in scope when they are distributed over a public communications network and instruct the user's client to request a resource or send an identifier. The same logic applies when JavaScript or app code dynamically constructs a pixel or URL identifier.

Local processing does not determine Article 5(3) scope by itself. Assess any instructed storage separately, even if the information never leaves the device. When processed information or a derived value is sent back through a communications network, the access trigger can also apply. For IoT, map direct reporting and mediated reporting through a relay because the relay can act as when it stores and sends the data onward.

  • For web tags and email pixels, save the HTML or script, the requested resource URL, the identifier parameters, and the purpose assigned by the tag owner.
  • For local identifiers, document whether the value comes from user input, device manufacturing, an OS or browser API, a sensor, cached storage, or client-side code.
  • For SDKs and app APIs, list each permission, local value, derived value, endpoint, recipient, and purpose before deciding whether consent or an exception is available.
  • For IoT products, separate direct device-to-server reporting from phone, hub, or gateway relay reporting, then test the onward network instruction separately.
Section 3

Test the two Article 5(3) exceptions narrowly

Consent is not required only where the storage or access is for the sole purpose of carrying out or facilitating transmission over an electronic communications network, or where it is strictly necessary to provide an information society service explicitly requested by the subscriber or user. WP29 Opinion 04/2012 treats the second exception as a high test: the user must have requested a clearly defined functionality, and that functionality must fail without the storage or access.

Purpose and implementation control the answer. A first-party session cookie for a shopping basket, authentication during a logged-in session, user-centric login security, multimedia playback during a session, load balancing, or a short-lived user-interface preference may qualify when the conditions described in WP29 Opinion 04/2012 are met. These are examples, not categorical exemptions. Behavioural advertising, cross-site tracking, social plug-in tracking, most third-party advertising operations, and analytics are not strictly necessary merely because the operator wants measurement or monetisation.

  • For the transmission exception, prove the value is solely needed to carry the communication, such as routing, session continuity, packet ordering, error detection, or load balancing.
  • For the explicitly requested service exception, name the specific user-requested functionality and show that it will not work if the storage or access is disabled.
  • Split multipurpose cookies or identifiers; an exempt purpose does not make a tracking, advertising, profiling, or analytics purpose exempt.
  • Set lifespan and scope to the purpose: session or short-lived values are easier to justify than persistent or third-party values, but purpose remains decisive.
Section 5

Evidence record for the terminal equipment decision

The evidence record should let a reviewer reproduce the Article 5(3) classification without relying on memory. For each technology, store the observed technical behaviour, purpose, recipient, legal classification, consent or exception basis, and test result.

Do not collapse the ePrivacy and GDPR records. The ePrivacy record should answer whether storage or access is allowed and on what basis. A separate processing record can then address any subsequent personal-data processing, including controller roles, lawful basis, transparency, retention, and data-subject rights.

Does Article 5(3) apply only to cookies?

No. EDPB Guidelines 2/2023 say Article 5(3) covers storage of, or access to, information in and is not limited to cookies. The same test can cover pixels, tracked URLs, local storage, SDK identifiers, device API reads, IoT reporting, and locally generated values sent back over a network.

Can analytics be treated as strictly necessary under Article 5(3)?

WP29 Opinion 04/2012 says first-party analytics cookies are not strictly necessary to provide a functionality explicitly requested by the user, even though they may present lower risk when limited to first-party aggregated statistics with safeguards. Treat analytics as requiring consent unless a specific cited exception is available.

What proof should teams keep for an Article 5(3) exception?

Keep the technical trace, the user-requested functionality, why the storage or access is solely for transmission or strictly necessary for that functionality, the lifespan and purpose limits, source citations, owner approval, and retest evidence showing non-exempt purposes do not run under the same identifier.

  • Inventory entry: technology name, owner, domain or package, storage location, value type, lifespan, first-party or third-party status, and public-network endpoint.
  • Scope analysis: information type, involved, storage/access event, instruction source, recipient, and whether the value leaves the device.
  • Basis decision: consent required, transmission exception, strictly necessary service exception, or blocked pending redesign, with source citation and reviewer approval.
  • Validation pack: network capture, cookie/local-storage export, consent-banner screenshots, reject-all trace, tag firing report, vendor documentation, and change history.
  • Review triggers: new tag, new SDK, new pixel, new API permission, new connected-device reporting path, new purpose, new vendor, new country launch, or banner redesign.
Primary sources

References and citations

edpb.europa.eu4 citations
Referenced sections
  • Primary technical-scope guidance for storage/access, pixels, URLs, local processing, IP-origin scenarios, IoT reporting, and unique identifiers.
  • Defines the technical-scope elements for Article 5(3) and confirms that cookies are only one example of covered storage or access technologies.
  • Applies Article 5(3) to URL and pixel tracking, local processing sent back over a network, IP-origin scenarios, IoT reporting, and unique identifier collection.
Show 1 more
  • Supports the technical evidence categories for storage, access, local processing, network return, IoT, and unique identifiers.
"technical scope"
More quoted passages
"three key elements"
"URL and pixel tracking"
"gaining of access"
eur-lex.europa.eu3 citations
Referenced sections
  • Binding Article 5(3) text for terminal-equipment storage/access and the two consent exceptions.
  • Article 5(3) sets the rule for storing information or gaining access to information stored in terminal equipment, subject to the transmission and strictly necessary service exceptions.
  • Article 5(3) contains the transmission and strictly necessary service exceptions.
"terminal equipment"
More quoted passages
"storing of information, or the gaining of access"
"strictly necessary"
edpb.europa.eu3 citations
Referenced sections
  • Cookie-banner enforcement coordination source for reject options, pre-ticked boxes, misleading design, essential-cookie classification, and withdrawal access.
  • Documents common cookie-banner assessment positions, including reject options, pre-ticked boxes, misleading design, essential-cookie classification, and withdrawal access.
  • Supports maintaining cookie lists, essentiality documentation, and consent/withdrawal testing records for regulator-facing review.
"no cookies which require consent"
More quoted passages
"Cookie Banner Taskforce"
"demonstrate the essentiality"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Historical Commission material about the proposed modernization of the broader EU online-privacy framework.
  • Historical Commission material about the proposed modernization of the EU online-privacy framework for digital communications and tracking technologies.
"future proof legal framework"
More quoted passages
"online privacy"
edpb.europa.eu2 citations
Referenced sections
  • Consent standard used when Article 5(3) requires consent for non-exempt storage or access.
  • Explains valid consent, consent demonstration, and withdrawal requirements used when Article 5(3) requires consent.
"freely given, specific, informed and unambiguous"
More quoted passages
"clear affirmative action"
ec.europa.eu2 citations
Referenced sections
  • Detailed analysis of Article 5(3) transmission and strictly necessary service exceptions.
  • Explains the transmission and explicitly requested service criteria and applies them to user-input, authentication, security, media, load-balancing, preference, social plug-in, advertising, and analytics cookies.
"Cookie Consent Exemption"
More quoted passages
"explicitly requested by the user"
Show all related guides (32)

EU ePrivacy consent-log evidence workflow for cookies and trackers

Build evidence that links each cookie or tracker decision to the banner shown, the user's signal, the live technical behavior, withdrawal, and later changes.

EU ePrivacy cookie banner UX test cases

Source-backed cookie banner UX tests for Article 5(3) ePrivacy consent: reject all, pre-ticked boxes, withdrawal, cookie walls, analytics toggles, and consent evidence.

EU ePrivacy Cookie Scope Classifier Workflow

Decide whether cookies, pixels, SDKs, local storage, identifiers, and analytics fall within Article 5(3), then document consent, an exemption, or escalation.

EU ePrivacy direct-marketing consent checklist

Checklist for ePrivacy Directive direct-marketing messages: consent, soft opt-in, sender identity, opt-out handling, proof records, suppression, and national-law caveats.

EU ePrivacy Directive compliance calendar for cookies, consent, and marketing

Source-backed ePrivacy calendar covering Directive milestones, Article 5(3) cookie reviews, consent evidence, direct marketing checks, and national-law follow-up.

EU ePrivacy Directive Compliance Checklist

A concrete ePrivacy checklist for terminal equipment access, cookie consent, exemptions, banner UX, direct marketing, confidentiality, GDPR interplay, and evidence records.

EU ePrivacy Directive Compliance Guide for Cookies, Marketing, and Communications

Practical ePrivacy Directive compliance checks for terminal equipment, communications confidentiality, cookie consent, exemptions, direct marketing, evidence, and national-law caveats.

EU ePrivacy Directive Cookies and Consent: Article 5(3), exemptions, and banner evidence

Cookie consent guide for the EU ePrivacy Directive: Article 5(3) scope, strictly necessary and transmission exemptions, consent UX, withdrawal, logs, analytics caveats, and GDPR interplay.

EU ePrivacy Directive direct marketing rules for electronic mail

Source-backed guide to Article 13 ePrivacy Directive rules for electronic mail marketing, prior consent, customer soft opt-in, opt-out handling, sender identity, and Member State caveats.

EU ePrivacy Directive Enforcement and Fines

Source-backed guide to ePrivacy Directive enforcement, national penalties, competent authorities, GDPR interplay, cookie-banner risk, and evidence limits.

EU ePrivacy Directive FAQ: cookies, consent, marketing, GDPR interplay

Answers to recurring EU ePrivacy Directive questions on Article 5(3), terminal-equipment access, cookie consent, exemptions, analytics, direct marketing, GDPR interplay, national enforcement, and evidence.

EU ePrivacy Directive Member State Cookie Rules

How to evidence EU ePrivacy cookie compliance when Article 5(3) is implemented through Member State law and national authority practice.

EU ePrivacy Directive Metadata and Location Data Guide

Source-backed guide to EU ePrivacy Directive rules for traffic data, location data, anonymisation, consent, value-added services, Article 5(3) overlap, and national-law limits.

EU ePrivacy Directive penalties and fines: national enforcement caveats

Source-backed guide to ePrivacy Directive penalty exposure, national transposition caveats, cookie enforcement evidence, consent defects, and GDPR overlap limits.

EU ePrivacy Directive Requirements: cookies, communications and marketing

Source-backed map of EU ePrivacy Directive requirements for communications confidentiality, terminal-equipment access, consent, traffic and location data, and direct marketing.

EU ePrivacy Directive vs GDPR: cookies, communications, marketing, and evidence

Compare the EU ePrivacy Directive and GDPR by trigger, consent standard, lex specialis overlap, enforcement caveats, and evidence outputs for cookies, device access, communications, and marketing.

EU ePrivacy Directive vs UK PECR: cookies and direct marketing

Compare the EU ePrivacy Directive with current UK PECR rules for device storage and access, statutory exceptions, consent, electronic-mail marketing, soft opt-ins, and enforcement.

EU ePrivacy soft opt-in marketing checklist

Source-backed checklist for using the EU ePrivacy Directive soft opt-in exception for customer email marketing, opt-outs, sender identity, suppression records, and national-law caveats.

EU ePrivacy soft opt-in marketing review workflow

Decide whether an electronic-mail marketing audience meets every Article 13 soft opt-in condition, or must be suppressed or supported by valid prior consent.

EU ePrivacy Strictly Necessary Cookie Exemptions

Source-backed guide to the Article 5(3) ePrivacy exemptions for transmission cookies, requested-service cookies, analytics caveats, evidence, and national-law checks.

Are cookie walls allowed under the EU ePrivacy Directive?

FAQ answer on cookie walls under the EU ePrivacy Directive, covering freely given consent, refusal and withdrawal paths, banner evidence, and national-law caveats.

Do Analytics Cookies Require Consent under the EU ePrivacy Directive?

FAQ answer on analytics cookies under Article 5(3) ePrivacy, limited analytics exemptions, configuration evidence, consent logs, and national-law caveats.

EU ePrivacy soft opt-in FAQ for email marketing

When Article 13(2) soft opt-in can support EU customer email marketing, including existing-customer, similar-offer, opt-out, sender-identity, suppression-list, and national-law checks.

Is a reject-all button required for EU ePrivacy cookie consent?

Standalone FAQ answer on EU ePrivacy reject-all and refuse options for cookie banners, including equal prominence, deceptive UX, consent evidence, withdrawal, and national-law caveats.

Strictly Necessary Cookies under the EU ePrivacy Directive

FAQ answer on when EU ePrivacy Article 5(3) allows cookies without consent, with cited examples, analytics caveats, evidence records, and national-law cautions.

What should CMP consent logs retain under the EU ePrivacy Directive?

FAQ answer on CMP consent logs for EU ePrivacy cookie consent: retained fields, consent validity signals, banner versioning, refusal and withdrawal events, proof limits, and national-law caveats.