When Your CMP Vendor List Changes, Who Has to Re-Consent?
Your consent banner looks the same as it did in September. The string it sends downstream is not supposed to be. TCF v2.4 specifications were published July 23, 2026, with a web implementation deadline of October 23, 2026, and legacy TCF v2.2 consent strings stopped working after February 1, 2026. If your CMP has not moved, vendors downstream may be rejecting valid consent, or accepting strings that no longer mean what they meant.
The version numbers are the boring part. The part that costs money is what happens when a vendor receives a string it cannot parse: it treats the user as unconsented, or it falls back to a default. Either way your ad revenue and your measurement change without anyone touching the banner. This post is the check that finds out which one is happening on your site.
It depends on what changed. Adding a vendor means the original consent never covered that vendor, so you need fresh consent for the new processing. Removing one is simpler, the old consent stays valid for what remains. The IAB TCF rules say the consent string has to reflect the current vendor list, and a string that names vendors who are no longer there is stale evidence.
The consent you collected names specific vendors
When a visitor clicks accept on a TCF banner, the consent string that gets stored is not a general yes to advertising. It is a yes to a named list of vendors and purposes, each with its own ID. That list lives in the Global Vendor List, and your CMP pulls the version that is current when the visitor consents. Change the list and the string no longer describes what is happening on the page.
This is why a vendor change is not a back office update. If a new vendor starts dropping cookies or reading identifiers and the stored consent never mentioned them, there is no lawful basis for that processing. The vendor is operating on a yes that was given for someone else. That is the gap regulators look for, and it is the gap that shows up in audits when a CMP vendor list and the consent records do not match.
What counts as a change that needs fresh consent
A vendor added to the list needs fresh consent before it processes anything. A vendor removed from the list needs nothing from the visitor, though the old consent string should be retired so it stops being passed around as if it were current. A vendor that changes its purposes, for example adding a purpose it did not have before, is the same as a new vendor for that purpose. A vendor that only changes its legal name while the processing stays identical is the one case where the old consent still covers it, and even then the CMP should record the rename.
The practical test is simple. Read the stored string and ask whether it names the vendor doing the work right now, for the purpose it is doing. If the answer is no, the consent is not there yet. No amount of banner polish fixes that, because the banner already ran and the visitor already answered a different question.
How to run the change without breaking the site
Do the change in the CMP first and let it push a new consent string version. Then decide how the re-prompt happens. The clean route is to show the banner again only to visitors whose stored consent predates the change, with the new vendor visible in the vendor list. That keeps the re-prompt narrow and honest, and it keeps the consent records tidy: every string carries the version of the vendor list it was collected against.
Keep the old strings. They are the evidence for processing that happened while they were current, and deleting them destroys the audit trail for that period. What you retire is their use going forward. Log the date of the change, the vendors added and removed, and the number of visitors re-prompted. If a regulator ever asks why a vendor processed data in a given week, that log is the answer.
Keep reading: Consent Mode v2: Basic or Advanced, and What the Choice Costs You, TCF v2.4 Is Past Its Deadline. Check What Your CMP Actually Sends, and The GPC Signal Is Not a Banner Setting. Test It Like a Request. cover the nearby cases in this series.
Frequently asked questions
Do I need fresh consent when a vendor leaves my list?
No. Removing a vendor narrows the processing, so the consent already collected still covers everything that remains. Retire the old consent string so it is not passed on as current, and keep it in your records as evidence for the period it covered.
What if a vendor only changes its name?
The old consent still covers the same processing under a new name, because nothing about the data use changed. Record the rename in the CMP and in your change log, and check the vendor list version so the stored strings stay accurate.
How do I know which vendor list version a consent string used?
The TCF consent string carries the Global Vendor List version it was collected against. Your CMP should show it alongside each stored record. If it does not, ask the vendor, because a consent record without a list version is hard to defend.
Can I just re-prompt everyone after any vendor change?
You can, but it costs you. Re-prompting the whole audience for a minor change trains visitors to click without reading, and the accept rate drops. Re-prompt only the visitors whose stored consent predates the change.