On 18 December 2025 the CNIL adopted deliberation 2025-131, folded into its consolidated cookie recommendation published on 16 January 2026. It adds a section on consent that follows a logged-in account across devices instead of sitting in one browser. Adopting it is optional. If you do, four things follow: refusal and withdrawal must work in one step wherever consent does, an anonymous choice made before login conflicts with the account and you must pick a documented resolution, your CMP vendor should never receive an account identifier containing an email or a name, and migrating an existing setup means asking everyone again. Here is what each requirement means for the storage layer.
Consent has always been stored where the visitor is: a cookie or a localStorage key, one browser at a time. Log in on your phone and you meet the banner again, because the phone has never heard of you. The CNIL has now written down how to attach those choices to an account instead — and the interesting part is not the permission, it is the set of conditions attached to it.
What was actually adopted
Deliberation n. 2025-131 of 18 December 2025 modifies the CNIL’s 2020 recommendation on cookies and other trackers. The two are merged in a consolidated version published on 16 January 2026, where the new material is section 7, on multi-device consent in authenticated contexts.
Read the first line of that section before anything else: implementing multi-device consent is optional and does not constitute an obligation on the controller. This is not a deadline. It is a description of how to do something properly if you choose to do it.
One scoping note, because this niche routinely reports French guidance as European law. The CNIL is the French authority, applying Article 82 of the French Data Protection Act, which transposes Article 5(3) of the ePrivacy Directive. Other supervisory authorities have not published an equivalent. What follows describes what one influential regulator has set out, not a rule that applies across the EU.
The definition, and the two conditions on it
Multi-device consent means the user’s choices are no longer attached to a terminal but to the account associated with the site or app. Express a preference on one signed-in device and it applies to the others — tablet, laptop, connected TV — and can be managed from any of them.
Two conditions come with the definition, and both are engineering requirements as much as legal ones.
Symmetry of scope. If consent can be given once for several terminals, the same must be true of refusal and of withdrawal. A design where accepting propagates instantly to every device but withdrawing only affects the device you are holding is specifically excluded. In practice this means withdrawal has to be a write to the same account-level record, not a local clear.
Information before the choice. The user has to be told the scope beforehand — that the decision will apply to every terminal where that account is signed in. Section 7.2 adds that this should be repeated immediately after authentication on a device not yet linked to the account, through an ephemeral banner indicating whether the account’s choices have been saved or changed.
The conflict problem, which is where the work is
Section 7.3 addresses the situation that any implementation hits on day one. A visitor arrives on a new device, sees the banner because nothing is stored locally, and chooses. Then they log in — and the account holds something different. Which wins?
The CNIL sets out two approaches and does not mandate either, while encouraging the industry to converge on one so users encounter consistent behaviour.
Approach 1: the pre-login choice overwrites the account. The most recent expression wins regardless of device, and propagates everywhere. It is simpler to build and easy to explain. It also means a single decision taken on a borrowed laptop rewrites the settings on every device the person owns.
Approach 2: the account wins. Closer to what people expect from a saved preference, and considerably more work. The recommendation is explicit about why: making it effective requires distinguishing the user’s browsing depending on whether they are authenticated or not, for example through two different cookies or identifiers. You are running two consent states per person and reconciling them at the login boundary.
Either way, the user has to be told what happened. Under approach 1, that the account’s choices were saved or modified. Under approach 2, that a contradiction exists, that the account’s earlier choices continue to apply, and how to change them.
Shared devices stay separate
Section 7.4 draws a line the reconciliation logic must respect: choices made in the authenticated context must not affect choices already recorded in the unauthenticated one. The example given is the household — a family computer, a connected TV. One person’s account preferences cannot become the defaults for everyone else who uses that screen while signed out.
So the browser-level record does not disappear when you introduce account-level consent. It continues to exist alongside it, governing anonymous sessions on that device, and your code has to keep the two apart.
Do not hand your CMP vendor an email address
Section 7.5 is short and easy to get wrong. Reconciling devices requires the consent platform to receive some identifier for the account. The CNIL recommends, on data minimisation and data protection by design under Article 25 of the GDPR, not transmitting the account identifier where it contains personal data in the clear — a username containing a first or last name, or an email address — and systematically substituting a technical identifier instead.
If your account IDs are email addresses, and many are, the fix is a per-user opaque token generated on your side and mapped back internally. Worth noting that this is one of the places where self-hosting removes the problem rather than solving it: with a self-hosted CMP there is no third party to minimise data towards, because the consent record never leaves your infrastructure.
The expensive requirement is the migration
Section 7.6 is the one to plan around. When an existing setup becomes a multi-device mechanism, controllers must collect fresh consent. Consent expressed on a single terminal beforehand cannot be treated as valid for the others, because the user was never informed of the wider scope when they gave it.
You cannot migrate the existing table and switch the flag. Turning this on means every user meets the banner again, once, with the new scope explained — and that is a measurable cost in a way that the rest of the section is not. It is also the direct consequence of the information condition above rather than a separate rule: consent covers what the person was told about.
Section 7.7 closes with a best practice pointing the other way: let users vary their choices device by device from the preference centre, since the context in which someone uses a phone is not the context in which they use a shared TV.
What this means for the storage layer
Everything above pushes consent out of the browser and into a record on your server, keyed by account, holding the state and the evidence. A cookie holding {"analytics":true} cannot satisfy symmetric withdrawal across devices, cannot be reconciled at login, and cannot show what the user was told at the time. We wrote separately about keeping a defensible proof-of-consent record; multi-device consent turns that from good practice into a structural requirement, because the record is now the only place the state lives.
Duration still applies on top. The same recommendation treats storing choices — consent and refusal alike — for six months as good practice, with the exact period assessed case by case. Attaching consent to an account does not make it permanent, and an account-level record makes re-prompting easier to implement precisely, not harder.
If you serve France specifically, this also interacts with how you scope the banner in the first place: showing the banner by region and attaching consent to accounts are separate decisions, and the second one does not follow from the first.
None of this is legal advice; it is a reading of what the recommendation says and what it implies for how the state is stored.
Before changing where consent lives, it is worth knowing what actually fires on your site today, signed in and signed out. Scan your site with CookieInspector.