IAB TCF v2.4: Was CMPs bis Oktober 2026 ändern müssen

IAB TCF v2.4 hat nun einen bestätigten Einführungsplan. IAB Europe plant, die endgültigen technischen Spezifikationen und die aktualisierte Global Vendor List (GVL) am 23. Juli 2026 zu veröffentlichen. CMPs haben dann bis zum 23. Oktober 2026 Zeit für Web-Implementierungen und bis zum 23. Februar 2027 für mobile App- und Connected-TV-Umgebungen. Wenn Ihr Consent-Stack am TCF teilnimmt, handelt es sich um ein Implementierungsprojekt – nicht nur um eine textliche Banner-Aktualisierung.

Die Änderungen verteilen sich auf TCF Policy v5.0.b und Technical Specifications v2.4. Sie betreffen, wie CMPs Features erläutern, den Umfang einer Auswahl offenlegen, geräteübergreifende Einwilligungen unterstützen und einen speziellen Anbieter-Signalisierungsfall codieren. Hintergrundinformationen zum aktuellen Framework finden Sie in Conzents IAB TCF Compliance-Übersicht.

Die wichtigsten Erkenntnisse

Die bestätigten Termine geben CMPs und Publishers eine kurze, aber handhabbare Abfolge vor: Prüfen Sie das finale Paket im Juli, schließen Sie Web-Änderungen im Oktober ab, und halten Sie Mobile und CTV in einem separaten Februar-Plan. Die wichtigsten Punkte sind:

• 23. Juli 2026: IAB Europe plant die Veröffentlichung der Technical Specifications v2.4 und das entsprechende GVL-Update.
• 23. Oktober 2026: CMPs müssen die neuen Offenlegungen in Web-Umgebungen implementieren.
• 23. Februar 2027: Die entsprechende Frist gilt für mobile App- und CTV-Umgebungen.
• CMP-Oberflächen benötigen klarere Standarderläuterungen und Illustrationen für Features.
• Die erste Schicht muss Nutzern mitteilen, ob eine Auswahl service-, gruppen- oder gerätespezifisch ist.
• Die technische Vorschau entfernt einen veralteten Legitimate-Interest-Workaround für Anbieter, die ausschließlich Special Purposes deklarieren; Teams sollten den finalen Wortlaut am 23. Juli prüfen.
• Die TCF-Teilnahme unterstützt Compliance-Arbeit, ersetzt aber nicht die eigene rechtliche Einschätzung eines Publishers oder Anbieters.

Die drei Termine für Ihren Lieferplan

IAB Europes Bestätigung vom 16. Juli 2026 legt drei separate Meilensteine fest. Sie alle als eine einzige Frist zu behandeln würde Discovery, Implementierung, Übersetzung und QA in dasselbe Release-Fenster pressen.

Die praktische Abfolge ist:

1. 23. Juli 2026 — Spezifikation und GVL-Veröffentlichung. Laden Sie die finalen Dateien herunter, vergleichen Sie sie mit dem öffentlich kommentierten Material und wandeln Sie jeden bestätigten Unterschied in eine zugewiesene Aufgabe um.
2. 23. Oktober 2026 — Web-Frist. Produktive Web-CMPs sollten die neuen Offenlegungen bereitstellen und die finalen v2.4-Signalisierungsanforderungen erfüllen.
3. 23. Februar 2027 — App- und CTV-Frist. Native SDKs, Store-Vorlaufzeiten, TV-Oberflächen und gerätespezifische Barrierefreiheitstests erhalten ein späteres Datum – keine Ausnahme.

Die Lücke zwischen Veröffentlichung und Web-Frist beträgt drei Monate. Das reicht für ein kontrolliertes Update, wenn Teams mit einem Spezifikations-Diff und einer Testmatrix beginnen. Es ist knapp, wenn die Arbeit erst mit einer späten Banner-Neugestaltung beginnt.

Die bestätigte Abfolge trennt das Quellmaterial, die Web-Implementierung und den App/CTV-Rollout. Planen und testen Sie sie als drei Meilensteine statt als einen einzigen Launch.

Wer handeln muss – und wer trotzdem aufmerksam sein sollte

