EU ePrivacy Directive Article 5(3) terminal equipment test

Start with the operation, not the label used by the vendor. EDPB Guidelines 2/2023 identify four Article 5(3) elements: information, terminal equipment of a subscriber or user, a public electronic 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 terminal equipment; the mere receipt of an IP address should not be replaced with a blanket conclusion detached from the EDPB's technical scenario.

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 is not automatically outside Article 5(3). If information stays strictly inside the device, the EDPB says Article 5(3) does not apply on that basis; when the information or a derived value is sent back through a communications network, the access trigger may apply. For IoT, direct reporting from a connected device and mediated reporting through a relay device must both be mapped because the relay can become the terminal equipment that stores and sends the data onward.

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.

Where no Article 5(3) exception applies, storage or access should wait for valid consent. EDPB consent guidance ties ePrivacy consent to the GDPR standard: freely given, specific, informed, unambiguous, and expressed through a clear affirmative action. Consent records should show the version of the notice, the purposes, the user action, and the time of the signal without collecting more proof data than needed.

The EDPB cookie-banner taskforce report is useful for testing common failure patterns. By default, cookies that require consent should not be set before consent. Pre-ticked boxes do not produce valid consent. Banner designs that hide refusal, make refusal look unavailable, push users toward accept, use confusing legitimate-interest layers for read/write operations, or make withdrawal harder than giving consent create evidence and enforcement risk.

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.