Unauthorized Cookies: The €475M+ Compliance Gap Your Banner Won't Catch

The CNIL handed out roughly €486.8 million in cookie-related sanctions in 2025 — and almost every major case shared one cause: unauthorized cookies firing before users gave consent. SHEIN paid €150 million for it. Google paid €325 million. American Express paid €1.5 million.

The pattern should worry anyone running an EU-facing site: the cookie banner most teams trust to handle compliance is rarely the thing that catches unauthorized cookies. Banners collect consent. They do not verify what your site actually drops on visitor devices. That gap is what regulators have been exploiting throughout 2025 and 2026 — and what is quietly costing operators tens of millions.

This guide unpacks what an unauthorized cookie is under EU law, why one ends up on your site even when your CMP is "installed and working", what 2025 enforcement teaches us, and how to detect them yourself.

What "unauthorized cookies" actually means under EU law

Any non-essential cookie placed without prior, opt-in consent is an unauthorized cookie — full stop.

The legal foundation is Article 5(3) of the ePrivacy Directive (2002/58/EC, as amended). It requires prior consent before storing or accessing any information on a user's terminal equipment, except where strictly necessary for a service the user explicitly requested. The GDPR (Articles 4(11) and 7) then defines what valid consent looks like: freely given, specific, informed, unambiguous, and given by a clear affirmative action.

The EDPB Cookie Banner Taskforce report (January 2023, still the operating reference for national DPAs) confirms that consent obtained through dark patterns — pre-ticked boxes, hidden "reject" buttons, asymmetric prominence between accept and refuse — does not count as valid consent at all.

The trap: a cookie can technically be "consented to" through your banner UI and still be unauthorized in the legal sense, because the consent itself was invalid. That is why CMP-led compliance is fragile in 2026. The banner can pass internal QA and still fail a regulator-aligned audit.

If the consent isn't valid, neither is the cookie.

The five most common causes of unauthorized cookies

Most unauthorized cookies don't come from rogue scripts — they come from configuration drift in tools you already trust.

1. Pre-consent firing. Tags evaluate before the consent banner mounts. Common when analytics scripts are hardcoded in the page head and with GTM containers that load before Consent Initialization fires.
2. Third-party SDK creep. A new chat widget, A/B testing tool, or session-replay library is added — and quietly drops cookies without honoring the existing CMP's consent state. Nobody notices because the deployment didn't touch the CMP code path.
3. Google Consent Mode v2 misconfiguration. Consent Mode v2 only works if every Google tag is wired to the correct consent signals. Sites toggle it on but skip per-tag consent settings, then leak _ga, _gcl_au, and IDE pre-consent.
4. Persistence after revocation. A user clicks "Reject all", but cookies set during a previous visit are still in the browser. The site doesn't actively delete them. The EDPB position: continued processing of those cookies after revocation is unlawful.
5. CMP catalog drift. Most consent management platforms classify cookies based on what their scanner found the last time it crawled. Cookies introduced between scans default to "uncategorized" — and many CMPs default uncategorized cookies to firing. The result is a built-in unauthorized-cookie generator.

Every cause above starts with a tool the site owner already trusts.

What 2025 enforcement actually penalizes

Regulators in 2025 stopped fining for paperwork failures and started fining for what cookies actually did.

Three cases set the tone:

• SHEIN — €150M (CNIL, September 2025). Inspectors loaded shein.com without interacting with the banner. Advertising cookies fired immediately. Even after clicking "Reject all", new cookies were still placed. The penalty cited the gap between what the banner promised and what the site actually did.
• Google — €325M (CNIL, September 2025). Among the listed violations: cookies placed during Google account creation without valid consent, and a refusal flow with measurably more friction than the acceptance flow.
• American Express Carte France — €1.5M (CNIL, November 2025). Smaller scale, same pattern — cookies fired before a clear, affirmative consent signal.

The thread connecting all three: regulators are not auditing the privacy policy. They are auditing the network tab — what fires, when, and whether the user actually said yes.

In 2025, the cookie audit moved from the legal team's PDF to the regulator's DevTools.

Why your CMP can't fully solve this

A consent management platform records what users say. It does not verify what your site does.

CMPs and verifiers are different jobs that the market keeps confusing. The CMP product loop is straightforward: show banner, capture user choice, signal that choice to integrated tags. That last step only works for tags the CMP knows about and that are wired correctly. New tags, server-side cookies, post-revocation cleanup, and unknown third-party requests all sit outside the CMP's control plane.