Die Fristen gelten für aktive TCF-Implementierungen und die dafür verantwortlichen CMPs. Die offiziellen TCF Policies umfassen sowohl kommerzielle CMPs für Kunden als auch private CMPs, die ein Publisher für seine eigenen Angebote betreibt. Publisher bleiben für die Framework-Oberfläche auf ihren digitalen Angeboten verantwortlich, auch wenn ein Dritter die CMP bereitstellt.

Sie sollten diese Arbeit in einen Lieferplan aufnehmen, wenn Sie:

• eine registrierte TCF CMP aufbauen oder betreiben;
• eine kommerzielle CMP auf einer durch programmatische Werbung finanzierten Website nutzen;
• eine private Publisher-CMP pflegen;
• dasselbe Consent-Erlebnis über Web, App und CTV hinweg bereitstellen;
• auf TCF-Signale für Anbieter, Bidding, Measurement oder personalisierte Anzeigen angewiesen sind.

Eine Website, die nicht am TCF teilnimmt, ist nicht automatisch zur Implementierung von TCF v2.4 verpflichtet. Sie benötigt möglicherweise dennoch einen gültigen Einwilligungsmechanismus nach geltendem Recht oder Plattformregeln. Die Framework-Version und die gesetzliche Pflicht zur Einholung einer Einwilligung sind verwandte, aber keine identischen Fragen.

Diese Unterscheidung ist für Google Publisher-Produkte relevant. Google verlangt eine zertifizierte CMP mit TCF-Integration für personalisierte Anzeigen, die über AdSense, Ad Manager oder AdMob an Nutzer im EWR, im Vereinigten Königreich und in der Schweiz ausgeliefert werden. Google gibt außerdem an, dass die Zertifizierungsprüfung keine vollständige Konformität mit dem TCF oder dem anwendbaren Datenschutzrecht prüft.

Was Nutzer in einer CMP anders sehen werden

Die sichtbarste Änderung ist das Bestreben, Features verständlicher zu erklären. Im TCF beschreibt ein Purpose, warum Daten verarbeitet werden, und gibt dem Nutzer gegebenenfalls eine Einwilligungs- oder Widerspruchsmöglichkeit. Ein Feature beschreibt eine Verarbeitungsmethode, die zur Erfüllung eines oder mehrerer Purposes eingesetzt wird; es trägt nicht auf dieselbe Weise eine separate Nutzerkontrolle.

Gemäß Policy v5.0.b und dem bestätigten GVL-Update müssen CMPs Folgendes berücksichtigen:

• ein neues standardTexts-Feld mit der Standarderläuterung für Features;
• Illustrationen für jedes Feature in der aktualisierten GVL;
• die Standard-Feature-Erläuterung, die zusammen mit dem Standardnamen und dem vollständigen nutzerfreundlichen Text angezeigt wird;
• Feature-Informationen, die optisch nicht mit Steuerelementen verknüpft sind, die das Feature nicht tatsächlich deaktivieren können;
• einen neuen Namen und neue Leitlinien für Special Feature 2.

Der aktualisierte Name für Special Feature 2 lautet „Geräte auf Basis aktiv angeforderter Informationen identifizieren." Die Richtlinienvorgabe umfasst ausdrücklich Merkmale, die über JavaScript oder APIs gesammelt werden – wie Schriftarten, Bildschirmauflösung und Plugins – sowie aktiv über User-Agent Client Hints angeforderte Informationen. Nutzer müssen einwilligen, bevor ein Anbieter dieses Special Feature nutzen darf.

Warum das mehr als ein Textupdate ist

Eine CMP, die Labels fest kodiert oder die alte GVL-Struktur voraussetzt, könnte versagen, selbst wenn das Banner noch normal aussieht. Produktteams müssen die neuen Daten vom Eingang bis zu jeder UI-Schicht, Übersetzung, Barrierefreiheitsbezeichnung, gecachten Anbieteraufzeichnung und jedem Regressionstest verfolgen. Das sichere Designprinzip ist einfach: Geben Sie die offizielle Bedeutung korrekt wieder, machen Sie das Vorhandensein oder Fehlen einer Nutzerwahl unmissverständlich, und machen Sie aus einem erläuternden Feature keinen unechten Schalter.

Geräteübergreifende Einwilligung braucht einen expliziten Geltungsbereich

