TDDDG § 25 in Germany: The Server-Side-Only Constraint

This is privacy research, not legal advice. See the footer for the full disclaimer.

TL;DR

§ 25 TDDDG is the binding constraint for any pan-European deployment. Configure for Germany; the rest of the EU composes upward.
Legitimate interest does not substitute for § 25 consent. The DSK Orientierungshilfe Version 1.2 of 20 November 2024 is unambiguous on this — and remains the operative guidance as of May 2026.
The only consent-free architecture is pure server-side processing with no cookie, no localStorage, no fingerprinting probes, no client-side identifier reads. § 25’s “Zugriff auf Informationen” reaches beyond cookies into any client-side data read.
A documented Article 6(1)(f) Legitimate Interest Assessment still has to exist for the GDPR processing layer that follows the server-side ingest — the LIA does not unlock a § 25 carve-out, but it grounds the personal-data processing.
Enforcement is active across BayLDA, NRW LDI, BlnBDI and HmbBfDI in 2024-2026 — targeting GA4 / Meta Pixel / Hotjar deployments without TDDDG-compliant consent. Maximum penalty: €300,000 per § 28(1) No. 13 plus GDPR Article 83 fines in parallel.

Why Germany is different

The 2026 EU map of consent-free analytics is not uniform. France’s CNIL has built a detailed audience-measurement carve-out — Italy’s Garante, Spain’s AEPD and the Netherlands AP have built their own. Germany has not. The Datenschutzkonferenz — the coordinated body of all 17 German data-protection regulators — confirmed in its Orientierungshilfe für Anbieter:innen von digitalen Diensten (Version 1.2, 20 November 2024) that § 25 TDDDG is lex specialis and only consent or strict necessity allows storage or access on a user’s terminal device. Legitimate interest under Article 6(1)(f) GDPR is not a valid alternative basis for the storage/access operation itself.

This makes Germany the binding constraint for any pan-European analytics deployment. An operator who configures for Germany is configured for everywhere else in the EU. An operator who configures only for France’s Sheet 16 still owes the German operator a separate, stricter answer.

The post that follows is the German answer. The rule itself, the May-2024 renaming, the narrow exemption, why “server-side-only” is the operating posture, the GDPR Article 6(1)(f) Legitimate Interest Assessment that nonetheless still has to exist, where Statnive Live lands, the German-language privacy-policy block an operator can paste, and the 8 privacy audit events that produce the accountability trail.

TDDDG, briefly

Germany’s Telekommunikation-Telemedien-Datenschutz-Gesetz entered force on 1 December 2021 as the TTDSG (the Federal Government’s transposition of ePrivacy Article 5(3) into national law). In May 2024, when Germany transposed the EU Digital Services Act, the statute was renamed to TDDDG — Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz. The substance was not changed; only the name reflected the broader DSA scope.

§ 25 is the operative cookie/storage provision and the direct transposition of Article 5(3) ePrivacy Directive 2002/58/EC (as amended by 2009/136/EC).

§ 25(1) TDDDG (English translation): “Storing information in the end user’s terminal equipment or accessing information already stored in the terminal equipment is only permitted if the end user has consented on the basis of clear and comprehensive information. The information to the end user and the consent shall be provided in accordance with Regulation (EU) 2016/679 [GDPR].”

§ 25(2) carves out only two cases:

(i) the sole purpose is to transmit a message via a public telecommunications network, and
(ii) the storage or access is absolutely essential to provide a digital service the user expressly requested.

That is the entire exemption. There is no audience-measurement carve-out in the German text. There is no equivalent of France’s Sheet 16, Italy’s 2021 Cookie Guidelines or Spain’s audience-measurement guide. § 25(2) covers the strictly-necessary cases — a shopping-cart cookie, an authentication session, a CSRF token — and that is the whole list.

Penalties under § 28(1) No. 13 and § 28(2) TDDDG run up to €300,000 per violation. GDPR fines under Article 83 (up to €20 million or 4% global turnover) apply in parallel for the personal-data-processing layer.

