Is a MAC Address Personal Data? What GDPR Case Law and Regulators Say

In a design review or a procurement meeting, you will almost certainly hear this line: "A MAC address is just a hardware number, so it is not personal information." As of 2026, that line no longer holds. Two consecutive rulings from the Court of Justice of the EU in the past two years, plus an unambiguous statement from the UK's ICO, point to the same conclusion: in most real-world scenarios a MAC address is personal data, and therefore inside the scope of the GDPR. This article lays out the legal basis, the key rulings, and what it actually means for network operations.

The test: identifiability, and specifically reasonably likely identifiability

Article 4(1) of the GDPR defines personal data as "any information relating to an identified or identifiable natural person", and expressly lists an online identifier among the identifiers. Recital 26 then supplies the test: to determine whether a natural person is identifiable, account must be taken of "all the means reasonably likely to be used, such as singling out".

That sentence is the crux of the debate, and it means two things:

1. A name is not required. Being able to single you out from a crowd is enough to make you identifiable.
2. Reasonable access to other information counts. Even if a MAC alone reveals nothing, the moment it can be combined with other data the holder possesses to point at a person, it is already personal data.

MAC addresses are hazardous on both counts. A unicast MAC is globally unique and fixed at manufacture, and its first 24 bits are an IEEE-assigned OUI that reveals the vendor and often the device type (see the IEEE OUI registry). Combined with access logs, DHCP leases and AP association records, tracking one person's device over time is straightforward.

The case law

CJEU C-413/23 P (EDPS v SRB), judgment of 4 September 2025. The question was whether pseudonymised data counts as personal data. The Court reaffirmed that pseudonymised data remains "information on an identifiable natural person" as long as it can be attributed to a person by the use of additional information, judged by all means reasonably likely to be used by the controller or others. The practical consequence: hashing an identifier or keeping a mapping table does not move it outside the GDPR as long as it can still be reversed.

CJEU C-604/22 (IAB Europe), judgment of 7 March 2024. The subject was the TCF consent string — a string of characters recording a user's consent preferences. The Court held it to be personal data, because the moment the string can be linked to a user's device identifier it identifies that user. This ruling nails down the logic that "a seemingly neutral technical string + a linkable identifier = personal data", and a MAC is exactly such a linkable identifier.

The earlier CJEU C-582/14 (Breyer), judgment of 2016, already established the same reasoning: for a website operator, a dynamic IP address is personal data because he has lawful means to obtain supplementary information from the ISP. IP and MAC stand on the same footing for identifiability — indeed, the European Commission lists "storing IP addresses or MAC addresses" directly as an example of data processing.

What regulators say

The UK ICO is blunt on its "Previously asked questions" page (last updated 16 December 2025): UK GDPR expressly includes "online identifiers" in the definition of personal data, which means MAC addresses can qualify as personal data. The scenario ICO discusses is using mobile Wi-Fi "signatures" — that is, MAC addresses — to estimate the number of people in an area, and it explicitly requires a lawful basis.

The European Commission's "Data protection explained" page lists storing a MAC address as an act of processing, and stresses that de-identified, encrypted or pseudonymised data that can still be used to re-identify a person remains personal data; only irreversible anonymisation falls outside the GDPR.

This also aligns with the earlier Article 29 Working Party Opinion 4/2007 on the concept of personal data, still a foundational reference.

What randomisation changes — and what it does not

Client-side MAC randomisation (Apple's private address since iOS 14, Android randomisation, and the MLD/per-link derivation in Wi-Fi 7) genuinely weakens long-term tracking across networks: the same phone uses a different address on each SSID, so a retailer can no longer string you together by one fixed MAC.

But it does not overturn the personal-data finding, because the test is whether you can be singled out in a given scenario. Inside an enterprise network, even a randomised address remains identifiable once it is tied to an employee's account, desk or 802.1X session — and enterprise authentication is moving to certificate-based persistent device identifiers, which binds the device identity back to the person. Randomisation changes the difficulty of identification, not the legal nature.

This also explains why entering a randomised address on the lookup page returns no vendor: that is neither a database problem nor a sign that the address is not personal data. It is a locally administered address with no known vendor, but its legal status is unchanged as long as it can be linked to a person. The rule is in reading the first byte of a MAC.

Pseudonymisation is not anonymisation

Many operations teams "hash the MAC in the logs with SHA-256" and consider it compliant. Per the SRB ruling above, that is pseudonymisation: if the original value, a mapping table or any reversal path survives, the data is still personal data and the GDPR still applies. True anonymisation must be irreversible, and hashing a MAC while keeping a lookup table plainly is not.

What it means for network operations

If you handle MAC addresses, these are the things that actually matter under the GDPR:

1. Establish a lawful basis. Logging MACs usually fits "legitimate interests" (security, abuse prevention) or "performance of a contract" (providing network service), but you must run and document a legitimate-interests assessment. "The technology needs it" is not a basis.
2. Minimise. Keep only the fields troubleshooting genuinely requires; do not pile up AP association logs, DHCP leases and ARP tables indefinitely. See the approach in MAC addresses and privacy.
3. Set retention limits. Give MAC logs an explicit retention period (say 30 or 90 days) with automatic deletion. "Keep it in case it's useful" does not survive the GDPR.
4. Be transparent. State in your privacy policy that you collect MACs, why, how long you keep them, and how to have them erased. This site's privacy policy follows that pattern.
5. Design for protection. Mask or aggregate wherever you can; for device identities you must keep long term, prefer a non-reversible key or simply use the platform ID in your asset system.
6. Honour data-subject rights. When someone asks to access or erase their data, MAC logs count — you need to be able to search and delete by identifier.

A note on asset inventory. When you track devices by MAC, the address is both an asset identifier and personal data (especially in BYOD settings). Design the MAC-based inventory process together with the retention and minimisation rules above, rather than retrofitting them later.

In one sentence

Whether a MAC address is personal data is not a yes-or-no question but a "in which scenario" question. If it can single an individual out in that scenario, it is personal data. The CJEU tightened the standard in SRB and IAB Europe to "reasonably likely identifiability" and "pseudonymised data is still personal data", while the ICO and the European Commission name online identifiers and MACs outright. Client-side randomisation makes tracking less convenient but does not change the legal nature. For operators the conclusion is plain: treat MAC logs as personal data — set retention, minimise, document it in your privacy policy, and be able to delete it.

References

• CJEU C-413/23 P, EDPS v SRB (2025-09-04), ECLI:EU:C:2025:645: https://curia.europa.eu/juris/document/document.jsf?docid=303863&doclang=en
• CJEU C-604/22, IAB Europe (2024-03-07), ECLI:EU:C:2024:214: https://curia.europa.eu/juris/document/document.jsf?docid=283529&doclang=en
• CJEU C-582/14, Patrick Breyer v Bundesrepublik Deutschland (2016-10-19), CELEX:62014CJ0582: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0582
• GDPR full text (Art. 4(1) and Recital 26): https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679
• European Commission, Data protection explained: https://commission.europa.eu/law/law-topic/data-protection/data-protection-explained_en
• UK ICO, Previously asked questions (updated 2025-12-16): https://ico.org.uk/for-organisations/advice-and-services/innovation-advice/previously-asked-questions
• Article 29 Working Party Opinion 4/2007, On the concept of personal data: https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf
• This site: MAC addresses and privacy
• This site: MAC address randomisation
• This site: Recognising devices after MAC randomisation in the enterprise