IAB TCF v2.4: What CMPs Must Change by October 2026

IAB TCF v2.4 now has a confirmed rollout schedule. IAB Europe plans to publish the final technical specifications and updated Global Vendor List (GVL) on 23 July 2026. CMPs then have until 23 October 2026 for web implementations and 23 February 2027 for mobile app and connected TV environments. If your consent stack participates in the TCF, this is an implementation project—not a wording-only banner update.

The changes sit across TCF Policy v5.0.b and Technical Specifications v2.4. They affect how CMPs explain Features, disclose the scope of a choice, support multi-device consent, and encode a narrow vendor-signalling case. For background on the current framework, see Conzent's IAB TCF compliance overview.

Key takeaways

The confirmed dates give CMPs and publishers a short but workable sequence: inspect the final package in July, finish web changes in October, and keep mobile and CTV on a separate February plan. The most important points are:

• 23 July 2026: IAB Europe plans to publish Technical Specifications v2.4 and the corresponding GVL update.
• 23 October 2026: CMPs must implement the new disclosures in web environments.
• 23 February 2027: the equivalent deadline applies to mobile app and CTV environments.
• CMP interfaces need clearer standard explanations and illustrations for Features.
• The initial layer must tell users whether a choice is service-specific, group-specific, or multi-device.
• The technical preview removes an obsolete legitimate-interest workaround for vendors that declare only Special Purposes; teams should verify the final wording on 23 July.
• TCF participation supports compliance work, but does not replace a publisher's or vendor's own legal assessment.

The three dates to put in your delivery plan

IAB Europe's confirmation dated 16 July 2026 establishes three separate milestones. Treating them as one deadline would compress discovery, implementation, translation, and QA into the same release window.

The practical sequence is:

1. 23 July 2026 — specification and GVL publication. Download the final files, compare them with the public-comment material, and turn every confirmed difference into an owned task.
2. 23 October 2026 — web deadline. Production web CMPs should expose the new disclosures and follow the final v2.4 signalling requirements.
3. 23 February 2027 — app and CTV deadline. Native SDKs, release-store lead times, television interfaces, and device-specific accessibility testing get a later date, not an exemption.

The gap between publication and the web deadline is three months. That is enough for a controlled update if teams start with a specification diff and a test matrix. It is tight if work begins with a late banner redesign.

The confirmed sequence separates the source material, web implementation, and app/CTV rollout. Plan and test them as three milestones rather than one launch.

Who must act—and who should still pay attention

The deadlines apply to live TCF implementations and the CMPs responsible for them. The official TCF Policies cover both commercial CMPs serving customers and private CMPs operated by a publisher for its own properties. Publishers remain responsible for the framework UI presented on their digital properties, even when a third party supplies the CMP.

You should put this work on a delivery plan if you:

• build or operate a registered TCF CMP;
• use a commercial CMP on a website funded by programmatic advertising;
• maintain a private publisher CMP;
• ship the same consent experience across web, app, and CTV;
• depend on TCF signals for vendors, bidding, measurement, or personalised ads.

A website that does not participate in the TCF is not automatically required to implement TCF v2.4. It may still need a valid consent mechanism under applicable law or platform rules. The framework version and the legal duty to obtain consent are related questions, not the same question.

This distinction matters for Google publisher products. Google requires a certified CMP integrated with the TCF for personalised ads served through AdSense, Ad Manager, or AdMob to users in the EEA, UK, and Switzerland. Google also states that its certification review does not check full compliance with the TCF or applicable privacy law.

What users will see differently in a CMP

The most visible change is an effort to explain Features more clearly. In the TCF, a Purpose describes why data is processed and gives the user a consent or objection choice where applicable. A Feature describes a processing method used in pursuit of one or more Purposes; it does not carry a separate user control in the same way.

Under Policy v5.0.b and the confirmed GVL update, CMPs need to account for:

