Is a MAC Address Personal Data? A €600,000 GDPR Ruling

Key Takeaways

On 29 July 2026 the Administrative Jurisdiction Division of the Dutch Council of State (ECLI:NL:RVS:2026:4403) left the annulment of a €600,000 GDPR fine standing — without deciding whether pseudonymised MAC addresses are personal data. That question was never reached.
The case turned on evidence, not on technology. The regulator confirmed at the hearing that it had not met the evidentiary standard for the three identification routes it had put forward.
A fining authority must produce its supporting evidence when it takes the decision, not later in court — settled Dutch case law, which the Division applied here. The separate rule that the regulator carries the burden of proving the infringement is anchored in Article 6(2) ECHR.
Enschede pseudonymised every captured MAC address and, from 1 January 2019, cut the last three characters off it. No court has held that this made the data anonymous.
Your accountability duty runs the opposite way to the regulator's: Article 5(2) GDPR requires you to demonstrate compliance, so an untested assumption that your hashed identifiers are anonymous is a gap in your records rather than a defence.

Introduction

A headline crossed European privacy feeds on 29 July 2026: a data protection authority had just lost a €600,000 fine over counting people's phones in a city centre. If your store hashes customer emails before sending them to an ad platform, or counts footfall in a physical shop, the temptation is to file that under good news and move on.

Read the judgment and the good news evaporates. The court did not decide that pseudonymised MAC addresses fall outside the GDPR. It decided the regulator had not proved its case, and never reached the substantive question at all. Those are very different findings, and the coverage has not reliably kept them apart.

This is informational content, not legal advice.

Often yes, but never automatically. Article 4(1) GDPR defines personal data by reference to identifiers including "location data" and "an online identifier", while Recital 26 makes identifiability turn on "all the means reasonably likely to be used". That is a factual test, answered case by case — not a fixed property of the identifier.

Two pieces of the regulation do the heavy lifting here. Article 4(1) covers "any information relating to an identified or identifiable natural person", where an identifiable person "is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier …". A device identifier tied to a place and a timestamp sits squarely inside that language.

Recital 26 then answers the question everyone actually asks about hashing. It states that "personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person". It also names singling out as one of the means to weigh, and requires account to be taken of "the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments".

What Enschede actually did

To measure visitor numbers, the municipality of Enschede ran a continuous passer-by count using at least ten sensors in the city centre, which picked up the MAC address of devices in range with wifi switched on. The judgment describes a MAC address as "an in principle unique identification number of twelve hexadecimal characters (0-9, A-F) assigned to the network card of a device" (our translation). Each captured address was held briefly in working memory, converted by an algorithm into a pseudonymised MAC address, and sent to a central server.

One design detail matters more than the rest: all the sensors used the same algorithm, so a device seen by several sensors received the same pseudonymised value each time. Daily records went into a short-term table, then through filters — an opt-out register, address spoofing, and a resident filter removing devices seen between certain night-time hours — before landing in a long-term table holding six months of data. From 1 January 2019 the server cut the last three characters off the pseudonymised address. The municipality decided on 5 September 2017 to start 24/7 passer-by counting from the following day; the processing the regulator fined ran from 25 May 2018 through 30 April 2020, and the count stopped on 1 May 2020.

What the regulator argued

The court recorded the Dutch DPA's position as follows. The pseudonymised MAC address and the location data say nothing about anyone's identity, so they do not concern an identified person — but they are information about an identifiable natural person. Attaching location data to a unique number amounts to individualising someone and can expose patterns of life and behaviour. The authority set out three ways in which identification could occur and argued that, because none required excessive effort and none was legally prohibited, the data were personal data. Truncation did not cure that.

It imposed the €600,000 fine by decision of 11 March 2021, raising the base amount by €75,000 because the processing was structural, ran for an unnecessarily long period, and touched hundreds of thousands of citizens.

What the Council of State actually decided

It decided the appeal failed, and very little else. The Division confirmed the district court's judgment, so the annulment of the fining decision stands and the €600,000 is gone. On whether a pseudonymised MAC address combined with location data is personal data, it decided nothing at all.

The reason is unusually candid. The Division recorded that the authority did not contest the district court's finding that it had failed to properly investigate and reason identifiability. It then noted that the authority "also confirmed at the hearing before the Division that, with regard to the three ways set out for this purpose, the evidentiary standard has not been met" (our translation of: "De AP heeft op de zitting bij de Afdeling ook bevestigd dat ten aanzien van de hiertoe geschetste drie manieren niet is voldaan aan de bewijsstandaard.").

The evidence rule that ended the case

