Do you need cookie consent for a CDN? Privacy myths, busted

Almost all confusion about CDNs and privacy comes from collapsing two separate questions into one. "Does this set cookies I need consent for?" and "does this process personal data?" have different answers, sit under different laws, and require different things of you.

Consent for cookies comes from the ePrivacy Directive, which governs storing or reading information on someone's device. Processing personal data comes from GDPR, which governs what you do with the data itself. A thing can require the second without requiring the first — which is exactly the case for a CDN, and is why so many people arrive at the wrong answer confidently.

Myth 1: "Using a CDN means I need a cookie banner"

False. Consent banners exist for storing or reading information on a visitor's device for non-essential purposes — analytics, advertising, profiling. A CDN delivering your own images, stylesheets and pages does not need to store anything on the device to do that job.

The cookies that trigger banners come from your analytics and marketing tools, and they would trigger them whether or not a CDN existed. If the only thing that changed is where your own files are served from, your banner obligations are unchanged.

Myth 2: "A CDN tracks my users"

False, for a content CDN. Delivering content requires processing technical data — chiefly the IP address, because you cannot route a response without knowing where to send it — but that is a categorically different activity from building a behavioural profile across sites.

The reasonable question is not whether a CDN sees an IP address, since anything serving you a web page necessarily does. It is what happens to it afterwards: how long logs are retained, whether addresses are truncated or hashed, and whether the provider's business model gives it any reason to be interested in your visitors.

Myth 3: "Security cookies need consent too"

False. Cookies strictly necessary to provide a service the user explicitly requested are exempt from consent. A cookie that remembers a visitor has passed a bot challenge, so they are not challenged repeatedly, falls squarely within that exemption — it exists solely to deliver the page they asked for.

The exemption is narrower than people would like, though. It covers what is strictly necessary, not what is convenient. A security cookie that also carried analytics identifiers would not qualify, and calling something "essential" does not make it so.

Myth 4: "Using a CDN is a GDPR violation"

False as stated. Using a processor is entirely ordinary and explicitly contemplated by GDPR; that is what Article 28 is for. What matters is whether you have the paperwork and whether personal data ends up somewhere it should not.

What you actually need is a data processing agreement with the provider, a mention in your privacy policy, and either a valid transfer mechanism or an arrangement where European traffic does not leave the EEA. That is a checklist, not a prohibition.

Myth 5: "It is fine, we anonymise the IPs"

Careful. Truncating or hashing IP addresses in logs is genuinely worthwhile and reduces your exposure meaningfully — but it does not retroactively make the processing not have happened. The edge server had the full address at the moment it answered the request, because it could not have answered otherwise.

Anonymisation is data minimisation, which is an obligation you have and should meet. It is not an exemption from having a lawful basis and a DPA.

Myth 6: "Serving assets from a third party is legally risky"

This one is not a myth, and it is worth understanding precisely, because it is frequently misapplied.

A German court found in 2022 that a website embedding Google Fonts from Google's servers had unlawfully transmitted visitors' IP addresses, and awarded damages. That ruling caused a wave of sites self-hosting their fonts, and a wave of speculative complaint letters.

The reasoning matters more than the headline. The problem was not that a font was loaded from another server. It was that visitors' IP addresses were being disclosed to a third party in another jurisdiction, with no consent and no necessity, when the site could trivially have served the file itself. The transmission was avoidable and unnecessary — that was the issue.

Which is why the same reasoning does not straightforwardly extend to a CDN you have engaged as your processor under a DPA, serving your own content, from infrastructure within the EEA. The distinction is between disclosing data to an independent third party for their own purposes, and instructing a processor to act on your behalf under contract. Embedding a public asset from someone else's product is the first. Using a CDN is the second.

What you actually need

Keep the two questions apart and most of the confusion resolves itself. Consent is about what you put on someone's device. GDPR is about what you do with their data. A CDN delivering your own content raises the second and not the first — and the second is answered with a contract and a paragraph, not a pop-up.