The DSK position and why legitimate interest does not save you

The Datenschutzkonferenz (DSK) — the coordinated body of Germany’s federal and state DPAs — published its Orientierungshilfe für Anbieter:innen von digitalen Diensten Version 1.2 on 20 November 2024. The guidance is unambiguous on two points.

Point one: § 25 TDDDG is lex specialis. For any storage or access on a user’s terminal equipment, the § 25 consent (or strict necessity) requirement governs. GDPR’s lawful-basis provisions in Article 6 do not provide an alternative basis for the storage/access operation itself.

Point two: legitimate interest cannot substitute for § 25 consent. Even if the operator has a perfectly documented Article 6(1)(f) Legitimate Interest Assessment, that LIA covers the processing of the personal data after it is collected — not the act of collecting it through terminal-equipment access. The two are governed by different layers and require different bases.

The practical effect: an analytics deployment that sets a cookie, writes to localStorage or reads a client-side identifier triggers § 25 TDDDG. The deployment needs consent. Full stop. No amount of “legitimate interest” reasoning recovers the consent requirement at the § 25 layer.

This is why the German position is so much stricter than France’s. The CNIL’s Sheet 16 carve-out interprets Article 5(3) ePrivacy with a defined audience-measurement exception built into the national transposition. Germany’s § 25(2) interprets Article 5(3) ePrivacy without that audience-measurement exception. Both interpretations are consistent with the underlying Directive; they simply land in different places within the Member-State discretion the Directive permits.

The single architecture that survives § 25 TDDDG without consent is one where the operator’s server does not store on or access information from the visitor’s terminal equipment. The browser sends only what it sends by default as part of an unavoidable HTTP request — IP, User-Agent, Referer headers. The server reads those headers, derives its analytics, and writes nothing back. No cookie. No localStorage. No fingerprinting probe. No client-side identifier construction. No instruction to the device to send additional information.

This falls outside § 25 TDDDG entirely. The Article 5(3) ePrivacy “storage or access on terminal equipment” trigger does not fire because no terminal-equipment interaction beyond the browser’s default request behaviour happens. EDPB Guidelines 2/2023 v2.0 explicitly covers this carve-out: where the operator does not instruct the device to send information and does not write to or read from device storage, Article 5(3) does not apply.

This is also the only consent-free architecture that satisfies all 27 Member States including the strictest ones. It is overkill for France; it is necessary for Germany. Operators with German traffic — even a small share — should design to the server-side-only baseline because the cost of architecting two stacks (one for Germany, one for everywhere else) almost always exceeds the cost of the unified strict baseline.

Bypassing § 25 TDDDG at the terminal-equipment layer does not eliminate the GDPR question. Once the server reads the IP, the User-Agent and the Referer from the request, it is processing personal data. The CJEU’s Breyer judgment (C-582/14, 19 October 2016) settled that a dynamic IP is personal data in the hands of a website operator. The User-Agent is a fingerprintable identifier on its own.

The lawful basis under GDPR Article 6 for this processing is realistically Article 6(1)(f) — legitimate interests — for first-party audience measurement. The DSK has accepted this position in its 2024 guidance, but only on the explicit condition that the § 25 TDDDG terminal-equipment-access requirement is independently satisfied (i.e. the strictly-necessary exception applies, or no terminal-equipment access happens). The server-side-only architecture meets that condition by construction.

The Legitimate Interest Assessment itself must be documented per EDPB Guidelines 1/2024:

