Cookies and Trackers: How to Manage Consent Across Devices and Across Sites (CNIL Guidance Adapted for Cross-Domain Use)

Users regularly access services through multiple touchpoints: a primary website, related domains (e.g., regional sites), mobile applications, and several devices (desktop, phone, tablet, connected TV). As consent prompts have become more frequent, some organizations want to reduce friction by allowing a user to make a single privacy choice that applies more broadly.

Why “one consent” models exist

These approaches can be acceptable only if they preserve user control. Because they rely on choices linked to an account, identifier, or shared consent record, they involve the processing of personal data and must be implemented with strict transparency and symmetry (accept/refuse/withdraw must be equally easy and equally effective).

Multi-device consent (cross-device): what it means

Multi-device consent (often called cross-device consent) is a mechanism where a user expresses cookie/tracker preferences once (typically after sign-in or when preferences are linked to an account), and the same choices are automatically applied to other devices connected to that account.

Core rule: users must understand the scope before choosing

Before the user makes a choice, the consent interface must clearly state that the decision will apply across all devices associated with the user account. This disclosure should appear directly within the consent collection experience (commonly delivered through a Consent Management Platform, or CMP) and be presented before the user finalizes the choice.

Core rule: the system must handle conflicts transparently

If a device-level choice made before login differs from the account-level preference already stored, the user must be informed that a discrepancy exists and how the service resolves it (for example, whether the account preference will override, whether the user will be prompted to confirm, or whether a new choice will replace the prior record).

Core rule: symmetry of rights across devices

If “accept once for all devices” is available, then “refuse once for all devices” and “withdraw once for all devices” must be equally straightforward and have the same scope. Multi-device consent must never make it harder to exercise rights.

Cross-domain consent (multi-site): adapting the same principles

Cross-domain consent (often described as multi-site consent) is a mechanism where a user’s cookie/tracker preferences are captured once and applied across multiple websites or domains. This is commonly requested by organizations operating several branded domains, regional domains, product domains, or a group of related sites.

What changes versus cross-device

Cross-domain consent expands the scope from “all devices on this account” to “all sites within a defined perimeter.” Because this affects the user’s experience across different domains, the perimeter must be explicit and easy to understand.

Conditions to keep cross-domain consent user-controlled

To align with the same privacy logic CNIL applies to cross-device consent, a cross-domain model should be built around the following requirements:

Clear perimeter: users must be told which sites/domains are covered (for example, “this choice applies to our sites A, B, and C”). Avoid vague language such as “our partners” or “our network” unless the user can see a definitive list at the point of choice.

Same ease of choice across the perimeter: if the user can accept once for all covered sites, the user must be able to refuse or withdraw once for all covered sites, with equal simplicity and identical practical effect.

No silent expansion of scope: if new domains are added to the perimeter later, users should not be treated as having consented to the expanded perimeter without being informed and given a meaningful opportunity to confirm or adjust preferences.

Conflict handling across sites: if the user makes a different choice on one covered site (or on a site before login) than the account-level or group-level preference, the user must be informed and the resolution logic must be predictable (prompt to confirm, apply account preference, or update the global record).

CMP-aligned implementation language (vendor-style, user-facing)

Below is CMP-style language commonly used by consent vendors, adapted to preserve CNIL’s key requirements. You can use this in your banner, preference center, and just-in-time notices.

• Scope disclosure (cross-device): “Your choices will be applied to all devices connected to your account.”
• Scope disclosure (cross-domain): “Your choices will be applied across the following sites: [Site/Domain List].”
• Account-based storage: “We store your preferences in your account settings so they can be respected when you sign in on another device or on our other sites.”
• Equal-action phrasing: “Accept all,” “Reject all,” and “Save my choices” should be presented with comparable prominence and effort.
• Change anytime: “You can change your choices at any time via ‘Cookie Settings’ (Preference Center). Changes apply to all covered devices/sites.”
• New device notice (ephemeral): “Cookie choices linked to your account are already saved. You can review or change them in Cookie Settings.”
• Conflict notice (pre-login vs account): “Your device-level choices differ from your account choices. Please confirm which settings to apply.”
• Audit-friendly wording: “We record the date/time of your preference update and the scope (devices/sites) it applies to.”

GDPR compliance checklist for implementing cross-device consent

This checklist is designed for teams deploying multi-device consent through a CMP and account-linked preference storage. It focuses on operational controls that demonstrate valid consent and user control.

1. Define the consent scope explicitly: confirm whether the consent applies per device, per account (multi-device), per domain, or across multiple domains. Document the perimeter and keep it stable unless re-notified.
2. Present scope disclosure before capture: ensure the banner/CMP states the multi-device impact before the user clicks “Accept,” “Reject,” or “Save.”
3. Ensure symmetry of actions: “Reject all” and “Withdraw” must be as easy as “Accept all,” with the same scope and no additional friction.
4. Implement a durable preference center: provide a persistent “Cookie Settings” entry point on every covered experience, enabling review and modification without re-hunting for controls.
5. Handle pre-login vs post-login conflicts: define and implement conflict logic (prompt user, override rules, or merge logic). Inform the user when a conflict occurs and what will happen.
6. Propagate changes reliably: verify that updates apply to all devices linked to the account (and, if applicable, all covered sites) within a defined and reasonable timeframe, including edge cases (new sessions, logged-out states, and app/SDK environments).
7. Prove consent validity: store consent records with timestamp, scope (devices/sites), purposes/categories, and a reference to the CMP configuration in force at the time of capture.
8. Minimize data used to synchronize preferences: use the least intrusive identifiers needed to apply choices across devices, and keep retention aligned to necessity (avoid indefinite preference identifiers without justification).
9. Keep purpose/vendor mapping consistent: ensure that “analytics,” “ads/targeting,” “personalization,” and other categories mean the same thing across devices and platforms (web/app), and that vendor lists align with those categories.
10. Test withdrawal end-to-end: confirm that withdrawing consent stops non-essential cookies/trackers across devices, including tags fired via GTM/SDKs, server-side tagging, and embedded third parties.
11. Maintain user notice quality: keep the information concise in the banner and provide deeper detail in the preference center (purposes, vendor categories, and how cross-device/cross-domain application works).
12. Operational readiness: ensure support and privacy teams can explain the model, respond to user rights requests, and troubleshoot cases where a device or site appears out of sync.

What users can do if their rights are not respected

If a service does not clearly inform users that their choices apply across devices or across multiple sites, or if it makes refusal/withdrawal more difficult than acceptance, users can first contact the organization (or its Data Protection Officer where applicable). If there is no response within one month, or if the response is unsatisfactory, a complaint may be submitted to CNIL.