TCF Purpose 1: Why Legitimate Interest Does Not Work for Storage

TCF purpose 1 is the storage of information on a device, and it is the purpose that underpins everything else. If your vendor list claims legitimate interest for purpose 1, your consent string is wrong, and your banner is collecting consent it cannot use.

Purpose 1 is the foundation

The IAB Transparency and Consent Framework, TCF 2.2, organises data processing into purposes, and purpose 1 is the storage of, or access to, information on a device. It is the foundation, because almost every other purpose needs to store or read something first: a cookie, a local storage entry, a device identifier. Purpose 1 requires consent. It cannot be based on legitimate interest, and the TCF policies are explicit on this point.

The reason is simple. Storing or accessing information on a user's device is the act that the ePrivacy Directive regulates, and the Directive requires consent for it, with only narrow exceptions for strictly necessary storage. Legitimate interest is a GDPR concept, and it does not override the ePrivacy requirement. A vendor that claims legitimate interest for purpose 1 is claiming a legal basis that does not exist for that act, and the consent string that records it is not valid.

The TCF consent string post explained how to read the string your CMP produces. This post is about what to look for in it: the legal basis recorded for purpose 1, for each vendor. If any vendor lists legitimate interest for purpose 1, the string is wrong.

How the misconfiguration happens

The misconfiguration usually happens in the CMP, not in the vendor list itself. A CMP that lets vendors self-declare their legal basis, or that imports a vendor list without checking it, can produce a string that records legitimate interest for purpose 1 without anyone noticing. The vendor list for a large site can have hundreds of vendors, and a single one claiming the wrong basis is easy to miss in a manual review.

The fix is to audit the vendor list and the consent string it produces, and to automate the check. Parse the consent string, extract the legal basis for purpose 1 for each vendor, and flag any vendor that records legitimate interest. The check is a script, not a meeting, and it should run on every vendor list change. The consent mode post made the same point about a different signal: the state has to be checked mechanically, because a human will not catch a single wrong entry in a list of hundreds.

What to do when you find it

Fix the vendor list first, then regenerate the consent string, then check that the new string records consent for purpose 1. The vendors that were claiming legitimate interest will need to be reconfigured or removed, and the change has to be communicated to them, because they have been acting on a string that told them they had a legal basis they did not have.

The wider lesson is that a consent string is only as good as the configuration that produces it. A banner that looks right and a string that is wrong is a compliance failure that is invisible to the user and visible to the regulator. Audit the string, not the banner, and automate the audit, because the vendor list changes more often than anyone remembers to check it.

Frequently asked questions

What is TCF purpose 1?

Purpose 1 is the storage of, or access to, information on a device, like a cookie. It is the foundation for the other purposes, because most of them need to store or read something first. It requires consent, and it cannot be based on legitimate interest.

Can a vendor claim legitimate interest for purpose 1?

No. Purpose 1 is one of the purposes that requires consent under the TCF, and a vendor that claims legitimate interest for it is misconfigured. The IAB's TCF policies are explicit on this point, and a consent string that records legitimate interest for purpose 1 is not valid consent.

What is a TCF consent string?

The consent string is a compact encoding of the user's choices, including which purposes and vendors they consented to and which legal basis applies. It is passed to vendors, and vendors are supposed to read it before processing data. If the string is wrong, the vendors act on wrong information.

How do I check whether my vendor list is wrong?

Check the vendor list in your CMP and the consent string it produces. If any vendor lists legitimate interest for purpose 1, the configuration is wrong. Fix the vendor list, regenerate the string, and check that the string records consent for purpose 1, not legitimate interest.

Is this a common mistake?

Yes, and it is one of the most common TCF misconfigurations. A vendor list with hundreds of vendors is hard to audit by hand, and a single vendor claiming the wrong legal basis for purpose 1 can invalidate the whole string. Audit the list regularly, and automate the check if you can.