# Fingerprinting under GDPR and ePrivacy

> The two layers of EU rules for a site that reads device signals: access to the device, then processing of the result. Informational, not legal advice.

Source: https://whiskerjs.com/privacy/gdpr-eprivacy/ (last updated 2026-10-26)

> **In plain words:**
>
> In the EU two sets of rules meet. The ePrivacy rules ask whether you may read information from the visitor’s device at all, and often require consent for that. The GDPR asks whether you may use what you read, and how: with a lawful basis, openly, for a clear purpose and not for longer than needed. A fingerprinting script raises both questions. WhiskerJS keeps the data small, but your site still has to answer them.

> **Informational, not legal advice.** This page summarises EU legal texts and published regulator guidance in general terms. It does not say what applies to your site, and national rules and enforcement differ between member states and the UK. Take advice from a qualified lawyer or your data protection officer for your own case.

## Layer one: access to the device (ePrivacy)

Article 5(3) of the ePrivacy Directive (Directive 2002/58/EC, as amended by Directive 2009/136/EC) says, in substance, that storing information on a user’s terminal equipment, or gaining access to information already stored there, is allowed only if the user has given consent after clear and comprehensive information. It has two exemptions:

- access for the sole purpose of carrying out the transmission of a communication; or
- access that is strictly necessary for the provider to deliver an information society service explicitly requested by the user.

The rule is not limited to cookies. The Article 29 Working Party said in its Opinion 9/2014 on device fingerprinting that Article 5(3) applies to fingerprinting, and the European Data Protection Board’s Guidelines 2/2023 on the technical scope of Article 5(3) read “gaining access” broadly, including scripts that run on the device and read its properties. A script like WhiskerJS reads characteristics of the browser and device in the page, so the question whether consent is needed applies to it.

### The exemption question for security and fraud checks

Whether a security or fraud check is “strictly necessary” for a service the user asked for is debated, and the answer depends on the case:

- Arguments for the exemption point to checks that protect the very service the user requested, run only at that moment (for example at login or payment) and are used for nothing else. The Article 29 Working Party’s Opinion 04/2012 on the cookie consent exemption discussed security cookies of this kind for a user-requested service.
- Arguments against point out that fraud detection mainly protects the site, that the exemption is read narrowly, and that a fingerprint is useful for tracking well beyond the request.

National authorities do not all take the same line. In the UK the equivalent rule is regulation 6 of the Privacy and Electronic Communications Regulations (PECR), which has been amended; check the current guidance of the Information Commissioner’s Office. Decide this point with your advisers and document the reasoning.

Practical consequences either way:

- If you rely on the exemption, keep the use narrow: collect only at the protected moment, for security purposes only, and never reuse the result for analytics or advertising.
- If you rely on consent, collect only after consent, and decide what happens for users who refuse (for example a different verification step).

## Layer two: processing the result (GDPR)

### Personal data

Article 4(1) of the GDPR defines personal data as information relating to an identified or identifiable person, and names online identifiers among the ways a person can be identified. Recital 30 mentions online identifiers provided by devices. A visitorId that is stored with account and login data clearly relates to a person; even on its own it is designed to single out a browser setup. Treat ids and results as personal data.

### Lawful basis

Article 6(1) lists the lawful bases. For fraud and security, sites usually consider:

- **Legitimate interests** (Article 6(1)(f)): Recital 47 says that processing strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest, and Recital 49 says the same of processing strictly necessary for network and information security. A balancing test is still needed: your interest, the necessity of the processing, and the user’s reasonable expectations and rights.
- **Consent** (Article 6(1)(a)): if you collected consent for device access, consider whether it also serves as the basis for processing, and what withdrawal means.
- **Legal obligation** (Article 6(1)(c)): where a specific law requires the checks.

Legitimate interests under the GDPR do not answer the ePrivacy access question; the two layers are assessed separately.

### Principles that matter most here

| GDPR rule | What it means for device signals |
| --- | --- |
| Purpose limitation, Article 5(1)(b) | collect for security and fraud prevention; do not reuse for marketing |
| Data minimisation, Article 5(1)(c) | drop components you do not need with `collect({ exclude })` |
| Storage limitation, Article 5(1)(e) | keep stored ids and results for a short, defined period |
| Transparency, Articles 13 and 14 | say what you collect, why, on what basis and for how long |
| Right to object, Article 21 | applies where you rely on legitimate interests |
| Automated decisions, Article 22 | decisions based solely on automated processing with legal or similarly significant effects (such as refusing a payment or closing an account) need safeguards; keep a human route |
| Data protection by design, Article 25 | prefer the least intrusive setup that meets the purpose |
| Impact assessment, Article 35 | consider whether a DPIA is required, for example for systematic monitoring at scale |

## How WhiskerJS supports minimisation

- It has no network code and no telemetry, so no third party receives data from the library.
- It stores nothing on the device: no cookies, no local storage, no IndexedDB.
- It shows no permission prompts and reads no location, camera, microphone, contacts or files.
- Large values leave the browser only as truncated SHA-256 digests.
- It does not work around privacy browsers: components that Brave, Firefox and Safari fingerprinting protection, Firefox resistFingerprinting and Tor Browser randomise or normalise are excluded.
- Volatile signals (zoom, taskbar, permissions, keyboard layout, versions) stay outside the ids.

These points help with Articles 5 and 25. They do not decide the consent question or make any particular use lawful. See [Privacy (library docs)](https://whiskerjs.com/docs/privacy/).

## A checklist for your team

1. Write down the purpose and the moments you collect (sign-up, login, payment).
2. Decide, with advice, whether you rely on consent or an exemption for device access, and record why.
3. Choose and document the GDPR lawful basis; for legitimate interests, write the balancing test.
4. Remove components you do not need with `exclude`.
5. Set and enforce a retention period for stored ids and results.
6. Update your privacy notice. See [What a privacy notice should say](https://whiskerjs.com/privacy/privacy-notice/).
7. Keep a human review route for automated refusals.
8. Consider a DPIA.

## Questions and answers

### Do I need consent to run a fingerprinting script in the EU?

Possibly. ePrivacy Article 5(3) requires consent to access information on a device unless an exemption applies. Whether a security or fraud check is strictly necessary for a service the user asked for depends on the case and on national guidance.

### Is fraud prevention a legitimate interest under the GDPR?

Recital 47 says processing strictly necessary for preventing fraud also constitutes a legitimate interest. You still need a balancing test, and legitimate interests do not settle the separate ePrivacy consent question.

### Is a visitorId personal data if I do not know the user's name?

Often yes. The GDPR covers data that can single out a person directly or indirectly, including online identifiers. Treat ids and results as personal data unless your advisers conclude otherwise.

## Related pages

- [What a privacy notice should say](https://whiskerjs.com/privacy/privacy-notice/): Text to adapt and a checklist.
- [Fingerprinting without cookies](https://whiskerjs.com/privacy/fingerprinting-without-cookies/): Why no cookies does not mean no consent rules.
- [Data minimisation in WhiskerJS](https://whiskerjs.com/docs/privacy/#data-minimisation): What the library leaves out and why.
- [Fraud prevention](https://whiskerjs.com/use-cases/fraud-prevention/): The purpose most sites use device signals for.