First Party Cookies Are Not Exempt Cookies

Ask a team for its cookie inventory and you will usually get a careful list of third party trackers, followed by a short shrug for first party cookies: those are ours, so they are fine. It is one of the most persistent misunderstandings in consent work, because the first and third party distinction feels like a trust distinction. Legally, it mostly is not.

First party describes the domain that sets the cookie. It says nothing about the purpose the cookie serves, how long it lives, or what it enables. A first party analytics cookie with a two year life is not more necessary to the visitor's requested service than a third party one. It is just nearer.

Necessary is a purpose test, not an origin test

The exemption that matters, in ePrivacy terms, is for storage that is strictly necessary for a service the visitor explicitly requested, or solely for transmitting a communication. Shopping cart state, load balancing, security tokens and the consent cookie itself qualify. Analytics, testing, personalisation and advertising do not become necessary by being set from your own domain.

Classify the inventory by purpose and duration, and treat origin as a technical attribute, not a category of innocence. When teams sort this way, they routinely find first party cookies they cannot explain: legacy testing tools still setting identifiers, a personalisation cookie for a feature retired last year, a two year analytics expiry nobody chose on purpose.

First party is also a technique, not just a fact

Modern tracking deliberately moves first party. Server side tagging, first party collection endpoints and CNAME arrangements place data collection under the site's own domain for resilience against browser blocking. Some of that is legitimate architecture. All of it means a first party label increasingly tells you where the engineering put the collection, not how benign it is.

For consent purposes, follow the data, not the DNS. If a first party endpoint forwards events to an advertising platform, the visitor's consent for that sharing is the question, whatever domain the browser talked to. Audits that stop at the cookie's origin will miss the largest flows on a modern site.

Duration is the neglected column

Inventories list names and purposes and forget expiry, which is where first party cookies quietly become indefensible. A preference for language or region does not need two years. A session identifier does not need to persist for months. Long durations increase the identifiability of the data and the exposure when a purpose is retired but its cookie keeps arriving.

Set a duration policy per purpose, review expiries against it, and shorten what cannot be justified. This is unglamorous work with a clean audit story: every long lived first party cookie in the inventory should be able to answer why it lives as long as it does, in one sentence, written down.

Build the inventory from observation, not memory

Crawl the site in a fresh profile, before consent, after rejecting, and after accepting, and record every cookie set in each state, with domain, duration and the page and script that set it. Compare that observed inventory with the disclosed one. The differences are your findings, and on most sites there are differences in all three states.

Repeat the crawl after major releases and campaign launches, because marketing activity sets cookies the core team never reviews. An inventory is a snapshot of a moving target. The programme is the re crawling, not the spreadsheet it produces once.

Frequently asked questions

Do first party cookies need consent?

Cookies that are not strictly necessary for a service the visitor requested generally need consent in regimes based on ePrivacy and GDPR, regardless of whether they are first or third party. Analytics, testing and personalisation cookies set by your own domain are not exempt by origin. Strictly necessary cookies, such as cart and security cookies, usually are.

What does strictly necessary mean for cookies?

Storage that is essential for a service the visitor explicitly asked for, such as keeping cart contents, maintaining a logged in session securely, load balancing, or remembering the visitor's consent choice itself. If the service works without the cookie, or the cookie serves the operator's measurement or marketing purposes, it is not strictly necessary.

Why do first party cookies matter if browsers block third party ones?

Because collection has moved first party through server side tagging and first party endpoints, partly to survive browser restrictions. The domain that sets a cookie or receives an event no longer indicates how the data is used. Consent should follow the purpose and destination of the data, not just its origin.

How should a cookie inventory be built?

By observation: crawl the site in a fresh browser profile before consent, after rejection and after acceptance, recording each cookie's name, domain, duration and what set it. Compare that with the disclosed inventory. Memory based lists miss campaign and legacy cookies, which are often the problematic ones.