The IAB Europe deadline to adopt the Transparency & Consent Framework version 2.3 was 28 February 2026. If your SaaS uses programmatic advertising, monetizes with ads in the EEA or the UK, or relies on a Consent Management Platform that participates in the IAB framework, that date applied to you. It has now been over two months since the cutover. Many publishers and vendors are still running TCF 2.2 strings, which means their consent signals are invalid in the eyes of TCF, ad requests default to "Limited Ads", and programmatic revenue has quietly slipped. This article walks through what TCF actually is, what changed in 2.3, how to check whether your current implementation is valid, and the migration steps if you are behind.

What TCF is, and what it is not

IAB Europe describes TCF as "an accountability tool that relies on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the GDPR". It is a voluntary standard, not a regulatory mandate. You can run a SaaS in the EEA forever without ever touching TCF, as long as you also do not participate in the programmatic advertising ecosystem that uses it.

Where TCF becomes mandatory in practice is the moment your business intersects with programmatic ad tech. That intersection has three roles:

  • Publishers — sites and apps that show ads and need to pass consent signals to ad networks.
  • Vendors — ad tech companies (SSPs, DSPs, DMPs, analytics) that read consent strings and behave according to them.
  • CMPs — Consent Management Platforms that collect consent from the end user and encode it into a TC string.

If your SaaS is none of those, TCF does not regulate you. If you are any one of those, TCF 2.3 is your baseline.

The TCF 2.3 change you may have missed

The headline change from TCF 2.2 to 2.3 is small in code and large in consequence: the "Disclosed Vendors" section is now mandatory in the TC string. IAB Europe positioned this as resolving the legitimate interest ambiguity that had been a flashpoint since the framework first launched.

In practical terms, version 2.3 strings carry an explicit list of which vendors the publisher actually surfaced to the user, rather than implying the full vendor list. This matters because regulators (in particular the Belgian DPA and the French CNIL) had ruled that legitimate interest in TCF 2.2 was being claimed too broadly, with publishers passing through TC strings that asserted vendor consent they had not really obtained.

The migration itself is mostly handled at the CMP level. If your CMP vendor (OneTrust, Cookiebot, CookieYes, Didomi, Sourcepoint, Quantcast, Consentmanager, Usercentrics) has shipped TCF 2.3 support, you may already be on it. The trap is the publishers and vendors who did not update their integrations to read the new string format. Their backends are still parsing 2.2-shaped strings and silently downgrading.

The cost of a missed migration is not a fine, it is silent revenue loss. Invalid 2.2-style strings default ad requests to "Limited Ads" mode in the major SSPs. Industry estimates published before the deadline put the potential revenue impact at over 50% on programmatic inventory. The damage is felt at month-end on the revenue report, not in a regulatory letter.

How to check if your current implementation is still valid

The audit takes an hour and does not require code changes. Three checks:

  1. Inspect your TC string. Open your site, open the CMP, accept some categories, and grab the __tcfapi output in the browser console. The string carries a version byte. Version 2 with no Disclosed Vendors section is TCF 2.2 or older. Version 2 with the Disclosed Vendors section populated is TCF 2.3.
  2. Verify your CMP's TCF policy version. Most CMPs expose a "TCF Policy Version" setting. It should read 5 (the policy version that corresponds to TCF 2.3). If it reads 4 or lower, you are still on 2.2.
  3. Check your vendor list URL. The Global Vendor List (GVL) version 3 corresponds to TCF 2.3. Earlier GVL versions correspond to 2.2.

If all three checks return TCF 2.3, you are current. If any returns 2.2, your strings are invalid for downstream vendors that follow the IAB enforcement and you should migrate now.

How to migrate if you are behind

The mechanical steps:

  1. Update your CMP to the latest version. All major CMPs released TCF 2.3 compatible builds in 2025. If yours did not, that is a procurement decision more than a configuration one.
  2. Re-collect consent from existing users. 2.3 strings are not backwards-compatible signals; you cannot upgrade a 2.2 string in place. The CMP shows the banner again on first visit after migration, and the user makes a fresh choice.
  3. Update vendor integrations. If you embed any direct ad tech (Google Ad Manager, Amazon DSP, Criteo), confirm each integration is reading TCF 2.3 strings. The configuration is usually a single flag or environment variable.
  4. Validate end-to-end. Use one of the IAB-published validation tools, or rely on your CMP's built-in audit, to confirm the string is being read correctly by your largest revenue partners.
  5. Document the migration date in your privacy operations log. Auditors and DPAs that ask about TCF compliance will want a date.

When TCF does not apply (clarifying the scope)

The framework is for programmatic advertising and the consent signals that flow through it. A surprising number of SaaS teams adopt TCF without needing it, because their CMP vendor sells "TCF compliance" as a default option. If your SaaS does not show ads, does not work with ad networks, and does not need to pass consent signals to third-party vendors, you do not need TCF. A simpler ePrivacy-compliant banner (with parity between Accept and Reject, no pre-firing of trackers, and a versioned consent record) is enough.

The line is whether your consent collection has to be interoperable with third-party ad infrastructure. If yes, TCF is the standard. If no, a simpler banner is faster to ship and easier to maintain.

Where Termerly fits (and where it does not)

Termerly's consent banner is explicitly not TCF compliant. It does not produce TC strings, it does not register with the Global Vendor List, and it does not participate in the IAB framework. That is a deliberate scoping decision rather than a gap. Termerly targets the simpler case: a SaaS that runs no programmatic advertising, needs a banner for analytics and product cookies, and benefits from a versioned consent record tied to the actual policy text the user saw.

If you are reading this article and your SaaS is in the simpler case, Termerly gets you a parity-by-default banner, a permanent legal page for the cookie policy, and a consent log mapped to policy versions. The banner ships as a single async script and updates without redeploys.

If your SaaS is in the programmatic case, you need a TCF 2.3 CMP. Termerly is not it, and that is OK. Use a dedicated CMP for the consent layer and Termerly for the underlying legal pages those banners link to.

Conclusion

The 28 February 2026 deadline did not arrive with a fine. It arrived with invalid TC strings, "Limited Ads" defaults, and a slow leak in programmatic revenue. The audit to check your status is short, the migration is mostly CMP configuration, and the cost of doing nothing is paid every month in the form of softer ad CPMs. For SaaS teams that never needed TCF in the first place, the lesson is the opposite: do not adopt TCF as a default just because your CMP vendor offers it. A simpler ePrivacy banner is faster and more honest.

If your SaaS does not run programmatic ads and the banner you need is the simpler kind, open a free Termerly project and ship a parity-by-default banner with a versioned consent record this week. If you are in the programmatic case, prioritize the TCF 2.3 migration first and come back for the underlying legal pages once the strings are valid again.