IAB TCF v2.4 is the latest version of IAB Europe's Transparency and Consent Framework. It changes how consent banners explain Features, renames Special Feature 2, adds rules for consent shared across devices, and removes an old legitimate interest workaround. CMPs must implement it on websites by 23 October 2026, and in mobile apps and on connected TV (CTV) by 23 February 2027.
This guide is for publishers and site owners who run ads through TCF vendors in Europe. It covers what changed from v2.3, what stayed the same, what to check on your site, and how to turn on TCF v2.4 in CookieYes.
What is IAB TCF v2.4?
IAB TCF v2.4 combines TCF Policies v5.0.b with Technical Specifications v2.4. IAB Europe released the policies on 29 May 2026, and the specifications were published with an updated Global Vendor List (GVL) on 23 July 2026.
The update is incremental. It focuses on what users see in the banner, particularly Features, rather than on how consent is encoded. The consent string (TC string) keeps the same version 2 format.
New to the framework? Start with what IAB TCF is and how it works.
TCF v2.4 deadlines
The deadlines apply to CMPs, and IAB Europe asks participants to make sure their live installations comply by each date.
| Date |
Milestone |
| 29 May 2026 |
TCF Policies v5.0.b released and public comment on the specifications opens |
| 23 July 2026 |
Technical Specifications v2.4 and the updated GVL published |
| 23 October 2026 |
Deadline for CMPs to implement the new disclosures on websites |
| 23 February 2027 |
Deadline for CMPs in mobile apps and CTV |
For publishers, the practical deadline is the same: the CMP running on your live site must support v2.4 by 23 October 2026. IAB Europe's confirmed v2.4 timeline sets out the dates.
What changed in IAB TCF v2.4?
Most of the changes concern Features: means of processing that vendors use in pursuit of purposes. Users make choices about purposes, not Features, which is why v2.4 adds text and pictures to explain them.
| Change |
What it means |
Who acts |
| Standard Feature explanation |
Banners show set text explaining that Features can only be used for purposes the user has a choice about |
CMP |
| Feature illustrations |
Each Feature gets illustrations, supplied through the GVL |
CMP |
| Special Feature 2 renamed |
New user-facing name and updated vendor guidance |
CMP and vendors |
| Cross-device consent |
Rules for telling users when their choices apply across devices |
Publisher and CMP |
| Legitimate interest workaround removed |
Vendors that declare only Special Purposes no longer need a legitimate interest bit |
CMP and vendors |
Features now come with a standard explanation
CMPs must display a standard explanation alongside Features. It clarifies that Features are means of processing that can only be used for purposes the user is given a choice about [1]. The text arrives through a new standardTexts field in the GVL, with translations.
Features also can't be shown next to controls that can't be disabled, so the banner doesn't suggest a choice that doesn't exist.
Every Feature gets illustrations
Version 2.4 adds illustrations for each Feature to help users understand what the processing looks like in practice. They're delivered through the updated GVL, so CMPs pull them in rather than writing their own.
Special Feature 2 has a new name
IAB Europe found the previous name unclear, so Special Feature 2 has been renamed. Its vendor guidance now also covers actively requesting Client Hints to create a device fingerprint.
| Version |
Name shown to users |
| Before v2.4 |
Actively scan device characteristics for identification |
| From v2.4 |
Identify devices based on information actively requested |
As with every Special Feature, vendors need the user's opt-in, which the TC string records as a separate bit.
New rules for consent shared across devices
Some publishers carry a user's privacy choices across devices, for example when the user logs in to an account. Following the French regulator CNIL's recommendations on cross-device consent, the policies now give publishers room to do this.
If you persist choices across devices, you must tell users the scope of those choices. The policies also give you flexibility when signals conflict, such as when a choice made before logging in differs from the one stored on the account.
The legitimate interest workaround is gone
In TC strings created before 1 March 2026, CMPs set the vendor legitimate interest bit to 1 for vendors declaring Special Purposes, as a way to show they had been disclosed. TCF v2.3 made the Disclosed Vendors segment mandatory, which gave that signal a proper home, and Specifications v2.4 removes the old workaround.
In a decoded TC string, a vendor that declares only Special Purposes should now appear under Disclosed Vendors, without a legitimate interest bit.
One smaller edit: the example stack for advertisers no longer includes Purposes 2, 3, and 4, because advertisers don't typically sell ad space on their own properties. The purposes themselves are unchanged.
What hasn't changed
- The TC string format. The string's version field still reads 2. "v2.4" is the specification version, not a new string format.
- Disclosed Vendors is still mandatory. TCF v2.3 has been required for all TC strings generated since 1 March 2026.
- Google's certified CMP rule. To serve personalised ads through AdSense, Ad Manager, or AdMob, you need a CMP on Google's list of certified CMPs: in the EEA and UK since 16 January 2024, and in Switzerland since 31 July 2024.
- Easy access to settings. Users must be able to reopen the banner from an easily accessible link or icon and withdraw consent as easily as they gave it.
Google's Ad Manager guidance on the TCF still describes the v2.3 transition and doesn't set a separate date for v2.4 (checked 14 October 2026). The IAB deadline applies to every CMP in the framework regardless.
What v2.3 changed, and why it still matters
TCF v2.3 made the Disclosed Vendors segment mandatory in every TC string. Before that, vendors that declared only Special Purposes had no reliable way to know whether the CMP had shown them to the user.
The segment works as a list: if a vendor appears in it, the user was shown that vendor, and the vendor can operate under its declared Special Purposes. Since 1 March 2026, Google has required v2.3 for newly generated TC strings and may default non-compliant ad requests to Limited Ads, while still accepting strings created before that date.
For Google's wider consent rules, see our guide to Google's EU User Consent Policy.
Do you need to collect consent again?
IAB Europe's v2.4 notices set deadlines for CMPs to implement new disclosures. Neither notice asks publishers to collect consent again from existing users.
The TC string format is also unchanged, so strings already stored keep the same structure. Ask your CMP how it handles returning visitors after the update.
IAB TCF v2.4 compliance checklist for publishers
- Confirm v2.4 is live on every site. Check the CMP version on each domain before 23 October 2026. If you run a self-hosted or custom CMP, the update is yours to make.
- Check the Features section. Open the banner's preference settings and look for the standard explanation text and an illustration for each Feature.
- Check there are no switches beside Features. Features shouldn't sit next to controls that can't be disabled.
- Check the Special Feature 2 name. It should read "Identify devices based on information actively requested".
- Check the first layer still shows the vendor count. The first layer must tell users how many third-party vendors store or access information on their device, and that count can include vendors outside the framework.
- Decode a fresh TC string. Vendors that declare only Special Purposes should appear under Disclosed Vendors.
- Review cross-device sync. If you carry choices across devices, tell users the scope and decide how you'll resolve conflicting choices.
- Review your vendor list. IAB Europe's policies warn that disclosing an unjustifiably large number of vendors can make informed choice harder for users and raise legal risk.
- Plan for apps and CTV. The deadline for those environments is 23 February 2027.
How to enable IAB TCF v2.4 in CookieYes
CookieYes supports IAB TCF v2.4 on the Pro and Ultimate plans. It's registered with IAB Europe as a CMP (ID 401) and appears on Google's list of certified CMPs for web and app. Read more about what Google certification means for TCF.
Turn it on in four steps:
- Go to Dashboard > Cookie Banner.
- In the General tab, select GDPR as the consent template.
- Turn on Support IAB TCF v2.4.
- Click Publish Changes.
Then run a new scan, because TCF adds a cookie, and update your privacy policy. Already using TCF with CookieYes? Open the General tab and check that the toggle reads Support IAB TCF v2.4.
Once it's on, CookieYes shows the TCF banner to visitors from the applicable regions. The text in both layers is approved by IAB Europe and can't be edited, which keeps the wording in line with the framework.
Full setup details are in our IAB TCF v2.4 help guide.
Frequently asked questions