IAB TCF v2.3: What Publishers Must Do by February 2026

Since the introduction of GDPR, few changes have reshaped the digital advertising ecosystem as fundamentally as the IAB Transparency and Consent Framework. Following the policy-focused TCF 2.2, IAB Europe has released the Transparency and Consent Framework (TCF) v2.3.

For publishers monetising via Google Ad Manager, AdSense, or AdMob, this update is critical. Failure to migrate by the 28 February 2026 deadline will result in valid consent strings becoming invalid, causing ad requests to default to “Limited Ads” and potentially slashing programmatic revenue by over 50%.

While TCF 2.2 focused on policy (removing legitimate interest for advertising), TCF v2.3 focuses on proof. It introduces a mandatory technical mechanism to verify that vendors were actually disclosed to users, closing a significant compliance gap.

This guide provides an in-depth analysis of the technical changes, the implementation roadmap, and how CookieYes automates this complex transition for you.

TCF v2.3 is the latest iteration of the industry standard for capturing, managing, and signalling user consent. Released on 19 June 2025, it was developed to resolve “signalling ambiguity”, a technical blind spot regarding vendor disclosures that left the ad tech supply chain vulnerable to GDPR challenges.

IAB Europe’s explanation is specific: in TCF v2.2, certain vendors could not reliably tell whether:

• They were not disclosed in the CMP UI, or
  
• The user objected (for scenarios where the Legitimate Interest bit was set to 0)
  

That uncertainty matters most when vendors intend to process data for Special Purposes under Legitimate Interest and cannot infer disclosure from existing signals.

So, TCF v2.3 resolves the ambiguity by making disclosedVendors mandatory.

The core problem TCF v2.3 solves: “ghost vendors” and disclosure ambiguity

In TCF v2.2, vendors could receive a consent string but still lack a reliable way to prove they were actually disclosed in the Consent Management Platform (CMP) interface the user saw.

Here’s the “ghost vendor” scenario in plain terms:

• A user objects to a vendor’s Legitimate Interest (LI) for certain processing, so the CMP generates a 0 signal.
• The vendor receives that 0, but can’t tell what it really means:
  • Did the user see the vendor and actively object?
  • Or was the vendor never shown at all in the CMP UI (a “ghost vendor”)?

This ambiguity becomes risky when vendors rely on Legitimate Interest for Special Purposes (such as fraud prevention or security). Those uses still require transparency, so if a vendor processes data without having been disclosed, they risk violating GDPR.

The solution in TCF v2.3: “mathematical proof of disclosure” in the TC string

TCF v2.3 fixes the guesswork by making the disclosedVendors segment mandatory in every TC string. This creates a binary, verifiable disclosure signal that tells vendors whether they were disclosed in the CMP UI.

In practice:

• 1 = the vendor was disclosed to the user in the CMP interface
• 0 = the vendor was not disclosed

After the transition, vendors affected by the previous ambiguity must check their bit. If it’s 0, they must not process data for Special Purposes, because transparency was not established.

From IAB Europe:

• TC strings created before 28 February 2026 without disclosedVendors remain valid after that date
  
• TC strings created after 28 February 2026 without disclosedVendors will be considered invalid
  

From Google Ad Manager:

• The mandatory deadline for publishers and CMPs is February 28, 2026
  
• TCF v2.3 is mandatory for all TC strings generated on or after that date
  

If you want a simple rule: make sure your CMP is writing v2.3 strings well before February 2026 so you have time to test.

Google has fully aligned its EU User Consent Policy with the TCF v2.3 standard. If you monetise traffic from the EEA, UK, or Switzerland, this update is mandatory for maintaining programmatic access.

• Programmatic bidding: Real-Time Bidding (RTB) relies on the consent string to tell bidders if they are allowed to bid. If the string is invalid (missing the 2.3 disclosure segment), premium bidders, including Google, will simply not bid.
• “Limited Ads” risk: Without a valid TCF 2.3 string, Google may serve “Limited Ads.” These ads do not use cookies for personalisation or frequency capping, resulting in significantly lower engagement and revenue.

Google provides a clear rollout window:

• Support is live now: Google can accept and process TCF v2.3 strings immediately, and you should begin migration as soon as possible
  
• Transition period: now—end of February 2026: Google treats v2.3 strings the same as v2.2 and will not validate the disclosed vendor segment, giving you a safer test window
  
• Final deadline: 28 February 2026: support for new TCF v2.2 strings is dropped; v2.3 becomes mandatory for strings generated on or after this date
  

And Google’s warning is direct: if you miss it, the ad request may be defaulted to Limited Ads, which may impact revenue.

Often, no.

IAB Europe states CMPs should not be required to re-surface the UI for this change. For publishers using a commercial CMP, IAB Europe also notes you should not be affected by the transition because there is no re-surfacing requirement tied to this update.

There is one important edge case:

• If your CMP kept records of which vendors were disclosed when a TC string was created, it may update existing strings (and IAB notes the lastUpdated field should not change in that case).
  
• If your CMP did not keep disclosure records, it should wait for the user to renew or change choices to create a new TC string including disclosedVendors.

Here is a detailed compliance checklist to ensure your transition to TCF v2.3 is seamless and audit-proof.

• Update your CMP: Ensure your Consent Management Platform supports TCF 2.3 signal generation. This is the baseline requirement for creating valid consent strings.
• Enable the “disclosed vendors” segment: Verify that your CMP populates the mandatory disclosedVendors segment (a binary 0/1 signal) in the TC string to prove vendors were shown to the user.
• Verify Google certification: Confirm your CMP is Google-certified for TCF 2.3. Using a non-certified platform will block you from Google Ad Manager and AdSense.
• Sync with the GVL: Configure your CMP to download the Global Vendor List (GVL) on a regular basis so vendor IDs and legal bases remain current.

• Display vendor count: Your banner’s first layer must state the exact number of vendors seeking data access (e.g., “We and our 142 partners”).
• Use plain language: Replace legal jargon with user-friendly descriptions and illustrative examples for all data processing purposes.
• Ensure easy re-access: Provide a persistent link (e.g., “Privacy Settings”) in the footer or a floating button so users can easily modify their consent choices.

• Audit your vendor list: Remove inactive vendors to reduce TC string size and improve page load speed.
• Check GVL participation: Ensure every partner is registered on the TCF 2.3 Global Vendor List; unregistered vendors cannot process valid consent signals.
• Match UI to string: Verify that the vendors listed in your banner match exactly with those marked as “disclosed” in the generated consent string.

Migrating to a new framework shouldn’t require a dedicated engineering team. CookieYes automates the entire TCF 2.3 transition for you.

• Automatic upgrades: We automatically update our string generation logic to include the mandatory disclosedVendors segment. You don’t need to change your code.
• Certified integration: As a Google-certified CMP, we ensure your signals are perfectly formatted for Google Ad Manager, AdSense, and AdMob.
• Compliance by design: Our banners are pre-configured with the mandatory vendor counts and user-friendly text, ensuring you meet the visual requirements of TCF 2.3 without manual design work.
• Seamless vendor management: We provide an easy-to-use interface for managing your GVL.