The SHEIN case is the textbook example. The CMP was installed. The banner displayed. Cookies still fired pre-consent because the tags responsible weren't covered by the CMP's consent gate. From the CMP-vendor dashboard, everything looked green.

What's actually missing is independent verification — scanning that watches what the site does, end to end, including the things the CMP doesn't know about. That is not a CMP feature, and it cannot credibly be one. CMP vendors have a structural conflict of interest: their scanner is the same product as their banner. If you want a methodical way to pressure-test your own banner against this gap, our independent 14-point banner audit checklist walks through the exact steps.

The CMP and the verifier should never be the same vendor.

How to detect unauthorized cookies on your site

You can find most of them in ten minutes with browser DevTools — and miss the rest forever without continuous scanning.

The quick manual method:

1. Open the site in an incognito window with DevTools open.
2. Clear cookies and storage, then reload.
3. Do not interact with the banner. Watch the Application → Cookies and Network → Headers tabs.
4. Any non-essential cookie that appears is an unauthorized cookie.
5. Repeat with "Reject all" clicked. Any new cookies, or any pre-existing cookies still being read, are also unauthorized.

The hard limit of manual scanning: you only see what fires for your user agent, your IP, and that moment. Cookies routed by geography, device class, or A/B variant won't show up. Third parties added next week won't show up either. This is why tooled scanning exists — and why the scan needs to repeat over time, not just run once.

Manual scanning catches the obvious; only continuous scanning catches the drift.

One-time audit vs continuous cookie monitoring

A point-in-time audit is the price of admission. Continuous monitoring is what keeps you compliant when nothing about your site changes — except everything else does.

Approach	What it catches	What it misses
Manual / quarterly audit	The state of cookies on the day of the audit	Drift between audits, new third-party tags, A/B-variant cookies, regression after CMP changes
Continuous monitoring	New cookies, new vendors, regression after CMP changes, post-revocation persistence — over time	Nothing, if it actually runs end to end

SHEIN's CMP was technically deployed. The fine still landed because the state of the site changed faster than the audit cadence. The compliance question for any team in 2026 is uncomfortable but simple: how would you know if a new unauthorized cookie appeared on your site today?

CookieSentry runs continuous, independent scans of cookies and third-party requests on your site, then issues a timestamped audit PDF that meets the evidentiary bar set under GDPR Article 6 and ePrivacy. It does not replace your CMP. It verifies what the CMP claims is happening.

A static audit is a snapshot of yesterday's compliance.

Frequently asked questions

Is a cookie unauthorized if my CMP labels it "necessary"?

Only if it genuinely meets the strictly-necessary test in ePrivacy Article 5(3): without it, the service the user explicitly requested cannot function. Most cookies labeled "necessary" by CMP defaults do not meet that test. Re-derive your necessary list against the regulation, not against the vendor's presets.

Do I need consent for analytics cookies in the EU?

In almost all cases, yes. The EDPB working position, echoed by the CNIL and most national DPAs, is that even server-side aggregated analytics need consent unless the exemption test is rigorously met — no third-party sharing, narrow stated purpose, no cross-site profiling. The bar is high enough that most teams should treat consent as the default.

What's the smallest fine likely if a regulator finds unauthorized cookies on my site?

There is no published floor. CNIL fines have started in the low six figures for SMEs and scaled to the hundreds of millions for global brands. The bigger practical risk for smaller operators is the DPA-imposed remediation deadline and the reputational cost — fines are the part that gets reported, not the only part that hurts.

Will Google Consent Mode v2 alone keep me compliant?

No. Consent Mode v2 is a signaling layer, not a compliance layer. It only works when upstream consent is valid and every tag is wired to the correct signals. Sites running Consent Mode v2 still leak unauthorized cookies whenever any tag bypasses the consent check.

How often should I scan for unauthorized cookies?

At minimum: after every CMP change, every third-party tool addition, and quarterly. Practically: continuously — third parties update their own cookies and SDKs without telling you, and new vendors get added by marketing teams without involving privacy.

Are pixels and local storage covered by the same rules as cookies?

Yes. ePrivacy Article 5(3) covers any storage of, or access to, information on a user's terminal device — cookies, tracking pixels, local storage, fingerprinting. The legal test is the same; the technical surface is broader than most teams audit.

If you have never opened DevTools on your own site to look for unauthorized cookies, that is the highest-leverage thing you can do this quarter. After that, point an independent scanner at it and let it watch over time. Run a free CookieSentry scan to get a baseline audit you can hand to your DPO, your legal counsel, or — if it ever comes to that — a regulator.