IAB Europe has updated its Transparency and Consent Framework (TCF) for 2026. The update combines TCF Policies v5.0.b with Technical Specifications v2.4.

The main changes affect how TCF Features are explained to users, how privacy choices can apply across multiple devices used for the same service, how Special Feature 2 is described, and how some Global Vendor List (GVL) and vendor-disclosure information is handled.

CookieScript now supports the updated TCF requirements for web implementations, including the CMP-side changes to consent-interface disclosures and TCF signalling.

The final v2.4 specifications and corresponding GVL update were published on July 23, 2026. The implementation deadline for web CMPs is October 23, 2026, while CMPs operating in mobile app and Connected TV (CTV) environments have until February 23, 2027. IAB Europe’s confirmed implementation timeline sets out these dates.

The IAB Europe Transparency and Consent Framework (TCF) is a standard used by publishers, consent management platforms (CMPs), and advertising vendors to communicate privacy disclosures and user choices in the digital advertising ecosystem.

Policies v5.0.b and Technical Specifications v2.4 Cover Different Things

Although they were introduced as part of the same TCF update, the policy and technical documents do different jobs.

TCF Policies v5.0.b set the Framework rules that CMPs, publishers, and participating vendors need to follow. They contain the policy-side changes explained below, as well as an update to one advertiser example. IAB Europe’s May 2026 policy amendment notice describes these changes.

Technical Specifications v2.4 deal with the implementation details. They add standardTexts to the GVL and remove an old disclosure workaround for vendors that register only for Special Purposes.

So despite the name “TCF v2.4,” this is not a major redesign of the TC String itself.

How TCF Signalling Works

A CMP can communicate users’ choices for TCF Purposes and Special Features, which vendors were disclosed, applicable consent and legitimate interest (LI) signals, and other Framework information. These signals are stored in a Transparency and Consent String, or TC String, which participating vendors can read.

TCF helps publishers, CMPs, and vendors communicate privacy choices under the GDPR and the ePrivacy Directive, including the national laws that implement the latter. Using the Framework, however, does not by itself make every processing activity legally compliant.

Privacy Choices Can Have Multi-Device Scope

Policies v5.0.b formally define multi-device scope.

In practical terms, this means a privacy choice can apply across different ways of accessing the same service—for example, a publisher’s website and mobile app.

One way this can work is through an authenticated account. Imagine a user signs in to a news publisher’s website on a laptop and makes a privacy choice. Later, the same user signs in to that publisher’s mobile app.

If the publisher uses this multi-device approach, the preference associated with the account can also be applied in the app instead of treating the phone as a completely separate privacy state.

IAB describes this more formally as a TCF Legal Basis applying across Digital Properties belonging to the same service, or a pre-defined group of Digital Properties under the same organisation, when those properties are accessed through different devices or user agents. A Legal Basis in this context can mean either consent or legitimate interest.

This is a formalisation, not a completely new idea

TCF guidance had already considered authenticated users moving between devices before 2026. Earlier guidance said that where a publisher could identify the same logged-in user across several devices, consent did not necessarily need to be collected again on each device. Earlier TCF v2.0 guidance addressed this situation.

Policies v5.0.b make multi-device scope an explicit part of the Framework and set clearer expectations for how it is disclosed and managed.

It does not mean global consent

A choice made on one website does not automatically carry across unrelated publishers.

Multi-device scope can apply, for example, between:

Publisher A’s website → Publisher A’s app

It does not mean:

Publisher A → unrelated Publisher B → unrelated Publisher C

The TCF does not provide for global consent across unrelated publishers. Multi-device scope operates within the same service or permitted group of Digital Properties.

Users need to know how far their choice applies

Where a privacy choice has multi-device scope, the consent interface needs to tell the user about that scope, including whether the choice is service-specific, group-specific and/or multi-device. The current TCF Policies include this information among the initial-layer requirements.

The practical principle is simple: if a choice made on one device may also affect another device, that should not happen without the user being told.

What if the account and device contain different choices?

A publisher can also encounter conflicting preferences.

For example, a user’s account may contain one preference while the user makes a different choice on a new device before logging in.