• a new standardTexts field containing the standard explanation for Features;
• illustrations for each Feature in the updated GVL;
• the standard Feature explanation displayed with the standard name and full user-friendly text;
• Feature information that is not visually associated with controls that cannot actually disable the Feature;
• a new name and guidance for Special Feature 2.

The updated name for Special Feature 2 is “Identify devices based on information actively requested.” The policy guidance explicitly covers characteristics collected through JavaScript or APIs—such as fonts, screen resolution, and plugins—and information actively requested through User-Agent Client Hints. Users must opt in before a vendor uses this Special Feature.

Why this is more than a copy update

A CMP that hard-codes labels or assumes the old GVL shape could fail even if the banner still looks normal. Product teams need to trace the new data from ingestion to every UI layer, translation, accessibility label, cached vendor record, and regression test. The safe design principle is simple: render the official meaning accurately, make the presence or absence of a user choice unmistakable, and do not turn an explanatory Feature into a fake toggle.

Multi-device consent needs an explicit scope

Policy v5.0.b adds multi-device scope to the framework's definitions. A legal basis can apply across access points for the same service or group—for example, a website and mobile app used by an authenticated account—when the implementation supports that scope. The initial layer of the framework UI must tell the user whether the consent choice is service-specific, group-specific, and/or multi-device.

That convenience creates a product responsibility. A CMP needs a defined way to resolve a choice made on a device before login against preferences already stored on the account. It also needs to keep refusal and withdrawal as usable as acceptance across the same scope.

CNIL's January 2026 cross-device recommendation is French regulatory guidance rather than an EU-wide TCF rule, but it is a useful implementation benchmark. CNIL recommends that:

• accepting, refusing, and withdrawing have the same multi-device reach;
• users are told before choosing that the preference will apply to devices connected to their account;
• a short reminder is shown when the user logs in on a new device;
• conflicts are handled transparently, either by prioritising the most recent pre-login choice or the account preference.

Document the chosen conflict rule and test both directions. A technically consistent preference store can still create a misleading experience if users are not told which choice wins.

What changes under the hood

The technical package is scheduled for 23 July, so implementation teams should use the current material to prepare—not to pretend the final diff has already been verified. IAB Tech Lab's public-comment summary identifies two concrete engineering areas.

First, the GVL gains the standardTexts object used for Feature explanations. Parsers, types, caches, APIs, and rendering code need to accept and preserve the new field. A graceful fallback is useful for operational resilience, but it must not silently omit a disclosure required after the deadline.

Second, the preview removes a workaround for vendors that declare only Special Purposes. Since TCF v2.3 made the disclosedVendors segment mandatory, those vendors can determine whether they were disclosed from that segment. The preview therefore removes the requirement to place Special-Purpose-only vendors in the Vendor Legitimate Interest section of the TC string.

A cautious implementation rule

Prepare tests now, then bind production behavior to the final v2.4 text published on 23 July. In particular, compare the final TC-string specification, CMP API material, GVL schema, translations, and examples with the preview. Record the version you tested. “We followed the June article” is not a useful audit trail when a final specification exists.

A seven-point TCF v2.4 readiness checklist

The deadline is easier to manage when each requirement has an owner and an observable acceptance test. Start with this checklist and expand it for your architecture.

1. Inventory every TCF surface. List web properties, embedded experiences, mobile apps, CTV apps, consent settings, account preference centres, SDKs, and cached GVL consumers. Mark each as web, app, or CTV for deadline planning.
2. Diff the 23 July release. Compare the final specification, GVL schema, translations, illustrations, and policy references with your current v2.3 implementation and the public-comment preview.
3. Update GVL ingestion. Verify that standardTexts, illustrations, the renamed Special Feature 2, and future unknown fields survive parsing, storage, APIs, and caching.
4. Test the user interface. Check that Feature explanations appear beside the correct information, do not look like controls, remain readable with zoom and assistive technology, and work in every supported language. Review the cookie banner experience as a complete flow rather than a single first layer.
5. Test signalling. Create fixtures for Special-Purpose-only vendors and verify the final v2.4 encoding and decoding rules across the CMP, downstream vendors, and any server-side consent handling.
6. Define multi-device behavior. Document scope, identity requirements, storage, propagation, withdrawal, and the rule used when device and account choices conflict. Test accept, refuse, change, logout, new device, and account deletion paths.
7. Ship and observe. Release web changes before 23 October with monitoring for GVL failures, consent-string errors, missing disclosures, and unusual changes in choice rates. Keep app and CTV releases on a separately owned plan for 23 February 2027.

