A first party cookie is one whose domain matches the site the visitor is on. That is the entire test. It says nothing about who wrote the code that set it, who reads the value, or what the value is for, and the gap between what the label sounds like and what it means is responsible for a large share of the bad advice on this subject. Plenty of first party cookies are pure tracking, and plenty of them need consent.
The domain test, and the three ways a first party cookie is created
Your own application can set one in a response header. A script you loaded from somebody else can set one from inside the page using the document interface. And a vendor can be given a subdomain of yours to serve from, which makes everything they set look like yours to the browser. All three produce a cookie the browser files as first party, and only the first is a cookie you actually control. When you audit, record who set each one as a separate column from whose domain it is on.
Why first party is treated better by browsers
Browsers restrict cross-site reading, not storage on the site you are visiting, so a first party cookie survives where a third party one is blocked or partitioned. That is genuinely useful: a basket, a login session and a language preference all work because of it. It is also why so much measurement has moved to first party storage, and why the list of first party cookies on a typical site has been getting longer rather than shorter.
Where the consent rule lands
On the purpose, not on the domain. The EU exemption is for storage strictly necessary to deliver the service the visitor asked for, which covers the basket and the session and does not cover the analytics identifier even when it lives on your own domain. In California the question is again different and turns on whether what you collect is sold or shared. A first party cookie can be entirely exempt or entirely in scope, and the only way to tell is to write down what each one is for.
The practical audit move
Sort your cookie list by domain, then split the first party group by who wrote it. The rows that are yours and necessary are the ones you can set before any banner appears. Everything else, whatever the domain says, belongs behind the consent signal. Doing it in that order takes about twenty minutes on a small site and produces a defensible table rather than a guess.
Questions people ask about first party cookies
Do first party cookies need consent?
Some do. The test is whether the storage is strictly necessary for the service the visitor asked for, and an analytics or personalisation cookie is not, however it is domained.
Is a cookie on a subdomain first party?
For the browser's purposes, yes, which is exactly why vendors ask for one. It does not change what the cookie is for or who receives the data.
Are first party cookies blocked by browsers?
Not generally, though lifetimes written by in-page scripts are often shortened. That is a measurement problem rather than a compliance one.
Does moving to first party cookies solve my consent problem?
No. It solves a browser problem. The consent question follows the purpose and the recipient, and moving the cookie changes neither.