IAB does not require one universal method for resolving this conflict. According to IAB Europe’s implementation FAQ, a publisher or CMP may keep the most recent choice made before login or prioritise the preference already stored with the authenticated account. IAB strongly recommends telling the user which preference is being applied.

Multi-device scope is not “Link different devices”

TCF already has Feature 2: “Link different devices”. That is a different concept.

Feature 2 describes a data-processing method used to associate different devices with the same user or household. The live GVL, for example, gives scenarios in which devices may be associated because the user signs in to the same service or the devices share the same internet connection.

Multi-device scope is about something else: whether a user’s consent or another TCF Legal Basis applies when the same service is used through another device.

Technical note: there is no new multi-device TC String field

The update does not add a multiDevice field or a new multi-device TC String segment.

The TC String still uses the existing TCF v2 encoding, and its Version field remains 2. The TC String specification continues to define that structure.

So checking for something such as TC String version == 2.4 would be incorrect. “v2.4” refers to the technical specification version, not a decimal value stored in the TC String.

Consent Interfaces Need to Explain TCF Features More Clearly

One of the most visible changes concerns the information users see inside the consent interface.

TCF distinguishes between three concepts:

• A Purpose explains why data is processed.
• A Feature describes a method that may be used to carry out one or more Purposes.
• A Special Feature describes particular processing that normally requires a separate opt-in, subject to defined exceptions.

The problem is that ordinary Features could sometimes look like separate choices in a CMP interface even though they are not standalone TCF permissions.

IAB’s May 2026 policy amendment notice introduces standard explanatory wording for Features. The current TCF Policies also say Features should not be associated with controls that could make users think they can switch the Feature on or off independently.

The GVL now includes standardTexts

To support this change, the technical specifications add a new standardTexts field to the Global Vendor List.

The live GVL already contains standardTexts.features, which provides standard wording CMPs can use to explain what Features are.

For website owners, the important point is not the JSON field itself. The practical result is that TCF-compatible CMPs can present a more consistent explanation of Features across different websites.

Features also get illustrations

The GVL also provides illustrations intended to make individual Features easier to understand.

Instead of relying only on technical labels such as “Link different devices,” CMPs can show a practical example of what that type of processing may involve.

IAB Europe’s July implementation notice identifies both the standard Feature explanation and Feature illustrations among the updated disclosures.

Special Feature 2 Has Clearer Wording

Special Feature 2 previously used the name:

“Actively scan device characteristics for identification.”

The updated name is:

“Identify devices based on information actively requested.”

It remains Special Feature 2; this is a wording and guidance change rather than a new permission. IAB Europe said the previous wording was not sufficiently clear in its policy amendment notice.

The revised guidance also explicitly covers actively requested browser information such as User-Agent Client Hints when that information is used to create an identifier or distinguish a user or device.

This helps clarify the difference between two TCF concepts.

1. Feature 3 concerns identification using information the device automatically sends, such as an IP address or ordinary User-Agent information.
2. Special Feature 2 concerns identification based on information that is actively requested from the browser or device, for example through JavaScript, APIs, or Client Hints. The current TCF Policies explain this distinction.

Special Feature 2 normally requires user opt-in. The Policies contain a specific derogation for certain active device-identification processing carried out for Special Purpose 1—security, fraud prevention and detection, and error correction—provided the Framework’s conditions are met.

Other Technical and Policy Changes

Not every part of the update has a visible effect on the consent interface. Two smaller changes are mainly relevant to how the Framework operates behind the scenes and how IAB documents advertiser use cases.

The old Special-Purpose vendor-disclosure workaround is removed

Before TCF v2.3 made the Disclosed Vendors segment mandatory, the Framework used a workaround for vendors that registered only for Special Purposes.

For TC Strings created before March 1, 2026, where such a vendor had been displayed by the CMP, the Vendor Legitimate Interest bit set to 1 could be used as the disclosure signal. The official technical specification documents this historical behaviour.

The progression is:

• Older TCF: Special-Purpose-only disclosure could use an LI-bit workaround.
• TCF v2.3: DisclosedVendors became mandatory, creating a dedicated vendor-disclosure signal.
• TCF v2.4: the now-redundant LI-based disclosure workaround is removed.