Interest identification. Operating, improving and securing the controller’s website (the functional component recognised in Breyer paras. 60–64); measuring audience and content engagement (the commercial component recognised in CJEU C-621/22 KNLTB paras. 47–49, decided 4 October 2024).
Necessity. Audience measurement cannot reasonably be achieved by less intrusive means while producing the metrics needed. Minimisation: no persistent identifier; raw IP discarded before storage; daily-rotating, site-scoped salt; /24 IPv4 truncation; User-Agent reduced to major versions; referrer reduced to host only; aggregation to nearest 10.
Balancing. Data-subject interests: Charter Article 7 (private life) and Article 8 (data protection). Reasonable expectations: a visitor expects the operator to know aggregate visit counts and page popularity, not individual cross-day or cross-site surveillance — the architecture matches that expectation. Impact: minimal — no behavioural advertising, no profiling, no third-party sharing, no decisions affecting the data subject. Mitigations: salt destruction at end of day, IP truncation, retention cap, Article 21 opt-out, DPA in place where applicable, EU-only hosting, open-source code paths for self-hosted deployments.

The LIA is not a one-time exercise. The EDPB recommends annual refresh and on material change — for example, on a CJEU referral that affects the Breyer analysis, on the Digital Omnibus adoption, or on national German guidance updates.

Where Statnive Live lands

Statnive Live is built to satisfy § 25 TDDDG by construction. The operator’s configuration steps for a German site:

Select the DE jurisdiction. Statnive Live’s site-policy panel exposes an 11-jurisdiction enum. Selecting DE triggers the hard-rule validator.
The hard-rule validator forbids permissive. A German operator cannot select permissive mode — the validator refuses the save with the error: “Permissive consent mode is incompatible with § 25 TDDDG (Germany). Select consent-free or consent-required.” This is enforced at policy save and again at policy load on every ingest request, so the configuration cannot be changed out-of-band.
Default to consent-free. This turns off cookies, localStorage and fingerprinting in the tracker; activates the server-side daily-rotating BLAKE3-HMAC visitor signature; activates the host-only referrer transform; activates IP truncation; activates User-Agent minimisation. The architecture matches the § 25 TDDDG “no terminal-equipment storage or access” baseline.
Hashed cookie ID at rest, but no cookie set. When consent-free is active, no _statnive cookie is set on the browser. There is no cookie to hash at rest in that mode. (In consent-required or hybrid mode with consent given, a UUID is emitted to the browser; the server-side storage is SHA-256(master_secret || site_id || cookieID) with a h: prefix. The browser sees the raw UUID; the database never does.)
GPC and DNT honoured. In DE jurisdiction, consent.respect_gpc = true is the default. Visitors sending Sec-GPC: 1 are short-circuited before the visitor identifier is computed — no pseudonymous record is created for a declining visitor, so there is nothing to delete because nothing was written. The GPC and hybrid-mode post covers the end-to-end test plan.
DSAR endpoints honoured. POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase are exposed on every Statnive Live deployment regardless of jurisdiction. The German operator has the wiring even though, in consent-free mode, the volume of access and erase requests on a non-cookie deployment is intrinsically low — most visitors leave no per-visitor record at all once the salt rotates.
Public legal disclosure routes embedded in the binary. /privacy, /legal/privacy-policy/en, /legal/privacy-policy/de, /legal/lia and /legal/dpa are served by the same Go binary. The /legal/privacy-policy/de route serves the verbatim German clause described in the next section.

The eleven-jurisdiction enum (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU) and the four consent modes (permissive / consent-free / consent-required / hybrid) compose into 44 cells. The DE row has only two valid cells — consent-free and consent-required. The validator’s job is to prevent the other 22 cells from existing.

The German privacy-policy block

An operator running Statnive Live’s consent-free mode for a German site can serve the following clause at /datenschutz (or the equivalent legal page). The wording is the verbatim text from research-53 §08 and reflects the § 25 TDDDG analysis above.

Reichweitenmessung. Diese Website verwendet [Statnive Live] zur rein server-seitigen Reichweitenmessung. Es werden keine Cookies, kein Local Storage und keine vergleichbaren Technologien auf Ihrem Endgerät gespeichert oder ausgelesen. Insbesondere findet kein Zugriff im Sinne des § 25 Abs. 1 TDDDG statt. Verarbeitet werden ausschließlich Daten, die Ihr Browser für die Auslieferung der Seite ohnehin überträgt (IP-Adresse, Browser-Kennung in stark reduzierter Form, aufgerufene URL, Referrer-Domain). Wir kürzen Ihre IP-Adresse vor jeder weiteren Verarbeitung um das letzte Oktett und ersetzen sie durch eine pseudonymisierte Signatur, deren Salt nach 24 Stunden vernichtet wird.

