Kurzantwort: IAB Europe hat TCF 2.4 am 23. Juli 2026 veröffentlicht. Web-Implementierungen müssen bis zum 23. Oktober 2026 umgestellt sein; für Mobile Apps und CTV gilt der 23. Februar 2027. Die TC-String-Formatversion bleibt 2 und die TCF-Policy-Version bleibt 5. TCF 2.4 führt deshalb kein pauschal neues Stringformat ein. Entscheidend sind die aktualisierten Richtlinien, insbesondere die strengere Behandlung des berechtigten Interesses von Vendoren.
Das Wichtigste in Kürze
- TCF 2.4 ist die aktuelle Spezifikation; die Umstellungsfrist ist nach Umgebung getrennt.
- Web: 23. Oktober 2026. Mobile App und CTV: 23. Februar 2027.
- Die binäre TC-String-Version bleibt 2;
tcfPolicyVersionbleibt 5. - Bereits gültige Einwilligungen erfordern nicht allein wegen der Versionsbezeichnung pauschal eine erneute Einwilligung. Eine erneute Abfrage kann aber aus anderen Gründen nötig sein, etwa bei geänderten Vendoren, Zwecken oder Rechtstexten.
- Das Segment
DisclosedVendorswurde mit TCF 2.3 verpflichtend und wird unter 2.4 fortgeführt. Es ist keine neue 2.4-Funktion. - Vendoren dürfen berechtigtes Interesse nicht allein aufgrund von Special Purposes signalisieren. Diese 2.4-Regel ist bereits seit April 2026 anzuwenden.
- Registrierung und Zertifizierung sind verschiedene Aussagen. Prüfen Sie außerdem, für welche Umgebung eine CMP registriert ist.
Was ändert sich mit IAB TCF 2.4?
TCF 2.4 aktualisiert die Richtlinien und technischen Vorgaben des Transparency and Consent Frameworks. Für Implementierende ist besonders wichtig, Versionsnummern nicht mit den Feldern im TC-String zu verwechseln: Das Core-Segment verwendet weiterhin die Formatversion 2, und die Policy-Version bleibt 5. Integrationen dürfen daher weder eine erfundene Stringversion „2.4“ kodieren noch allein wegen des Versionswechsels alle vorhandenen Signale verwerfen.
Die praktisch wichtigste Änderung betrifft Vendor Legitimate Interest. Ein Vendor darf ein LI-Bit nur setzen, wenn dafür mindestens ein zulässiger Verarbeitungszweck vorliegt. Special Purposes allein reichen nicht aus. CMPs müssen diese Invariante beim Erzeugen, Wiederherstellen und Widerrufen von Signalen durchsetzen.
Disclosed Vendors: in 2.3 eingeführt, in 2.4 weiterhin erforderlich
Das DisclosedVendors-Segment dokumentiert, welche Vendoren der Person tatsächlich angezeigt wurden. Es wurde mit TCF 2.3 verpflichtend und bleibt Teil einer korrekten 2.4-Implementierung. Bei der Migration auf 2.4 sollte das Segment daher nicht neu erfunden, sondern gegen die sichtbare Vendorliste geprüft werden:
- Jeder im Segment enthaltene Vendor muss in der Consent-Oberfläche offengelegt worden sein.
- Nicht angezeigte, gelöschte oder nicht aktive Vendoren dürfen nicht als offengelegt signalisiert werden.
- Die Vendor-Menge in Konfiguration, Oberfläche,
DisclosedVendorsundTCDatamuss nachvollziehbar zusammenpassen.
Fristen nach Umgebung
| Umgebung | Umstellungsfrist auf TCF 2.4 |
|---|---|
| Web | 23. Oktober 2026 |
| Mobile App | 23. Februar 2027 |
| CTV | 23. Februar 2027 |
Eine Web-Registrierung deckt Mobile Apps oder CTV nicht automatisch ab. Prüfen Sie den Eintrag der CMP in der offiziellen CMP-Liste und die dort genannten Umgebungen. Biscotti CMP wird von der Campcruisers GmbH betrieben und ist mit CMP-ID 497 für Web registriert. Eine Native-App- oder CTV-Registrierung wird damit nicht behauptet.
Schrittweise Migration auf TCF 2.4
1. Registrierungs- und Umgebungsstatus prüfen
Vergleichen Sie CMP-ID, Rechtsträger und registrierte Umgebungen mit der offiziellen CMP-Liste. Verlassen Sie sich nicht auf ein Logo oder eine allgemeine Formulierung wie „IAB-konform“.
2. Aktuelle GVL und Vendor-Auswahl binden
Laden Sie eine aktuelle Global Vendor List und bestimmen Sie die Vendoren, die für die konkrete Website oder App tatsächlich eingesetzt werden. Die Oberfläche und der erzeugte Consent-Status müssen aus derselben Vendor-Menge abgeleitet werden.
3. Vendor-LI-Regel fail-closed umsetzen
Erzeugen Sie kein Vendor-LI-Signal, wenn der Vendor nur Special Purposes deklariert oder kein zulässiger LI-Zweck verbleibt. Prüfen Sie diese Regel auch nach Reject, Widerruf, GVL-Wechsel und Wiederherstellung eines gespeicherten Zustands.
4. TC-String-Semantik beibehalten
Kodieren Sie weiterhin TC-String-Formatversion 2 und Policy-Version 5. Behalten Sie das verpflichtende DisclosedVendors-Segment bei. Ändern Sie keine API-Versionsfelder nur deshalb, weil die Framework-Spezifikation 2.4 heißt.
5. Reconsent gezielt entscheiden
Ein Versionswechsel allein ist kein pauschaler Reconsent-Grund. Prüfen Sie stattdessen, ob sich Zwecke, Vendoren, Rechtsgrundlagen, Publisher Restrictions oder die gegenüber der Person angezeigten Informationen wesentlich geändert haben. Dokumentieren Sie die Entscheidung.
6. Vollständige Zustandsübergänge testen
Testen Sie mindestens Accept All, Reject All, granulare Auswahl, berechtigtes Interesse, Widerruf, erneutes Öffnen, Browser-Neustart und eine GVL-Aktualisierung. Dekodieren Sie die erzeugten Strings unabhängig und vergleichen Sie Vendor- und Purpose-Sets.
Technische Prüfliste
__tcfapi('ping', 2, ...)meldet konsistente CMP- und Policy-Daten.- TC-String-Formatversion ist 2 und
tcfPolicyVersionist 5. DisclosedVendorsentspricht der tatsächlich sichtbaren Vendorliste.- Vendor-LI wird ohne zulässigen LI-Zweck niemals gesetzt.
- Reject und Widerruf entfernen unzulässige Consent- und LI-Signale.
- Gespeicherte Zustände werden nur übernommen, wenn sie zur aktuellen Konfiguration passen.
- CMP-ID und registrierte Umgebung stimmen mit der öffentlichen CMP-Liste überein.
- Web-, Mobile-App- und CTV-Releases werden getrennt freigegeben.
Müssen bestehende Nutzer erneut gefragt werden?
Nicht automatisch. Die Versionsbezeichnung TCF 2.4 ändert weder allein das TC-String-Format noch die Policy-Versionszahl. Eine erneute Einwilligung ist jedoch erforderlich, wenn die bisherige Entscheidung die aktuelle Verarbeitung nicht mehr zutreffend abbildet oder die Person neue wesentliche Informationen erhalten muss. Die Entscheidung sollte anhand der tatsächlichen Konfigurationsänderung und mit rechtlicher Beratung getroffen werden.
Häufige Fehler
- TCF 2.4 als neue TC-String-Formatversion zu kodieren.
tcfPolicyVersionohne normative Grundlage zu erhöhen.- Disclosed Vendors fälschlich als neue 2.4-Änderung zu beschreiben.
- Special Purposes als ausreichende Grundlage für Vendor-LI zu behandeln.
- Eine Web-Registrierung als Mobile-App- oder CTV-Registrierung darzustellen.
- „registriert“, „validiert“ und „zertifiziert“ synonym zu verwenden.
- Nur den Accept-All-Pfad zu testen und Reject, Widerruf oder Neustart auszulassen.
Fazit
Die Umstellung auf TCF 2.4 ist keine reine Textänderung. Sie verlangt eine nach Umgebung geplante Freigabe, korrekte Vendor-LI-Signale und den Nachweis, dass sichtbare Vendoren, gespeicherter Zustand und TC-String übereinstimmen. Wer Formatversion 2, Policy-Version 5 und die Historie von Disclosed Vendors korrekt auseinanderhält, vermeidet die häufigsten Migrationsfehler.
FAQ
Ist TCF 2.4 eine neue TC-String-Formatversion?
Nein. Das Versionsfeld des TC-Strings bleibt 2; die Framework-Version 2.4 darf nicht in dieses Feld geschrieben werden.
Ändert sich die TCF-Policy-Version?
Nein. Für TCF 2.4 bleibt tcfPolicyVersion bei 5.
Sind Disclosed Vendors neu in TCF 2.4?
Nein. Das Segment wurde mit TCF 2.3 verpflichtend und wird in 2.4 fortgeführt.
Erfordert TCF 2.4 immer Reconsent?
Nein. Maßgeblich sind die tatsächlichen Änderungen an Verarbeitung und Nutzerinformation, nicht allein die Versionsnummer.
Ist Biscotti CMP für Mobile Apps oder CTV registriert?
Der aktuelle Registereintrag der Campcruisers GmbH, CMP-ID 497, umfasst Web. Daraus folgt keine Registrierung für Mobile Apps oder CTV.
Quellen
- IAB Europe, TCF Policies v5.0.b und Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, CMP-Liste: https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, Consent String and Vendor List Formats: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Dieser Beitrag erläutert technische und organisatorische Gesichtspunkte und ist keine Rechtsberatung.