TCF for Publishers: Implementing IAB's Transparency & Consent Framework (2.2 and 2.3)

Why TCF Matters to Publishers

If you monetise your site with programmatic advertising, the IAB Europe Transparency & Consent Framework (TCF) is almost certainly part of your compliance stack — whether you chose it deliberately or inherited it through your ad partners. The TCF is the advertising industry’s standardised system for collecting, encoding, and transmitting user consent across the programmatic supply chain, so that hundreds of ad-tech vendors can read a single, interoperable consent signal.

This guide is written for publishers: what the framework requires of you, what changed in TCF 2.2, and what the more recent TCF 2.3 update means in practice (including a concrete deadline). If you want the conceptual foundation first — what a TC String is, what the Global Vendor List does — read what is TCF and what a CMP is, then return here for the publisher-specific detail.

How the Framework Works, Briefly

The TCF connects three roles. Publishers run a registered Consent Management Platform (CMP) that shows the consent UI and records the user’s choices. The CMP encodes those choices into a compact TC String and exposes it through a standard JavaScript interface (__tcfapi). Vendors registered on the Global Vendor List (GVL) — the public registry of ad-tech companies and the purposes they process data for — read that string to decide whether they have a legal basis to operate.

For you as a publisher, the practical upshot is that your CMP is the single point that determines whether your ad stack can legally personalise and measure. Get the CMP configuration right and the rest of the chain receives a clean signal; get it wrong and you risk either lost revenue (vendors withholding bids) or compliance exposure.

What TCF 2.2 Changed

TCF 2.2 was a substantial overhaul aimed at making consent genuinely informed and at addressing regulatory criticism of the framework. The changes that matter most to publishers are:

• Legitimate interest removed for advertising purposes. Vendors can no longer rely on legitimate interest as the legal basis for Purposes 3, 4, 5, and 6 — the purposes covering personalised advertising and content profiling. These now require explicit consent. This materially raised the bar: a user who declines can no longer be served personalised ads under a legitimate-interest claim.
• Vendor count on the first layer. CMPs must disclose the total number of vendors seeking a legal basis directly on the first layer of the consent UI, so users see the scale of data sharing before they decide.
• Clearer, jargon-free language. Purpose names and descriptions were rewritten in plainer language, with standardised illustrations of how data is used.
• Vendor transparency. Vendors must declare additional information about their processing, including a dedicated URL describing their legitimate interests, surfaced through the CMP’s secondary layers.
• Easy withdrawal. Users must be able to re-open the CMP and withdraw consent as easily as they gave it.

What TCF 2.3 Changes — and the Deadline

TCF 2.3 is a narrower, more technical update than 2.2, but it carries a hard deadline. Its central change is making the disclosedVendors segment of the TC String mandatory. Previously optional, this segment removes an ambiguity in how vendors interpret legitimate-interest signals: without it, a vendor could not reliably tell “this vendor was not disclosed to the user” apart from “the user objected.” Making the segment mandatory resolves that.

The timeline is concrete:

• Before 1 March 2026: TC Strings created without the disclosedVendors segment remain valid during the transition.
• From 1 March 2026: TC Strings created without the disclosedVendors segment become invalid, and vendors must act on the segment.

The good news for most publishers: if you use a commercial, properly maintained CMP, this is largely handled for you — it is a CMP/TC-String implementation detail, and no re-surfacing of your consent UI is required. The action item is simply to confirm your CMP has shipped TCF 2.3 support ahead of the deadline.

TCF and Google Consent Mode: Two Different Things

Publishers frequently conflate the TCF with Google Consent Mode, but they solve different problems and you often need both. The TCF communicates consent to the IAB programmatic ecosystem via the TC String. Google Consent Mode communicates consent to Google’s own tags (Ads, GA4) via consent signals. A certified CMP typically emits both from the same user choice, so a single banner interaction satisfies the IAB supply chain and Google’s tag behaviour simultaneously.

If you run Google tags alongside programmatic demand, make sure your CMP is configured to drive both. See Google Consent Mode v2 for how the Google side works.

Common Publisher Pitfalls

• Treating advertising purposes as legitimate interest. Post-2.2, Purposes 3-6 need consent. Configurations carried over from older setups may still assume legitimate interest and quietly under-serve consented demand or, worse, over-claim a basis you no longer have.
• An unmaintained or uncertified CMP. Only CMPs registered with IAB Europe may participate, and they must keep pace with framework versions. An out-of-date CMP is a compliance and revenue risk.
• Ignoring non-TCF visitors. TCF governs the ad supply chain, but you still owe every visitor a lawful consent experience under GDPR and the ePrivacy Directive. TCF compliance is not a substitute for a sound overall banner — cross-check the GDPR cookie compliance checklist.
• Poor first-layer design. The framework sets requirements, but consent rates still depend on UX. Apply cookie banner design best practices within the TCF constraints.

Authoritative Sources

• IAB Europe: Transparency & Consent Framework
• IAB Europe: TCF 2.2 launches — all you need to know
• IAB Europe: Transition to TCF v2.3
• ePrivacy Directive (2002/58/EC) on EUR-Lex