Policy v5.0.b fügt den geräteübergreifenden Geltungsbereich zu den Definitionen des Frameworks hinzu. Eine Rechtsgrundlage kann für denselben Dienst oder dieselbe Gruppe über mehrere Zugangspunkte hinweg gelten – zum Beispiel eine Website und eine mobile App, die von einem authentifizierten Konto genutzt werden – sofern die Implementierung diesen Geltungsbereich unterstützt. Die erste Schicht der Framework-Oberfläche muss dem Nutzer mitteilen, ob die Einwilligungsentscheidung service-, gruppen- und/oder geräteübergreifend gilt.

Diese Bequemlichkeit schafft eine Produktverantwortung. Eine CMP benötigt eine definierte Methode, um eine auf einem Gerät vor dem Login getroffene Entscheidung mit bereits im Konto gespeicherten Präferenzen abzugleichen. Sie muss außerdem sicherstellen, dass Ablehnung und Widerruf über denselben Geltungsbereich hinweg genauso einfach möglich sind wie eine Zustimmung.

CNILs geräteübergreifende Empfehlung vom Januar 2026 ist eine französische Regulierungsempfehlung und keine EU-weite TCF-Regel, stellt aber einen nützlichen Implementierungsmaßstab dar. CNIL empfiehlt:

• dass Akzeptieren, Ablehnen und Widerrufen dieselbe geräteübergreifende Reichweite haben;
• dass Nutzer vor der Auswahl darüber informiert werden, dass die Präferenz auf alle mit ihrem Konto verbundenen Geräte angewendet wird;
• dass eine kurze Erinnerung angezeigt wird, wenn der Nutzer sich auf einem neuen Gerät anmeldet;
• dass Konflikte transparent gehandhabt werden, entweder durch Priorisierung der jüngsten Entscheidung vor dem Login oder der Kontopräferenz.

Dokumentieren Sie die gewählte Konfliktregel und testen Sie beide Richtungen. Ein technisch konsistenter Präferenzspeicher kann dennoch ein irreführendes Erlebnis erzeugen, wenn Nutzern nicht mitgeteilt wird, welche Entscheidung Vorrang hat.

Was sich unter der Haube ändert

Das technische Paket ist für den 23. Juli geplant, daher sollten Implementierungsteams das aktuelle Material zur Vorbereitung nutzen – nicht so tun, als ob der finale Diff bereits verifiziert wäre. IAB Tech Labs Zusammenfassung des öffentlichen Kommentarverfahrens benennt zwei konkrete technische Bereiche.

Erstens erhält die GVL das standardTexts-Objekt für Feature-Erläuterungen. Parser, Typen, Caches, APIs und Rendering-Code müssen das neue Feld akzeptieren und erhalten. Ein graceful Fallback ist für die betriebliche Resilienz sinnvoll, darf aber nach Ablauf der Frist eine erforderliche Offenlegung nicht stillschweigend weglassen.

Zweitens entfernt die Vorschau einen Workaround für Anbieter, die ausschließlich Special Purposes deklarieren. Da TCF v2.3 das disclosedVendors-Segment verpflichtend gemacht hat, können diese Anbieter aus diesem Segment ableiten, ob sie offengelegt wurden. Die Vorschau entfernt daher die Anforderung, Anbieter ausschließlich mit Special Purposes in den Abschnitt „Vendor Legitimate Interest" des TC-Strings zu platzieren.

Eine umsichtige Implementierungsregel

Bereiten Sie Tests jetzt vor, binden Sie das Produktionsverhalten dann aber an den finalen v2.4-Text, der am 23. Juli veröffentlicht wird. Vergleichen Sie insbesondere die finale TC-String-Spezifikation, das CMP-API-Material, das GVL-Schema, Übersetzungen und Beispiele mit der Vorschau. Dokumentieren Sie die getestete Version. „Wir haben uns an den Juni-Artikel gehalten" ist kein brauchbarer Prüfpfad, wenn eine finale Spezifikation existiert.

Eine Sieben-Punkte-Checkliste zur TCF v2.4-Bereitschaft

Die Frist lässt sich leichter einhalten, wenn jede Anforderung einen Verantwortlichen und einen nachprüfbaren Abnahmetest hat. Beginnen Sie mit dieser Checkliste und erweitern Sie sie für Ihre Architektur.

