Cross-device consent: what the CNIL expects from an app with user accounts

An optional mechanism, with two conditions

The recommendation defines cross-device consent as a mechanism that applies a user’s choices about reading and writing information on their device to every environment from which they access the service: computer, tablet, smartphone, smart TV, browser or app. Where the user is signed in, those choices are no longer tied to a device but to the account, and they can manage them from any of their devices. The CNIL states at the outset that implementing such a mechanism “is optional and is not an obligation for the controller”.

A controller that does implement it faces two conditions on top of the usual consent rules. The first is symmetry: if consent can be given once for several devices, “the same must apply to refusing or withdrawing consent”. An app that propagated acceptance to every device on the account but made users refuse device by device would not meet it. The second is information: before choosing, the user must know that their choices will apply to every device on which they are signed in.

On that second point, the summary of the consultation published by the CNIL says it amended the text to stress that information about the cross-device scope must appear on the first layer of the consent window, the CMP. The adopted version puts it more loosely: the information “may be given, for example” through that window, “from the first layer of information”. The same summary confirms that a publisher may offer only the cross-device model, with no consent limited to a single device, as long as it meets these conditions.

At sign-in: conflicting choices and the temporary banner

The text dwells on the moment a device joins the account. When no choice is stored on the device, the first time the app is opened for instance, the app shows its consent window before the user signs in, and nothing stops them from making a choice that differs from the one already on their account. The CNIL calls this a conflict and asks the controller to handle it “in a way that is clear and fair to the user”.

It describes two approaches. In the first, the choice made on the new device before sign-in overwrites the account’s and then applies to every other device: the latest choice wins, whatever the device. In the second, the account’s choice prevails over the one made before sign-in; to work, the text adds, this requires telling apart the tracking of a signed-in user from that of a signed-out one, “for example through two different cookies and/or identifiers”.

During the consultation, several contributors asked to keep only the second approach. The CNIL declined: neither is unlawful in itself, and it is up to the controller to pick one and inform people accordingly. It does, however, encourage the industry to converge on a single approach, so that the mechanism reads the same way from one site or app to the next.

Either way, the user must be informed after signing in. On a device not yet linked to the account, the recommendation provides for a “temporary information banner” that recalls the scope of the choices and how to change them, and says whether the account’s choices have been saved or modified. In case of conflict, under the second approach, the banner says that the two choices differ and that the account’s choice still applies. Some contributors wanted the banner to be interactive; the CNIL rejected the idea of collecting a new consent there, which in its view would defeat the purpose of the mechanism.

At sign-out, the device goes back to its own choices

The text draws a clear line between the signed-in and the signed-out worlds: choices attached to an account must not alter those stored on a device outside a session. The CNIL gives the example of a shared device, the family computer or the household’s smart TV. One member’s choices, possibly made on their own phone, must not be imposed on the other people using the shared screen who are not signed in to that account.

The consultation summary draws a consequence that affects a widespread practice. One contributor argued that the recommendation called into question the habit of linking a device to a user who has signed in on it, even after they sign out. The CNIL kept the rule: cross-device choices belong to the account, and once the user signs out, the choices tied to the device apply. In an app, signing out therefore changes which choice applies, and the SDKs it embeds have to follow that change.

The identifier given to the CMP, the one point visible in the traffic

To reconcile the devices of a single user, the consent management platform has to know that they belong to the same account. Paragraph 7.5 governs what the publisher sends it. In the name of data minimisation and data protection by design, set out in Article 25 GDPR, the CNIL recommends not sending the account identifier to the CMP provider when it contains data supplied by the user in clear, “for example, a username containing the first name, or even the surname, or an email address”, and substituting “systematically a technical identifier” for it.

This is the point of the recommendation that leaves a trace outside the interface. When the app itself syncs the account’s choices with the CMP, rather than going through the publisher’s servers, the request goes to an identifiable server and carries whatever designates the user. An email address in clear shows up in a capture of the traffic, without reading the provider’s documentation or the app’s code.

Switching to cross-device means asking again

A publisher that adopts the mechanism cannot extend the consents it has already collected. The text is explicit: consent given on a device before the switch to cross-device “cannot be considered valid for other devices”, since the user was not told about that scope. A new consent, freely given, specific, informed and unambiguous, has to be collected. In an app, choices made before the switch therefore stay attached to the phone on which they were made.

Finally, as good practice, the CNIL encourages letting users revisit their choices device by device, for example from a preference centre attached to the account. A minority of contributors wanted that paragraph removed; the CNIL kept it, noting that good practice is not imposed by law.

What the text leaves aside

The recommendation only covers signed-in environments. Recognising the same user across several devices without them signing in remains outside its scope, the CNIL taking the view that this “would involve intrusive processing”. The opening paragraph of the consolidated version also recalls that being signed in “does not exempt” anyone from collecting the consent required by Article 82 of the French Data Protection Act whenever trackers subject to consent are used.

It does not cover consents collected outside the CMP, for instance in an account creation form. It also leaves open the related question of multi-property consent, a single choice valid for several sites or media of the same group: the CNIL has announced work on that topic in 2026, and recommendations that will be put to public consultation.

Lastly, as its title says, the text proposes practical ways to comply. The legal conditions it refers to are those of the CNIL’s guidelines on Article 82, and that article is what makes consent mandatory for trackers, those of SDKs included.

What an app publisher can check

For an app with accounts that adopts cross-device consent, the recommendation translates into a handful of questions. Does the consent window say, from its first layer, that the choice will apply to every device on the account? Does a refusal reach as far as an acceptance? After signing in on a new phone, does a banner say what was saved and how to change it? Which approach has the publisher chosen for conflicting choices, and has it documented it? Do the account’s choices stop applying at sign-out? Does the CMP provider receive a technical identifier, or the user’s email address?

The first questions can be checked on screen. The last one, like whether SDKs honour the choice, is checked in what the app sends. Skanopy automatically drives the Android app on a real phone, records, before and after the user’s choice, the third-party actors actually contacted and what is sent to them, and dates every finding, version after version. That is the whole point of a mobile app analysis: it does not state the law, it supplies the dated evidence the law is applied to.

Sources

Every finding in this article traces back to one of these documents. Quotations from the CNIL are our translations.

1. CNIL ’26Cookies and other trackers: the CNIL publishes its final recommendations on cross-device consentCNIL, 16 January 2026 (in French)
2. CNIL ’25Recommendation proposing practical ways to comply with cross-device consentCNIL, deliberation no. 2025-131, version adopted on 18 December 2025 (in French)
3. CNIL ’26Summary of the contributions to the public consultation on the draft recommendation on collecting cross-device consentCNIL, January 2026 (in French)
4. CNIL ’26Recommendation proposing practical ways to comply when using “cookies and other trackers”CNIL, consolidated version published on 16 January 2026 (deliberations no. 2020-092 and no. 2025-131, in French)
5. Law 78-17French Data Protection Act, Article 82Consolidated text published by the CNIL (in French)
6. GDPRRegulation (EU) 2016/679, Article 25Official Journal of the European Union