Your company is building a mobile app. Developers add a third-party software development kit (SDK), such as an analytics or attribution tool. That is where ePrivacy device access can become relevant.

The privacy review starts with the usual GDPR questions.

  • What personal data does the component collect?
  • What is our lawful basis?
  • Is anything transferred internationally?
  • What does the privacy notice need to say?

Each of those is a valid GDPR question. But there is an earlier question that is easy to miss:

What does that component read from, or write to, the user’s device?

ePrivacy device access and GDPR ask different questions

The clearest way to understand the difference is this:

  • GDPR asks: what are we doing with personal data?
  • Article 5(3): uses the broader concept of information and can apply even when no personal data is involved.

Those overlap, but they are not the same. Article 5(3) uses the broader concept of information, and can engage even where no personal data is involved at all.

That distinction matters for ePrivacy device access. If you start with the lawful basis, you may be starting in the middle of the analysis.

The device question comes first, not because ePrivacy outranks GDPR, but because Article 5(3) can apply whether or not the information is personal data.

Why ePrivacy device access goes beyond cookies

tyle=”margin: 0px 0px 1.2em !important;”>Article 5(3) of the ePrivacy Directive is often called the cookie rule. The nickname can be misleading because it encourages privacy teams to look for one technology and stop once they have dealt with it.

The rule covers storing information on a user’s device or accessing information already stored there. The Directive calls the device ‘terminal equipment’: a phone, laptop, tablet or connected device. The technology itself is not the point.

The European Data Protection Board (EDPB) adopted final guidelines on the technical scope of Article 5(3) in October 2024, clarifying which techniques fall within it. Two examples show why this matters.

A third-party component in your app reads a device identifier and sends it to an analytics provider. It may also write identifiers or configuration data into local app storage.

Reading information from the device is not necessarily enough on its own. If a component uses information only locally and the information does not leave the device, that does not mean a third party has gained access to it. The position changes when the information, or something derived from it, is made available to that third party. So ‘the SDK reads something’ is not the end of the enquiry.

What happens to the information afterwards is also part of the question.

A tracking pixel can fall within Article 5(3) even though no conventional cookie is placed. Loading it can cause information to be stored on the device, including through caching, and can cause the device to send information back.

When ePrivacy device access does not require consent

Technical applicability does not automatically require consent. If Article 5(3) applies, consent is not always required.

Article 5(3) contains two exemptions from consent: storage or access used solely to carry out the transmission of a communication, and storage or access that is strictly necessary to provide an information society service explicitly requested by the user.

Those exemptions can apply in practice. But you need to test the operation against Article 5(3) itself. You cannot simply carry across a GDPR conclusion reached for a different purpose. A legitimate interests assessment answers a different question.

Those exemptions can apply in practice. The point is that the analysis has to be done against Article 5(3)’s own tests, rather than inherited from a GDPR conclusion reached for a different purpose. A legitimate interests assessment answers a different question.

So the sequence is:

  • First: does Article 5(3) apply to this operation, and does one of its exemptions cover it?
  • Then: if personal data is processed as a result, what does GDPR require?

Which national ePrivacy rules apply?

One structural point is easy to miss if you are used to GDPR. Article 5(3) comes from a Directive. The EDPB guidelines help with technical scope, but national implementing law still matters for territorial scope, exemptions and enforcement.

Unlike GDPR, there is no single EU-wide territorial test equivalent to GDPR Article 3. You need to identify the relevant national law and check when it applies, especially if the business has no establishment in that country.

How to structure an ePrivacy device access review

For a mobile app or other digital product offered in European markets, start by establishing which national ePrivacy rules apply. Then ask four questions:

  1. What runs on the user’s device (scripts, embedded components, pixels?)
  2. What does each of them read from, or write to, that device?
  3. Does Article 5(3) apply, and is an exemption available?
  4. If personal data is then processed, what does GDPR require?
    A GDPR-led privacy review can easily start at question four.

Actions you can take

  • Map the third-party components, scripts and pixels in your app or site.
  • Establish what each reads from or writes to the user’s device, and where that information goes afterwards.
  • Do not treat ‘we don’t use cookies’ as the end of the ePrivacy analysis.
  • Test the Article 5(3) exemptions before relying on a GDPR lawful basis.
  • Review the supplier’s technical documentation against what the component actually does.
  • For each EU or EEA market you target, identify the relevant national ePrivacy rules and check when they apply.

If you are launching a digital product into European markets, or reviewing one already there, we can carry out an ePrivacy device access review. We assess what each component reads from or writes to the device, whether an exemption applies, and which national rules govern the analysis. Contact us before your next release.

​