Self-hosting does not remove these responsibilities. If you operate OCI on your own infrastructure, you control the upgrade window and can inspect the implementation, but you also own the final specification review, deployment, and verification.

What publishers should ask their CMP provider

Publishers do not need to implement every parser change themselves, but they should not accept “TCF-ready” as a complete answer. Ask for evidence tied to your actual environments and dates.

Useful questions include:

• Which TCF Policy and Technical Specification versions are running in production today?
• When will web support for v2.4 be generally available, and what customer action is required?
• How are the new Feature explanations, illustrations, and Special Feature 2 text rendered and translated?
• Does the product support multi-device scope, and exactly how are conflicting choices resolved?
• Which web, app, and CTV SDK versions contain the changes?
• What automated and manual tests cover the final v2.4 TC-string behavior?
• Will users need to see the framework UI again, and what is the source for that decision?

Ask the provider to separate framework compliance, Google certification, and general privacy-law support. They overlap, but none is proof of the other. Your own controller, publisher, and vendor obligations still need a GDPR compliance assessment appropriate to the processing you perform.

What TCF v2.4 does not mean

TCF v2.4 is an industry framework update, not a new statute and not a universal mandate for every website. IAB Europe's own policy describes participation as voluntary and says that the framework is not a substitute for individual participants taking responsibility for their legal obligations.

Keep these boundaries visible in internal and customer communication:

• meeting the TCF deadline does not by itself make a consent flow lawful;
• Google CMP certification does not equal full TCF or privacy-law compliance;
• a technically valid TC string does not prove that the user received clear information or made a valid choice;
• multi-device convenience does not justify hidden scope or one-way propagation;
• a new standard label does not fix a misleading interface around it.

Use legal counsel for jurisdiction-specific conclusions. Use the specification, policy, and regulator guidance as separate inputs to product requirements rather than blending them into one vague “compliance” ticket.

Frequently asked questions

What does IAB TCF mean?

IAB TCF means the IAB Europe Transparency and Consent Framework. It standardises how participating publishers, CMPs, and vendors disclose data processing, capture relevant choices, and communicate consent, objection, and transparency signals in the digital advertising ecosystem.

What is IAB TCF v2 3?

TCF v2.3 is the technical version immediately before v2.4. Among other changes, it made the disclosedVendors segment mandatory. That matters to v2.4 because the public-comment draft uses the mandatory segment to remove the older legitimate-interest workaround for Special-Purpose-only vendors.

What is the TCF list?

The term usually refers to the Global Vendor List, or GVL. IAB Europe maintains it for registered TCF vendors, and CMPs use its declarations, standard text, and related data to present information and produce framework signals. The v2.4 rollout includes a corresponding GVL update scheduled for 23 July 2026.

Does every CMP need to implement TCF v2.4?

No. The deadlines concern CMPs and live installations participating in the IAB Europe TCF. A non-TCF consent tool may still have obligations under privacy law or platform policy, but those obligations do not automatically turn it into a TCF participant.

When is the TCF v2.4 deadline for CMPs?

The confirmed deadline is 23 October 2026 for web environments and 23 February 2027 for mobile app and CTV environments. The specifications and corresponding GVL update are scheduled for publication on 23 July 2026.

Conclusion

TCF v2.4 is not a reason to redesign every consent flow. It is a reason to verify the parts users and vendors rely on: clear Feature explanations, honest scope, reversible cross-device choices, and accurate signals. Start with the 23 July files, test web before 23 October, and keep mobile and CTV on the February 2027 plan. A documented, evidence-based rollout will beat a rushed banner-only update.