Rechtsgrundlage. Soweit personenbezogene Daten im Sinne der DSGVO verarbeitet werden, stützt sich die Verarbeitung auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Eine Interessenabwägung gemäß EDSA-Leitlinien 1/2024 wurde dokumentiert.

Widerspruchsrecht gemäß Art. 21 DSGVO: [OPT-OUT-BUTTON].

The clause does three things at once. It tells the visitor what is happening (reine server-seitige Reichweitenmessung); it tells the regulator why § 25 TDDDG does not apply (no terminal-equipment storage or access); and it tells the data subject what the GDPR basis is (Article 6(1)(f) plus a documented LIA) and how to object (the Article 21 opt-out link).

It is not a substitute for the operator’s own privacy policy. The operator still owes a full notice covering the controller’s identity, the purposes, the categories of data, the retention period, the recipients, and the rights enumerated by GDPR Articles 13–22. The clause above slots into the Reichweitenmessung section of that broader notice.

The Article 21 opt-out is implemented in Statnive Live as a strictly-necessary cookie expressing the user’s choice — which is permitted under § 25(2)(ii) TDDDG because it implements the user’s expressly-requested service preference (the right to object). Alternatively, the opt-out can be persisted server-side via a suppression list keyed on the visitor’s h: signature with an adequate TTL.

The audit trail — 8 privacy events

Statnive Live emits 8 structured audit events covering the privacy-and-legal surface. These are the Article 28(3)(h) accountability evidence ready for a DPO or an auditor:

privacy.opt_out_received — an Article 21 objection has been registered.
privacy.dsar_access_requested — an Article 15 right-of-access request has been initiated.
privacy.dsar_erase_requested — an Article 17 right-to-erasure request has been initiated.
privacy.consent_given — statnive.acceptConsent() was called (relevant in consent-required and hybrid modes, not consent-free).
privacy.consent_withdrawn — statnive.withdrawConsent() was called.
legal.lia_viewed — the /legal/lia page was served.
legal.dpa_viewed — the /legal/dpa page was served.
legal.privacy_policy_viewed — the /legal/privacy-policy/{lang} page was served.

For a German consent-free deployment, the typical event mix is opt_out_received (low volume — most visitors never object because the architecture is unobjectionable), occasional dsar_*_requested (data-subject rights are technical-availability features regardless of mode), and a steady trickle of legal.*_viewed (transparency theatre tracking that visitors do read the policy pages).

The events emit to whatever log sink the operator’s environment supports — stdout/stderr in containerised deployments, syslog on traditional hosts, or a dedicated audit table in self-hosted setups. The audit events are structured JSON so they parse cleanly into Loki, Elasticsearch, or any structured-log pipeline.

The audit trail is what an operator points at if the Berlin DPA or the Bavarian BayLDA opens an inspection. The clause in the privacy policy is the public-facing position; the audit events are the contemporaneous evidence that the position is actually implemented.

What this gives a German operator

The practical outcome:

No cookie banner required for the audience-measurement workflow, on the basis that no terminal-equipment storage or access occurs at all — the strictest current European position satisfied by construction, not by ePrivacy-exemption interpretation.
A documented Article 6(1)(f) LIA as the GDPR basis for the personal-data processing the server does after reading IP, User-Agent and Referer at ingest. The LIA template is at /legal/lia; customise to the operator’s processing context with counsel.
A privacy-policy block that names § 25 Abs. 1 TDDDG and explains why it does not apply. The block lives at /legal/privacy-policy/de and is paste-ready into the operator’s /datenschutz page.
A configuration that satisfies all 27 Member States by deploying the strictest cell. Adding French traffic, Italian traffic or Dutch traffic does not require re-architecting; the existing configuration also qualifies for CNIL Sheet 16, the Garante’s 2021 Cookie Guidelines, the AEPD audience-measurement guide and the Dutch AP analytical-cookies position. The country-by-country map walks through the deltas.
Forward compatibility with the Digital Omnibus Article 88a(3)(c) proposal. If the Commission’s text is adopted intact, a consent-free Statnive Live deployment qualifies on day one.