1. Alle TCF-Oberflächen inventarisieren. Listen Sie Web-Angebote, eingebettete Erlebnisse, mobile Apps, CTV-Apps, Einwilligungseinstellungen, Konto-Präferenzzentren, SDKs und gecachte GVL-Verbraucher auf. Kennzeichnen Sie jedes als Web, App oder CTV für die Fristenplanung.
2. Das Release vom 23. Juli vergleichen. Vergleichen Sie die finale Spezifikation, das GVL-Schema, Übersetzungen, Illustrationen und Richtlinienverweise mit Ihrer aktuellen v2.3-Implementierung und der Vorschau aus dem öffentlichen Kommentarverfahren.
3. GVL-Erfassung aktualisieren. Stellen Sie sicher, dass standardTexts, Illustrationen, das umbenannte Special Feature 2 und zukünftige unbekannte Felder Parsing, Speicherung, APIs und Caching unbeschadet überstehen.
4. Die Benutzeroberfläche testen. Prüfen Sie, ob Feature-Erläuterungen neben den richtigen Informationen erscheinen, nicht wie Steuerelemente aussehen, bei Zoom und unterstützenden Technologien lesbar bleiben und in allen unterstützten Sprachen funktionieren. Überprüfen Sie das Cookie-Banner-Erlebnis als vollständigen Ablauf, nicht nur als erste Schicht.
5. Signalisierung testen. Erstellen Sie Fixtures für Anbieter ausschließlich mit Special Purposes und verifizieren Sie die finalen v2.4-Codierungs- und Decodierungsregeln für CMP, nachgelagerte Anbieter und jegliche serverseitige Einwilligungsverarbeitung.
6. Geräteübergreifendes Verhalten definieren. Dokumentieren Sie Geltungsbereich, Identitätsanforderungen, Speicherung, Übertragung, Widerruf und die Regel für Konflikte zwischen Geräte- und Kontoentscheidungen. Testen Sie Akzeptieren, Ablehnen, Ändern, Abmelden, neues Gerät und Kontolöschung.
7. Ausrollen und beobachten. Veröffentlichen Sie Web-Änderungen vor dem 23. Oktober mit Monitoring für GVL-Fehler, Consent-String-Fehler, fehlende Offenlegungen und ungewöhnliche Änderungen der Zustimmungsraten. Halten Sie App- und CTV-Releases in einem separat verwalteten Plan für den 23. Februar 2027.

Self-Hosting entbindet nicht von diesen Pflichten. Wenn Sie OCI auf Ihrer eigenen Infrastruktur betreiben, kontrollieren Sie das Upgrade-Fenster und können die Implementierung prüfen, tragen aber auch die Verantwortung für die finale Spezifikationsprüfung, den Rollout und die Verifikation.

Was Publisher ihren CMP-Anbietern fragen sollten

Publisher müssen nicht jede Parser-Änderung selbst implementieren, sollten aber „TCF-bereit" nicht als vollständige Antwort akzeptieren. Fordern Sie Belege an, die auf Ihre tatsächlichen Umgebungen und Termine bezogen sind.

Nützliche Fragen sind:

• Welche TCF Policy- und Technical Specification-Versionen laufen heute in der Produktion?
• Wann wird Web-Support für v2.4 allgemein verfügbar sein, und welche Kundenaktionen sind erforderlich?
• Wie werden die neuen Feature-Erläuterungen, Illustrationen und der Text von Special Feature 2 dargestellt und übersetzt?
• Unterstützt das Produkt den geräteübergreifenden Geltungsbereich, und wie werden widersprüchliche Entscheidungen genau aufgelöst?
• Welche Web-, App- und CTV-SDK-Versionen enthalten die Änderungen?
• Welche automatisierten und manuellen Tests decken das finale v2.4-TC-String-Verhalten ab?
• Müssen Nutzer die Framework-Oberfläche erneut sehen, und worauf stützt sich diese Entscheidung?

Bitten Sie den Anbieter, Framework-Compliance, Google-Zertifizierung und allgemeinen Datenschutz-Support zu trennen. Diese überschneiden sich, sind aber kein Beweis füreinander. Ihre eigenen Verantwortlichkeiten als Controller, Publisher und Anbieter erfordern weiterhin eine DSGVO-Compliance-Bewertung, die der von Ihnen durchgeführten Verarbeitung angemessen ist.