The change does not reduce vendor-disclosure requirements. DisclosedVendors remains mandatory. The old workaround can be removed precisely because a dedicated mandatory disclosure signal now exists.

The advertiser example was updated

Policies v5.0.b also update Example Stack Combination 3 (Advertisers).

IAB removed Purposes 2, 3, and 4 from that particular advertiser example because advertisers typically do not sell advertising placements on their own Digital Properties. The May policy amendment notice describes the change.

This is only a change to the example. Purposes 2, 3, and 4 remain part of TCF, and Stack 3 itself has not been removed.

Does TCF v2.4 Mean Everyone Has to Consent Again?

No.

The publication of the updated technical specifications and Policies does not by itself require every existing user to go through the consent process again.

TCF already has rules for situations where a policy change requires existing Legal Bases to be re-established. The GVL uses tcfPolicyVersion for this purpose, and the technical specification explains how CMPs handle such changes.

The GVL still reports tcfPolicyVersion as 5.

A CMP may still need to ask a user again when other relevant circumstances change—for example, changes involving vendors, Purposes, Legal Bases, or required disclosures. But there is no blanket consent reset simply because TCF v2.4 was published.

How CookieScript Users Should Prepare

Preparation should focus on the parts of the consent experience that depend on the publisher’s own services and configuration.

• Check whether multi-device preferences apply to your service. If your organisation shares privacy choices between its website and other authenticated environments, review how those preferences are stored and applied.
• Review account-versus-device preference logic. Decide what happens if a user makes one choice before login but has a different preference stored in their account.
• Check the updated consent experience. Review how the new Feature explanations, illustrations, and Special Feature 2 wording appear to users.
• Review your TCF vendor setup. Confirm that the vendors and processing purposes configured for your service still reflect how your website and related services actually operate.

CookieScript handles these CMP-level implementation requirements; publishers should focus on the configuration and service-level decisions they control.

Frequently Asked Questions

Do I need to change anything in CookieScript manually for TCF v2.4?

The CMP-side implementation is handled by CookieScript. You do not need to build the new TCF signalling or standardTexts functionality yourself. You should still review your TCF configuration, vendor configuration, and the resulting consent experience to make sure they reflect how your website and related services actually operate.

What if I only have a website and do not have an app or logged-in users?

Multi-device scope may have little practical impact if you do not carry privacy preferences between devices or different access points to the same service. You should still review the consent experience and your TCF vendor configuration, but you may not need to make changes related to multi-device preference handling.

Do I need to implement DisclosedVendors myself?

No. DisclosedVendors is part of the TCF signalling handled at CMP level. It became a mandatory part of the Framework under TCF v2.3, but CookieScript customers do not need to create or maintain that TC String segment themselves.

Should I change the vendors configured in my TCF setup because of v2.4?

Not automatically. The update does not introduce new vendor-registration requirements or require publishers to change their configured vendors. However, regularly reviewing vendors configured in a consent banner helps ensure that the disclosed vendors still match the advertising and data-processing technologies actually used by the service. The current Global Vendor List provides the Framework’s current vendor information.

What should I test after the update?

Check how the consent interface appears to users, including Feature explanations, Feature illustrations, and the updated Special Feature 2 wording. If you use multi-device privacy preferences, also test the consent implementation across browsers and devices, including what happens before and after login.

If I do not use multi-device preferences, do I need to implement them now?

No. The updated Policies define how multi-device scope should work when it is used; they do not require every publisher to introduce multi-device privacy preferences. You should still verify that your existing consent setup works as intended, but you do not need to add multi-device functionality solely because of this update.

Do I have a TCF v2.4 deadline if I use CookieScript only on the web?

The October 23, 2026 deadline applies to CMP implementation of the new web disclosures, as set out in IAB Europe’s implementation timeline. CookieScript handles the CMP-side implementation; publishers should focus on reviewing and testing the configuration they control.

What if my organisation later adds an app or another logged-in service?

You should review whether privacy choices will be shared between the new environment and your existing website. If they will, the multi-device rules become relevant, including how scope is disclosed and how conflicting account-level and device-level preferences are handled. After introducing the new environment, test the consent flow across devices to confirm the expected preference is applied.