WhorlID
Live demoGet started

compliance

GDPR and device fingerprinting

Last reviewed 25 July 2026

Most fingerprinting vendors sell "no cookies" as if it were a compliance feature. It is not. Removing the cookie removes the cookie, not the obligation. This page is the honest version: what the rules actually cover, where fraud prevention genuinely helps you, and what you have to do on your own site to deploy WhorlID lawfully.

We are engineers, not your lawyers, and this is not legal advice. It is the position we designed the product around, written plainly so your counsel can check it quickly.

The short version

Why "we do not use cookies" is not an argument

The rules are written around access to the terminal equipment, not around a storage format. A script that reads your screen resolution, your GPU renderer string, and your audio stack behaviour is accessing information from your device just as surely as one that reads a cookie, and it is more durable, because the user cannot clear it. Regulators noticed that argument some time ago and closed it. If a vendor tells you fingerprinting sidesteps consent because nothing is stored, treat that as a reason to distrust the rest of their claims.

Where the strictly-necessary exemption can help

This is the part worth getting right, because it is the difference between a consent banner in front of your login form and no banner at all. The exemption is narrow and it is assessed from the user's point of view, not yours. Two things matter: whether the user explicitly requested the service, and whether the access is strictly necessary to deliver it.

The stronger case. A user submits a login, creates an account, or completes a checkout, and you read the device to detect account takeover, stolen cards, or automated abuse in that transaction. The user asked for the transaction, security is part of delivering it, and the processing is limited to it. Several regulators accept security measures of this kind as strictly necessary in principle; the argument gets stronger the tighter the coupling between the check and the thing the user asked for.

The weaker case. Fingerprinting every visitor on every page load "for security", keeping the result for general analytics, using it to enforce a trial limit or a coupon rule, or feeding it into anything resembling marketing. Convenient for you is not the same as strictly necessary for the user, and a purpose that drifts is the fastest way to lose the exemption you started with.

Practically: the narrower and later you run the check, the better your position. Run it on the security-relevant action, not on the homepage.

What we have built so the lawful version is the easy version

How to deploy it lawfully

1. Decide your position first, in writing. Either you rely on the strictly-necessary exemption for a specific security flow, or you collect consent. Write down which, and why, before you ship. If you are relying on the exemption, that document is what you will be asked for.

2. Run the check on the action, not on the page. Call it at login, signup, checkout, or password reset, not in your global layout. This is better security practice and a better legal position at the same time.

3. If you are collecting consent, gate the load. Nothing leaves the browser until fpjs.load runs, so a gate is enough. No special vendor integration required:

consent-gate.js
// Load the collector only once your consent state allows it.
// Replace hasConsent() with your CMP's API (TCF, Google Consent Mode,
// or your own banner state).
async function identifyIfAllowed() {
  if (!hasConsent('device_fingerprinting')) return null;

  const fp = await fpjs.load({ publicKey: 'pk_live_...' });
  const { requestId } = await fp.get();

  // Send only the requestId to your backend, then verify it
  // server-side with your secret key.
  return requestId;
}

4. Disclose it in your own privacy notice. Name the purpose, the processor, and the retention. Something like this, adapted to your setup:

privacy-notice-snippet.txt
Fraud and abuse prevention. When you log in, create an account, or
check out, we read technical characteristics of your browser and device
(such as screen properties, hardware capabilities, and graphics and audio
rendering behaviour) to recognise the device and detect fraudulent or
automated access. This is done by WhorlID, our processor, operating in
Ireland on our behalf. The identifier is used only on this site, is never
used for advertising, and the underlying technical signals are deleted
within 30 days. [Describe your legal basis and, where consent applies,
how the user can withdraw it.]

5. Keep the purpose where you put it. If someone later asks to use the same identifier for growth analytics, that is a new purpose and a new assessment, not a free extension of the old one.

6. Treat the result as evidence, not proof. Identification is probabilistic and the signals are forgeable. Deciding to block a person automatically on a probabilistic score also drags in the fairness and automated-decision provisions of the GDPR. Combine it with your own account signals and keep a human route for appeals.

What we cannot do for you

We cannot tell you that your deployment is lawful, because that depends on facts only you have: which flows you run it on, what you tell your users, what else you combine it with, and which regulator you answer to. We also cannot promise that the strictly-necessary exemption covers your case. What we can do is not stand in your way: no dark patterns, no hidden secondary use, retention you can point at, a signed DPA, and a straight answer when you ask us something we have not built.

Questions worth asking any fingerprinting vendor

Ours are answered above and in the DPA. If an answer is missing, ask us and we will add it to this page.

Data Processing Agreement | Privacy policy | Integration docs

GDPR and device fingerprinting: how to deploy it lawfully | WhorlID