What it does not give: the ability to set a German consent banner for free, or to run GA4 in Germany on a legitimate-interest basis. Neither is achievable; the DSK’s 2024 guidance closes both paths.

FAQ

Possibly — but not for audience measurement. A consent banner is required only for processing that triggers § 25(1) TDDDG (storage or access on the device) and falls outside § 25(2)(i)-(ii). That includes any third-party advertising cookies, retargeting pixels, social-share widgets that set cookies, embedded YouTube/Vimeo videos that set cookies on page load, A/B-testing variant cookies, and so on. For those purposes the operator owes a banner with a Reject-as-easy-as-Accept UX and the German Consent Management Ordinance recognition where applicable.

The audience-measurement layer — the visitor counts, the page popularity, the referrer analysis — does not need a banner under the conditions in this post. The operator chooses whether to consolidate analytics on the audience-measurement-only layer or to add a separate consent-gated layer for ecommerce attribution, A/B testing or marketing campaign attribution.

The German Consent Management Ordinance — Einwilligungsverwaltungsverordnung — was approved by the Bundesrat on 20 December 2024 and entered force on 1 April 2025 under § 26(2) TDDDG. It recognises Personal Information Management Services (PIMS); websites must honour signals from recognised consent-management services. The EinwV does not change the substantive § 25 rule — it adds a recognised-PIMS pathway for the consent the rule requires when consent is required.

For a consent-free deployment, the EinwV is largely irrelevant because no consent is being sought. For a consent-required or hybrid deployment, the EinwV recognition path is the long-term mechanism for honouring browser-level consent signals — see the GPC and hybrid-mode post for how Statnive Live implements browser-level signal handling today.

Does the BGH Planet49 judgment change anything?

The German Federal Court of Justice judgment in BGH I ZR 7/16 Planet49 (decided 28 May 2020, following CJEU C-673/17 of 1 October 2019) confirmed in German law that pre-ticked checkboxes do not produce valid consent and that opt-out approaches under the prior § 15(3) TMG were insufficient post-GDPR. The judgment reinforces the consent direction at § 25 — it does not weaken it. Operators who interpret BGH Planet49 as a softening of the German consent regime have misread the judgment.

Can I use legitimate interest for cookies in Germany if my LIA is very thorough?

No. The DSK’s 2024 guidance is explicit: legitimate interest does not substitute for § 25 TDDDG consent at the terminal-equipment-access layer. An exhaustively documented LIA is required for the GDPR Article 6 basis for the subsequent personal-data processing, but it does not unlock a cookie-storage carve-out at the § 25 layer. This is the consistent EDPB Opinion 5/2019 position and is reaffirmed by the UK ICO’s April-2026 Storage and Access Technologies guidance.

The way to satisfy German law without consent is to not write to the device in the first place. Architect the cookie out; the legitimate-interest question becomes the GDPR-Article-6-only question, not the § 25 question.

What to do, and what to skip