The authority then pressed an argument it had raised before the district court but never in its own decision: that people had been directly identified, because combining MAC addresses with location data allowed unique visitors to be counted at all. The Division's answer was that this position was absent from the authority's own decision-making — so it declined to test that argument and left it "buiten beschouwing" (out of consideration, our translation). Settled case law requires an administrative body imposing a fine to deliver the supporting evidence of the infringement at the completion of its decision-making — "also in the light of the legal certainty the alleged offender can claim and of his ability to mount a timely and adequate defence in law against the accusation" (our translation).

The two precedents cited say the same thing from different angles. In ECLI:NL:RVS:2015:4034, at 6.2, the safeguard invoked is Article 6(2) ECHR: the burden of proving an infringement rests on the administrative body, and "in case of doubt the person concerned must be given the benefit of the doubt" (our translation). In ECLI:NL:RVS:2017:1819, at 5.1, adding evidence after the decision is not categorically barred, but the possibility is bounded by due process — again because of the accused's ability to defend themselves in time.

The district court had made the point in plainer terms on 2 February 2024 (ECLI:NL:RBOVE:2024:594), noting that where a fine is discretionary the burden of proof lies with the authority and "high demands are placed on the evidence" (our translation). It faulted the regulator for not investigating whether its identification routes genuinely allowed a device user's identity to be established "met het blote oog" (with the naked eye, our translation), and held that Recital 26 obliged it to examine costs, time, available technology at the time of processing, and technological developments. The alleged breach was of Article 5(1)(a) read with Article 6(1) GDPR.

The appeal was declared unfounded, and a €559.00 court fee was levied from the authority.

Attributed legal read: the Division's holding is procedural — a fining authority must prove the infringement when it decides, not when it litigates. Our practical read is that this tells you a great deal about how regulators must build cases, and almost nothing about whether the identifiers in your own systems are anonymous.

Why "the regulator lost" is not a green light

Because a regulator failing to prove something is not a finding that the opposite is true. Three points separate this judgment from the clearance some coverage described.

The first is scope. The Division never ruled on the substantive question, so the judgment is not authority for the proposition that pseudonymised MAC addresses fall outside the GDPR. Anyone citing it that way is citing a case that does not exist.

The second is direction. The burden that failed here binds a public authority imposing a penalty, backed by the presumption of innocence in Article 6(2) ECHR. That protection belongs to the target of a fine, not to your processing records.

The third is the regulation's starting point. Recital 26 treats pseudonymised data attributable to a person "by the use of additional information" as information about an identifiable person, and names singling out among the means to weigh. Enschede's shared algorithm produced a stable value for the same device across every sensor — on its face, a singling-out capability. Our read is that this makes the design a harder case for anonymity than the headlines suggest, and it is exactly the analysis no court has yet performed.

Your burden runs the other way

Article 5(2) GDPR is one sentence long: "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')." That is the mirror image of the rule that decided Enschede. A regulator must prove an infringement to fine you; you must be able to demonstrate compliance whether or not anyone is investigating.

"We assumed it was anonymous" is not a demonstration, and the assumption is usually undocumented. If your record of processing activities simply omits the hashed identifiers you send to ad platforms on the grounds that they are not personal data, the omission is the finding — there is nothing there to review. For the substantive test of when data is genuinely anonymous rather than pseudonymised, see our guide to GDPR anonymisation.

Coverage has not helped. Reporting the ruling on 29 July 2026 under the headline "Raad van State: intrekking privacyboete Enschede terecht", the Dutch local-government outlet Gemeente.nu both reported that the regulator had insufficiently demonstrated that the addresses qualified as personal data and carried language suggesting the device codes and location data simply cannot be traced back to people. Those are two different claims, and only the first is in the judgment.

What to do about the pseudonymised identifiers in your stack

Treat this as a documentation exercise, not a legal one. The output is a dated determination you could hand to a regulator.

Inventory what you currently treat as anonymous. Hashed emails sent to advertising platforms, cookie and device IDs, session identifiers, order hashes, loyalty tokens, and any in-store footfall or wifi analytics.
For each one, write down who holds the additional information that would re-link it, and where that sits. Article 4(5) makes pseudonymisation conditional on such information being "kept separately" and protected by technical and organisational measures — if it is not separate, the definition is not met.
Apply Recital 26's factors explicitly and date the assessment. Costs, time required, the technology available at the time of processing, and technological developments. An undated conclusion cannot be defended later.
Test singling out on its own. A value that stays stable across sessions, devices, or locations lets you pick one person out of a crowd without ever learning a name. Enschede's shared algorithm did exactly that across ten sensors.
Record the conclusion and its reasons in your ROPA, with a review date. The reasoning is the asset; the yes-or-no answer alone is not demonstrable.
Where the honest answer is "probably personal data", stop arguing and assign a lawful basis. Consent for tracking technologies is usually the relevant route — see cookie consent best practices.

