In short
A cookie banner is the consent interface that a website displays on the first visit in order to obtain users' permission for cookies and comparable access to their device. Legally, it is the technical implementation of § 25(1) TDDDG: without prior, informed consent, a website may not store anything on the device or read anything from it that is not strictly necessary.
Synonyms such as consent banner, cookie notice or consent layer refer to the same element. The software behind it is called a consent management platform (CMP): it shows the banner, stores the decision, blocks scripts until consent is given and documents everything verifiably. The term "cookie banner" is somewhat misleadingly narrow: the obligation to obtain consent does not depend on the cookie file format but on access to the terminal equipment. Local storage, session storage, device fingerprinting and pixels are covered in exactly the same way.
Legal basis: § 25 TDDDG and the GDPR interlock
In Germany, two levels have to be distinguished, and it is precisely this separation that is regularly overlooked in practice:
- Level 1, access to the device: regulated in § 25 TDDDG. Storing or reading is "only permitted if the end user has consented on the basis of clear and comprehensive information".
- Level 2, the subsequent processing of the data: regulated in the GDPR. Here you need a separate legal basis under Art. 6 GDPR, usually again consent under Art. 6(1)(a).
The TDDDG has had this name since 14 May 2024; before that it was the TTDSG. It was renamed in the course of the Digital Services Act (DDG), and in content § 25 has remained unchanged. If you read "§ 25 TTDSG" in older sources, the same provision is meant.
Why there is no legitimate interest for access to the device
The most common mistake in marketing departments: "Analytics runs on legitimate interest, doesn't it?" For data processing under the GDPR, Art. 6(1)(f) is in principle a conceivable legal basis, but not for access to the device under § 25 TDDDG. The provision knows exactly two options: consent or one of the two narrow exceptions in paragraph 2. There is simply no room for balancing there. Anyone who sets a tracking cookie without consent violates § 25(1) TDDDG, regardless of how cleanly the subsequent data processing is justified.
The two exceptions of § 25(2) TDDDG
Without consent, access is only permitted if it serves solely to transmit a message via a public telecommunications network, or if it is strictly necessary for the provider to be able to provide a digital service expressly requested by the user. "Strictly necessary" must be read strictly and assessed from the user's point of view, not from that of your marketing.
In an online shop, the following are typically undisputedly necessary: session ID, basket, login status, language setting, choice of currency, CSRF token, load balancing and a cookie that stores the consent decision itself. Not necessary are: reach measurement, A/B testing, conversion pixels, remarketing, embedded YouTube or Vimeo players, chat widgets from external providers and map services that transmit data to third parties when loading. When exactly you need consent under § 25 TDDDG and how to check your banner is shown in our practical guide.
What an effective cookie banner has to achieve
The requirements arise from § 25 TDDDG in conjunction with Art. 4(11), Art. 7 and Art. 13 GDPR. In practice this means:
- Informed: before the decision, it is clear which purposes are pursued, which providers are involved, how long cookies last and whether data flows to third countries.
- Voluntary: no compulsion, no disadvantages in case of refusal, no cookie wall without an alternative.
- Granular: consent per purpose or at least per group of purposes, not as an all-or-nothing package.
- Actively declared: no pre-ticked boxes, no "continuing to browse counts as consent", no scroll consent.
- Equally easy to reject: "Reject all" must be on the first level and just as easy to reach as "Accept all".
- Revocable: under Art. 7(3) GDPR, withdrawal must be as easy as giving consent; in practice, a permanently accessible link or a small widget in the footer.
- Verifiable: Art. 7(1) GDPR requires you to be able to prove consent. This includes timestamp, purposes selected, banner version and the consent text displayed.
- Effectively blocking: scripts that require consent are only loaded after consent, not before it and not "just with an opt-out flag set".
Dark patterns: where banners fail in practice
Most objections by supervisory authorities are not directed at missing banners but at manipulative design. Typical patterns and their clean alternative:
| Pattern in the banner | Why it is open to challenge | Clean implementation |
|---|---|---|
| "Accept" as a green button, "Settings" as a grey text link | Rejection cannot be reached equally easily, and voluntariness suffers | Two buttons of the same size, colour and position on level 1 |
| Rejection only on the second level | An additional click hurdle, expressly objected to by the Hanover Administrative Court | "Reject all" directly next to "Accept all" |
| Switch for statistics cookies activated in advance | No active action, violates Planet49 and the Federal Court of Justice ruling | All non-essential categories off by default |
| Banner shown again on every page view until accepted | Nudging, de facto compulsion to consent | Store the rejection for as long as consent |
| Scripts already load when the page is built, consent is only "remembered" | Access to the device has long since taken place | Blocking logic in tag management, scripts only after the consent event |
What the courts have decided
The guard rails have been in place for years. On 1 October 2019, the Court of Justice of the European Union ruled in Planet49 (C-673/17) that a pre-ticked checkbox does not constitute valid consent, regardless of whether the information stored is personal data. On the duty to inform, the Court also made it clear that users must be informed about the duration of the cookies and about access by third parties.
The German Federal Court of Justice followed on 28 May 2020: in the proceedings I ZR 7/16 ("Cookie-Einwilligung II"), an action under the Injunctions Act, it confirmed that pre-ticked consents are invalid under German law. For you as an operator, the procedural side of this case is almost as important as the substantive one: a faulty banner is not only an issue for the supervisory authority but can also be challenged by consumer associations.
Hanover Administrative Court 2025: Google Tag Manager and the reject button
The most practically relevant recent decision comes from the Hanover Administrative Court of 19 March 2025 (ref. 10 A 5385/22). The operator of a regional online news service had brought an action against an order of the data protection authority, and lost. You should know two points of the ruling:
First: Google Tag Manager itself requires consent. The court took the view that even retrieving the gtm.js script triggers access to the terminal equipment and that data is transmitted to Google, even if no tracking tag has yet been served via the Tag Manager. The widespread practice of loading the Tag Manager as "neutral infrastructure" before consent is therefore open to challenge.
Second: a banner without an equivalent option to reject on the first level is not permitted. The consent interface must not be designed in such a way that it deliberately steers users towards consent. For German operators, the debate about the "Reject all" button has therefore been practically decided.
Range of fines: what a faulty banner can cost
| Basis | Range | Responsibility |
|---|---|---|
| § 28(1) no. 13, (2) TDDDG (access without consent) | up to €300,000 | The Federal Commissioner (BfDI) for telecommunications providers and federal authorities, otherwise the state data protection authorities |
| Art. 83(5) GDPR (unlawful processing) | up to €20 million or 4% of worldwide annual turnover, whichever is higher | the competent state data protection authority |
| Injunctions Act / competition law | Injunction, costs of warning letters, contractual penalty | Consumer associations, competitors |
In reality, the risk is not the theoretical maximum amount but the effort: a complaint triggers an information procedure, the procedure ties up resources, and in the end there is usually an order with a deadline for changing things. That is exactly how the case before the Hanover Administrative Court went.
Technical implementation: blocking logic instead of an alibi banner
A banner that only asks for a decision but does not block any scripts is legally worthless and quickly exposed technically: a look at the network analysis in the browser's devtools before the click is enough. This order has proven effective:
- Inventory: capture all cookies, storage entries and outgoing requests, including fonts, maps, videos and chat widgets from third-party providers.
- Classification: assign each entry to one of the two categories: strictly necessary under § 25(2) TDDDG or requiring consent.
- Blocking: load scripts that require consent via the CMP's consent event, not via
document.writein the head. - Checking: open the page with an empty profile, reject, check the network log. After rejection, no more requests may go to analytics or ad domains.
- Documenting: store consent logs in an audit-proof way and reflect their retention in the deletion concept.
Cookie consent in Shopware 6
Shopware 6 comes with a cookie consent manager in the storefront that organises cookies in groups: technically required, comfort features and statistics. Plugins hook in with the CookieGroupCollectEvent and register their own cookies in the appropriate group; the earlier variant via the CookieProviderInterface has been marked as deprecated since 6.7.3.0.
More interesting than the API is an innovation from the same version: Shopware calculates a hash over the entire cookie configuration and stores it per language in the browser cookie cookie-config-hash. If a plugin changes the cookie landscape, the hash differs, and the banner is shown again on the next visit. This cleanly solves a requirement where many home-made solutions fail: if purposes or providers change, the old consent no longer holds. The division of responsibility remains important: the system provides the mechanism, but correctly classifying your cookies and wording the purposes remain your task.
Google Consent Mode v2 does not replace consent
Since 6 March 2024, Google Consent Mode v2 has effectively been a prerequisite for Google Ads and Analytics functions to work without restriction for users in the EEA. The requirement was triggered by the Digital Markets Act. Consent Mode is only a signalling protocol, though: it transmits parameters such as ad_storage and analytics_storage to Google tags. It does not obtain consent, does not check its validity and is not a legal basis. Anyone who implements Consent Mode but runs a banner without an equivalent reject button has a technically correct signal on top of invalid consent, and the violation remains. Conversely: if the signal is not passed on correctly, you lose measurability and campaign control even though you are working in a legally clean way. Both have to fit together, which is why we always set up consent configurations in digital marketing together with the tracking concept.
PIMS: consent management under the EinwV
With § 26 TDDDG, the legislator has created a way out of the flood of banners: recognised consent management services, often called PIMS (personal information management systems). The idea is that users set their preferences once centrally and websites query this decision instead of showing their own banner every time. The associated Consent Management Ordinance (EinwV) has been in force since 1 April 2025 and regulates recognition, the security concept and annual self-assessment.
In practice, the model has so far been a fringe phenomenon. As of August 2026, the public register under § 13 EinwV at the BfDI lists exactly one service: "Consenter", recognised on 17 October 2025. As long as use is not widespread, the classic banner remains the norm for you, but you should still keep an eye on developments.
Outlook: the Digital Omnibus is stuck
On 19 November 2025, the European Commission presented the Digital Omnibus proposal. Its data protection part would move the cookie rule from Art. 5(3) of the ePrivacy Directive into the GDPR, as a new Art. 88a, flanked by Art. 88b on machine-readable browser signals. Among other things, it provides for exceptions for low-risk purposes such as measuring your own reach, and a blocking period of around six months before users may be asked again after a refusal.
Decisive for your planning: this is a proposal, not applicable law. As of August 2026, the Council has no negotiating position; a compromise text from the Cypriot presidency was withdrawn at the end of June 2026 for lack of a qualified majority, and in the version of 18 June 2026 the article on machine-readable browser signals had already been deleted. In Parliament, procedure 2025/0360(COD) is at "Awaiting committee decision"; the draft committee report is dated 22 June 2026, and amendments were tabled until 27 July 2026. Anyone who postpones their consent set-up on the grounds that banners will soon disappear anyway is building on sand.
Do not confuse them: the AI omnibus and the data protection omnibus
The most common mistake in specialist articles is mixing up two projects that are both called "omnibus". The AI part was adopted long ago: Regulation (EU) 2026/1744 has been in force since 27 July 2026 and, among other things, postpones deadlines of the AI Act. It has nothing to do with cookies, § 25 TDDDG or consent banners. So if you read "the omnibus is in force, cookie banners will become easier", these are two different legal acts, and the one relevant to cookies is still in the legislative process.
Frequently asked questions about cookie banners
Does every website really need a cookie banner?
No. A website that only sets strictly necessary cookies and does not load any third-party resources does not need a consent banner, only a correct privacy policy. But as soon as reach measurement, map services, embedded videos or advertising pixels are involved, the banner is mandatory. The quickest self-test: open the browser's devtools, load the page in a private window and check which domains are contacted before any interaction.
Is "Accept all" plus "Settings" enough?
According to the line of the Hanover Administrative Court and the German supervisory authorities, no. Rejection must be reachable on the same level and with the same weighting as consent. A "Settings" link behind which rejection is hidden does not fulfil this.
How long does consent, once given, remain valid?
The TDDDG does not specify a fixed period. In practice, operators obtain consent again after 6 to 12 months. A new request is mandatory if purposes, providers or the tools used change; Shopware handles exactly this case via the configuration hash. Withdrawal must be possible at any time regardless.
May I lock out users who reject, or make them pay?
The so-called "consent or pay" model has not been conclusively clarified legally. The European Data Protection Board took a critical position in an opinion in 2024, but this opinion is not binding, and a final decision by the Court of Justice is still pending. For a shop of a mid-sized company, the model is generally neither necessary nor proportionate.
Who is liable if the agency installs the banner incorrectly?
The website operator remains the controller within the meaning of the GDPR. An agency or a CMP provider is a processor or service provider, which does not relieve you in relation to third parties. That is why classifying the cookies, approving the purpose texts and a documented test run before go-live belong in every project; for us, this is a fixed part of the work when we build custom systems with tracking and consent requirements.