Do	Don’t
Select `DE` jurisdiction in Statnive Live; default to `consent-free` mode (the hard-rule validator enforces it).	Set a German site to `permissive` mode — § 25 TDDDG forbids it; the validator refuses the save.
Honour GPC and DNT by default in EU mode; short-circuit ingest before computing the visitor signature.	Treat cookieless analytics as automatically § 25-compliant — the DSK has confirmed that access to end-device information also triggers § 25, even without cookies.
Publish the verbatim Reichweitenmessung clause at `/datenschutz` naming § 25 Abs. 1 TDDDG and the Article 21 right of objection.	Claim “no consent banner needed in DE” without the documented LIA + privacy-policy disclosure. The DSK position requires both.
Document an Article 6(1)(f) Legitimate Interest Assessment per EDPB Guidelines 1/2024 for the personal-data processing the server does at ingest.	Rely on legitimate interest as a substitute for § 25 consent at the terminal-equipment-access layer. The DSK Orientierungshilfe Version 1.2 is unambiguous: it cannot.
Cross-reference with qualified German counsel — typically a Fachanwalt für IT-Recht — before publication.	Run GA4 / Meta Pixel / Hotjar pre-consent in Germany. BayLDA, NRW LDI, BlnBDI, and HmbBfDI have all sanctioned operators for it.

The bottom line

Germany’s § 25 TDDDG is the strictest current European position on terminal-equipment consent. There is no audience-measurement carve-out in German law, the DSK has confirmed legitimate interest does not substitute for the § 25 requirement, and the penalties run up to €300,000 per violation under § 28(1) No. 13 plus GDPR fines under Article 83.

The only consent-free architecture that survives Germany is one where no storage or access on terminal equipment happens. Statnive Live’s consent-free mode plus DE jurisdiction is exactly that architecture, enforced by a hard-rule validator that refuses to save a permissive German configuration. The privacy-policy block at /legal/privacy-policy/de names § 25 Abs. 1 TDDDG and the Article 21 right of objection. The 8 privacy audit events emit the contemporaneous accountability trail.

An operator who configures for Germany is, by construction, configured for the rest of the EU. The strict baseline composes upward. The 2026 EU Consent-Free Analytics Playbook is the broader frame; the CNIL Sheet 16 post is the French alternative; the country-by-country map walks the remaining Member States. The German operator’s path is the one this post described.

This is privacy research, not legal advice. Statnive Live, configured in consent-free mode for the DE jurisdiction with consent.respect_gpc = true and a documented Legitimate Interest Assessment, is architected to qualify as a no-terminal-equipment-storage-or-access deployment under § 25 TDDDG. The architecture removes the § 25(1) trigger; the LIA covers the GDPR Article 6(1)(f) basis for the subsequent processing. Every Statnive customer remains the data controller and bears responsibility for its own configuration and DPIA. Cross-reference with qualified German counsel — the DPO of record or a Fachanwalt für IT-Recht — before publication.

Status of regulatory references as of 13 May 2026: TDDDG (renamed from TTDSG 14 May 2024; no textual amendment to § 25 between then and May 2026); § 25 TDDDG; § 28(1) No. 13 TDDDG; DSK Orientierungshilfe für Anbieter:innen von digitalen Diensten Version 1.2 of 20 November 2024 (still operative; no successor version as of May 2026; confirms cookieless tracking also triggers § 25 when it accesses end-device information); Einwilligungsverwaltungsverordnung (EinwV) approved by Bundesrat 20 December 2024, effective 1 April 2025; BGH I ZR 7/16 Planet49 of 28 May 2020; CJEU C-673/17 Planet49 of 1 October 2019 (ECLI:EU:C:2019:801); CJEU C-582/14 Breyer of 19 October 2016 (ECLI:EU:C:2016:779); CJEU C-621/22 KNLTB of 4 October 2024 (ECLI:EU:C:2024:857); EDPB Guidelines 2/2023 v2.0 of 7 October 2024; EDPB Guidelines 1/2024 of 8 October 2024; draft EDPB Guidelines 01/2025 on Pseudonymisation (adopted as draft 16 January 2025; final not yet published as of May 2026); EDPB-EDPS Joint Opinion 2/2026 of 11 February 2026 on the Digital Omnibus; EDPB Opinion 5/2019. Continued 2024-2026 § 25 TDDDG enforcement by BayLDA / NRW LDI / BlnBDI / HmbBfDI against GA4 / Meta Pixel / Hotjar deployed without consent.