Common mistakes

Reading an evidential ruling as a technical clearance. This is the worst of them, and the reason this article exists. A regulator that fails to prove identifiability has told you about the quality of its file, not about the nature of your data.

Calling hashing "anonymisation". Article 4(5) defines pseudonymisation as processing after which the data "can no longer be attributed to a specific data subject without the use of additional information". A stable hash applied consistently across your estate is a pseudonym, not an erasure — the identifier still points at one person every time.

Treating truncation as a threshold. Enschede cut three characters from every pseudonymised address from 1 January 2019, and no court has held that this made the data anonymous. Chopping bits off an identifier is evidence for an anonymity argument, not the argument itself.

Letting the assessment go stale. Recital 26 pegs identifiability to the technology available at the time of the processing. A determination written in 2019 does not describe re-identification risk in 2026, and the older it gets the less it protects you.

Keeping the determination in someone's head. Under Article 5(2) the reasoning has to exist in a form you can produce. If it lives only in a decision someone made three roles ago, you cannot demonstrate anything.

How PrivacyForge Helps

The difficulty with Recital 26 is not understanding it. It is that the answer changes per identifier, per system, and over time — and nobody owns the record of what was decided.

PrivacyForge's data mapping keeps the identifier inventory and the identifiability determination in one place: what the identifier is, who holds the re-linking information, which Recital 26 factors were weighed, when the assessment was made, and when it is next due. Where the conclusion is that data is personal, consent records and lawful-basis tracking pick it up from there, and compliance scoring surfaces assessments that have gone stale. None of that decides the legal question for you. It does mean that when someone asks why you treat a hashed identifier as anonymous, the answer is a dated record rather than an afternoon of archaeology.

Frequently Asked Questions

Is a MAC address personal data under GDPR?

Frequently, though it turns on the facts. Article 4(1) GDPR lists "location data" and "an online identifier" among the identifiers that can make someone identifiable, and Recital 26 asks whether identification is possible using "all the means reasonably likely to be used". A MAC address tied to place and time is a strong candidate, assessed case by case.

Did the Dutch court rule that MAC addresses are not personal data?

No. In its judgment of 29 July 2026 (ECLI:NL:RVS:2026:4403) the Administrative Jurisdiction Division of the Council of State never reached that question. It upheld the annulment of the €600,000 fine because the regulator had not proved its case at the decision-making stage, and refused to examine the one substantive argument raised too late. The question remains undecided.

Does hashing or pseudonymising data make it anonymous?

No. Article 4(5) GDPR defines pseudonymisation as processing after which data cannot be attributed to a person "without the use of additional information", and Recital 26 says pseudonymised data that could be attributed to someone using additional information is still information about an identifiable person. Anonymisation is a higher bar, assessed on re-identification risk.

Who has to prove that data is personal data — the company or the regulator?

Both, in different settings. To impose a fine, a regulator carries the burden of proving the infringement, and in the precedent the Division cited that burden is anchored in Article 6(2) ECHR with the benefit of the doubt going to the alleged offender. Separately, Article 5(2) GDPR requires controllers to demonstrate their own compliance.

Does truncating an identifier put it outside the GDPR?

Not by itself. Enschede's system cut the last three characters from each pseudonymised MAC address from 1 January 2019, and no court has ruled that this made the data anonymous. Truncation reduces re-identification risk and is evidence worth recording, but the Recital 26 assessment still has to be carried out and documented.

What should an online store do about identifiers it treats as anonymous?

Inventory them, then document a determination for each. Record who holds the information that would re-link the identifier, whether it is kept separately as Article 4(5) requires, which Recital 26 factors you weighed, and the date. Test whether the value lets you single out one person across sessions. Assign a lawful basis wherever the answer is uncertain.

Conclusion

The Enschede judgment is a good decision and a bad headline. It enforces something worth enforcing — that a regulator must build its case before it fines you, not after — and it does so without ever reaching the question of whether the underlying data was personal. Treating that silence as a clearance is the one reading the text will not support.

For an online store, the practical consequence is unglamorous. Nothing about your hashed emails, cookie IDs, or footfall counters changed on 29 July 2026, and the burden that protected a Dutch municipality in a penalty case is not the burden Article 5(2) puts on you. Write down which identifiers you treat as anonymous, why, and when you decided it.

Run a free compliance scan to see which trackers your store is loading, then record the determination for each identifier behind them.

Sources

#personal data #enforcement #pseudonymisation #data mapping #GDPR