Is Device Fingerprinting Legal? GDPR, ePrivacy, and Fraud Prevention

This comes up in every procurement review and the answers online are uniformly bad — either "it is fine, fraud prevention is a legitimate interest" or "it is illegal without consent." Both are too simple, because two separate laws apply and they ask different questions.

What follows is how the regime is structured and which questions to put to your own counsel. It is not legal advice, and anyone selling you a fraud tool who says otherwise is not being straight with you.

Two laws, two questions

Almost all confusion here comes from collapsing two separate regimes into one.

GDPR asks whether you may *process personal data*, and requires a lawful basis. ePrivacy (in the UK, PECR) asks whether you may *store information on, or gain access to information stored on, a user's terminal equipment* — and that question has its own answer regardless of what your GDPR basis is.

A fraud tool can be perfectly defensible under GDPR and still owe you an ePrivacy analysis. Getting a clean answer on one tells you nothing about the other.

The GDPR side is the easier one

Fraud prevention has unusually explicit support. Recital 47 of the GDPR states outright that processing personal data strictly necessary for fraud prevention purposes constitutes a legitimate interest of the controller.

That is not a blank cheque — legitimate interest still requires a balancing test weighing your interest against the rights of the data subject, and you have to document it. But it does mean the usual starting point for fraud detection is Article 6(1)(f), not consent, and that position is well supported.

Note also that an IP address is personal data where it can be linked to an individual, following the CJEU's decision in *Breyer* (C-582/14). So IP reputation checks are in scope even if you never touch a name or an email.

The ePrivacy side is where it gets interesting

Article 5(3) of the ePrivacy Directive requires consent for storing or accessing information on a user's device, with a narrow exemption for what is *strictly necessary* to provide a service the user explicitly requested.

Crucially, this is technology-neutral. It is not a cookie rule. European regulators have been consistent that it captures device fingerprinting, local storage, and similar techniques, precisely because the alternative would have let everyone sidestep it by not using cookies.

So the question becomes whether your fraud check falls inside the strictly-necessary exemption. Reasonable arguments exist that security measures a user would expect — protecting their own account at login — qualify. Regulators have not universally endorsed that reading, and it is weaker for, say, profiling a browsing session than for verifying a login. This is exactly the question to put to counsel rather than to a vendor blog.

Questions worth asking any fraud vendor

Independent of your own analysis, the vendor's architecture determines how hard your position is to defend.

• Is identity correlated across customers? A vendor that links device identity across its whole customer base is building a cross-site profile of individuals, which is a substantially harder position to defend than one that keeps correlation inside each customer's own data. Ask directly, and get the answer in writing.
• What is actually stored, and for how long? "We store a hash" and "we store a full fingerprint" are materially different claims. So is thirty days versus indefinitely.
• Is there a DPA, and who are the sub-processors? You need both to complete your own Article 30 records, and a vendor who cannot produce a current sub-processor list on request is telling you something.
• Where is data processed? Transfers outside the EEA need their own mechanism, and "our cloud provider has a region there" is not the same as a documented transfer basis.
• Can you honour erasure? If a data subject requests deletion, can the vendor actually delete — including from backups — and how quickly?

Where Sentinel sits, concretely

So you can evaluate the above against a real answer rather than a generic one:

• Device-to-account linking is per-customer only and hash-only. Correlation never crosses between customers, which means Sentinel does not build a cross-site profile of any individual. This is an architectural constraint, not a setting.
• Signup email checks against disposable-domain feeds are transient — checked in the request, never stored or logged.
• A DPA and a current sub-processor list are published rather than available on request.
• The company is UK-registered (Sentinel Edge Networks LTD), and the retention position is documented in the privacy policy rather than described only in sales conversations.
• None of that decides your ePrivacy question. It narrows what you have to defend.

The practical position

Most teams running fraud detection in the EU and UK land somewhere like this: legitimate interest under Article 6(1)(f) as the GDPR basis, with a documented balancing test; a considered position on whether the client-side collection falls inside the ePrivacy strictly-necessary exemption; transparency in the privacy notice about what is collected and why; and a vendor whose architecture does not create cross-site profiling.

That is a defensible posture. It is also one you should reach with your own counsel, having read the actual texts, rather than by trusting a paragraph on a vendor's website — including this one.

Go deeper

• Data Processing Agreement
• Current sub-processor list
• Privacy policy and retention
• Device fingerprinting vs IP intelligence

Evaluate the architecture, not the promise

Per-customer linking, hash-only, published DPA and sub-processors.

Try Sentinel free →