Was TCF v2.4 nicht bedeutet

TCF v2.4 ist ein Update eines Branchenframeworks – kein neues Gesetz und kein universelles Gebot für jede Website. IAB Europes eigene Richtlinie beschreibt die Teilnahme als freiwillig und stellt klar, dass das Framework kein Ersatz dafür ist, dass einzelne Teilnehmer Verantwortung für ihre rechtlichen Verpflichtungen übernehmen.

Halten Sie diese Grenzen in interner und kundenseitiger Kommunikation sichtbar:

• Das Einhalten der TCF-Frist macht einen Einwilligungsablauf nicht per se rechtmäßig;
• Google-CMP-Zertifizierung entspricht nicht vollständiger TCF- oder Datenschutz-Compliance;
• ein technisch gültiger TC-String beweist nicht, dass der Nutzer klare Informationen erhalten oder eine wirksame Entscheidung getroffen hat;
• geräteübergreifende Bequemlichkeit rechtfertigt keinen verborgenen Geltungsbereich oder eine einseitige Übertragung;
• ein neues Standard-Label behebt keine irreführende Oberfläche drumherum.

Holen Sie rechtlichen Rat für jurisdiktionsspezifische Schlussfolgerungen ein. Nutzen Sie Spezifikation, Richtlinie und Regulierungshinweise als separate Inputs für Produktanforderungen, anstatt sie zu einem vagen „Compliance"-Ticket zu verschmelzen.

Häufig gestellte Fragen

Was bedeutet IAB TCF?

IAB TCF steht für das IAB Europe Transparency and Consent Framework. Es standardisiert, wie teilnehmende Publisher, CMPs und Anbieter Datenverarbeitung offenlegen, relevante Entscheidungen erfassen und Einwilligungs-, Widerspruchs- und Transparenzsignale im digitalen Werbe-Ökosystem kommunizieren.

Was ist IAB TCF v2.3?

TCF v2.3 ist die technische Version unmittelbar vor v2.4. Unter anderem machte sie das disclosedVendors-Segment verpflichtend. Das ist für v2.4 relevant, weil der öffentliche Entwurf das verpflichtende Segment nutzt, um den älteren Legitimate-Interest-Workaround für Anbieter ausschließlich mit Special Purposes zu entfernen.

Was ist die TCF-Liste?

Der Begriff bezieht sich üblicherweise auf die Global Vendor List oder GVL. IAB Europe pflegt sie für registrierte TCF-Anbieter, und CMPs nutzen ihre Deklarationen, Standardtexte und zugehörige Daten, um Informationen bereitzustellen und Framework-Signale zu erzeugen. Der v2.4-Rollout beinhaltet ein entsprechendes GVL-Update, das für den 23. Juli 2026 geplant ist.

Muss jede CMP TCF v2.4 implementieren?

Nein. Die Fristen betreffen CMPs und aktive Installationen, die am IAB Europe TCF teilnehmen. Ein Consent-Tool außerhalb des TCF kann dennoch Verpflichtungen nach Datenschutzrecht oder Plattformrichtlinien haben, aber diese Verpflichtungen machen es nicht automatisch zu einem TCF-Teilnehmer.

Wann ist die TCF v2.4-Frist für CMPs?

Die bestätigte Frist ist der 23. Oktober 2026 für Web-Umgebungen und der 23. Februar 2027 für mobile App- und CTV-Umgebungen. Die Spezifikationen und das entsprechende GVL-Update sind für die Veröffentlichung am 23. Juli 2026 geplant.

Fazit

TCF v2.4 ist kein Anlass, jeden Consent-Ablauf neu zu gestalten. Es ist ein Anlass, die Teile zu überprüfen, auf die Nutzer und Anbieter sich verlassen: klare Feature-Erläuterungen, ehrlicher Geltungsbereich, reversible geräteübergreifende Entscheidungen und genaue Signale. Beginnen Sie mit den Dateien vom 23. Juli, testen Sie Web vor dem 23. Oktober, und halten Sie Mobile und CTV im Februar-2027-Plan. Ein dokumentierter, evidenzbasierter Rollout schlägt ein überstürztes Banner-Update allemal.