IAB Europe’s 2026 Transparency and Consent Framework update combines TCF Policies v5.0.b with Technical Specifications v2.4. The main changes are clearer explanations of TCF processing Features, formal rules for applying privacy choices across different devices used for the same service, updated guidance for Special Feature 2, and smaller technical changes to the Global Vendor List (GVL) and vendor-disclosure signalling.

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

Customers do not need to rebuild the CMP implementation themselves. Publishers may still need to review their own configuration or account-level privacy logic, particularly if they use multi-device preferences. The update also does not, by itself, require existing users to consent again.

The final v2.4 specifications and corresponding GVL update were published on July 23, 2026. CMPs have until October 23, 2026 to implement the new disclosures in web environments and until February 23, 2027 for mobile app and Connected TV (CTV) environments. 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 platforms, 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

It helps to separate the policy changes from the technical ones.

TCF Policies v5.0.b cover the broader changes. They formalise how privacy choices can apply across multiple devices, change how TCF Features are presented in consent interfaces, clarify Special Feature 2, and update one advertiser example. IAB Europe’s May 2026 policy amendment notice describes these changes.

Technical Specifications v2.4 make two direct technical changes. 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.

TCF v2.3 had primarily addressed a different problem: vendor disclosure. It made the Disclosed Vendors segment mandatory, creating a dedicated way to signal which vendors had actually been shown to the user.

The 2026 update moves the focus toward two broader questions:

How should a user’s privacy choice work when the same service is used on different devices?

And:

How can consent interfaces explain TCF processing methods more clearly?

A Quick TCF Refresher

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 cross-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 an allowed group of services, 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

Global TCF consent remains unsupported. The cross-device rules operate within the same service or permitted group of Digital Properties.

Users need to know how far their choice applies

Where consent 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 its current TCF 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 other 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.

The updated Policies aim to make that distinction clearer.

IAB’s May 2026 implementation 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.

For CookieScript users, this is one of the most directly visible parts of the update because it affects how TCF information is presented inside the consent interface.

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.

Policies v5.0.b did not introduce a machine-level TCF policy version beyond 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.

What Does This Mean for CookieScript Users?

• CookieScript support: CookieScript supports TCF Policies v5.0.b and Technical Specifications v2.4. The CMP-side changes required by the new version are already handled, so customers do not need to build the updated TCF signalling or consent-interface logic themselves.
• Clearer consent information: Users should see clearer explanations of ordinary TCF Features and clearer wording around actively requested device information.
• Cross-device privacy choices: Publishers need to determine whether privacy preferences are carried between their website, app, or other authenticated access points. If they are, the publisher’s own account and preference systems may need to support that behaviour correctly.
• Publisher responsibilities: CookieScript handles the TCF-specific changes that belong at CMP level. Publishers remain responsible for reviewing how their websites, apps, accounts, vendor configurations, and privacy-preference flows fit into the updated rules.
• Impact on website visitors: The practical result should be clearer information about what certain processing methods mean and, where multi-device scope is used, how far a visitor’s privacy choice applies.

Implementation Timeline

July 23, 2026 — Technical Specifications v2.4 and the corresponding GVL update were published.

October 23, 2026 — CMP deadline for the new disclosures in web environments.

February 23, 2027 — deadline for mobile app and CTV environments.

These dates come from IAB Europe’s July 2026 timeline confirmation.

How CookieScript Users Should Prepare

The underlying CMP changes are already handled, so customers do not need to implement the v2.4 signalling changes themselves. Preparation should focus on the parts of the consent experience that depend on the publisher’s own services and configuration.

• Check whether cross-device preferences apply to your service. If privacy choices are shared across your website, app, or other authenticated access points, 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 or app actually operates.

CMP-level work such as consuming standardTexts, rendering the required Feature information, maintaining the relevant TCF signals, DisclosedVendors, and removing the retired LI disclosure workaround belongs at CMP level rather than being functionality publishers should recreate themselves.

What TCF v2.4 Means Overall

For publishers, the important part of the 2026 update is not a new consent-string format.

It is about making two parts of the consent experience clearer: what certain processing methods mean, and where a user’s privacy choice applies when the same service is used across different devices.

The technical specification also removes an obsolete vendor-disclosure mechanism and adds standardised Feature text to the GVL, but those changes primarily affect CMP and vendor implementation.

With the CMP-side changes already supported by CookieScript, publishers can focus on the parts they control: whether cross-device privacy choices apply to their service, whether their vendor configuration is accurate, and how the updated consent experience works for users.

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 selection, and the resulting consent experience to make sure they reflect how your website or app actually operates.

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 cross-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 my TCF vendor list because of v2.4?

Not automatically. The update does not introduce new vendor-registration requirements or require publishers to replace their existing vendor lists. 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 cross-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 cross-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. Because CookieScript already supports the updated requirements, customers do not have to implement those CMP-side changes themselves. Publishers should instead test their own consent configuration and review any vendor or cross-device settings they control.

What happens if I later add 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.