It might seem logical: if a user logs into your service on multiple devices, treat their consent choice as a single, unified preference. One account, one consent state. Your legal team likes it because it's simpler to document. Your product team likes it because it reduces friction. And it feels user-friendly, nobody wants to reject cookies on their laptop, then again on their phone, then again on their tablet.
But this approach creates more problems than it solves.
Why Unified Cross-Device Consent Falls Short
The CNIL's updated guidance on cross-device cookie consent highlights a key issue: what seems like consistency to you can feel like a loss of control to your users. Syncing a consent choice from one device to another assumes context that often doesn't hold.
Think about someone opting into analytics cookies on their work laptop during business hours, then using their personal phone later. Should your system assume they want the same tracking on a device used for personal browsing or financial planning? The device context matters. The CNIL requires organizations to offer device-level controls alongside any account-level synchronization.
Here's the deeper issue: cross-device consent synchronization creates a new processing activity that itself requires consent. You're tracking which devices belong to the same user and applying decisions across them. This is exactly the kind of cross-device tracking that privacy regulations aim to control. Linking consent states across devices builds a cross-device identity graph, even if it's "just" for consent management.
Key Requirements from the CNIL
The CNIL's 2020 recommendations, recently updated, set clear requirements for syncing consent across logged-in sessions. They mandate three specific practices:
Symmetry of Choice must be global. If you sync opt-ins across devices, you must also sync opt-outs. You can't have a system where accepting cookies on one device applies everywhere, but rejecting them stays local. This requirement alone breaks many existing implementations.
Prior Consent to the mechanism itself. Users must be informed "at the beginning of the consent process" that choices made while logged in will apply across devices. This isn't a footnote in your privacy policy. It's first-layer information that appears before the user makes their initial choice.
Conflict resolution must be explicit. The guidance addresses a scenario many teams haven't considered: what happens when a user opts out on a device before logging in, then logs into an account that's opted in? Your system can honor either the device-level choice or the account-level choice, but you must tell users in advance which takes precedence. If you haven't documented this logic and disclosed it, you're making arbitrary decisions about user privacy.
Device-level controls are essential. Even with cross-device synchronization, users must be able to override it at the device level through a preference center or similar interface. This isn't optional flexibility, it's a mandatory control plane.
What to Do Instead
Consider whether you need cross-device consent synchronization at all. For many services, device-level consent is sufficient and simpler to implement defensibly. Each device gets its own Consent Notice, its own consent record, and its own set of controls. No cross-device identity mapping required.
If your service genuinely benefits from account-level consent (for example, a streaming platform where viewing preferences span devices), implement it with full transparency:
Disclose the mechanism before the first choice. Your initial Consent Notice must explain that consent choices will apply across devices when the user is logged in. Don't bury this in layer two.
Build true symmetry. If a user can accept analytics cookies on their laptop and have that choice apply to their phone, they must be able to reject analytics cookies on their phone and have that rejection apply to their laptop. Your CMP architecture must support bidirectional synchronization.
Provide device-level overrides. In your preference center, show users their account-level consent state and give them the ability to set device-specific exceptions. Label these clearly: "Account preference: Accepted | This device: Rejected."
Document your conflict resolution logic. Write down what happens when device-level and account-level choices conflict, then show that logic to users. For example: "If you're logged in, your account preferences take precedence. If you're not logged in, this device's preferences apply."
Track the consent to consent. Maintain a separate record showing that the user was informed about cross-device synchronization and when. This is distinct from the cookie consent itself.
The CNIL has indicated that cross-domain consent guidance is coming next. Expect similar requirements for complexity and disclosure when you operate multiple properties under the same corporate umbrella. CNIL guidelines on cross-domain consent.
When Unified Consent Makes Sense
Cross-device synchronization is appropriate in limited scenarios. If you're operating a subscription service where the user explicitly expects a consistent experience across devices (streaming, productivity tools, cloud storage), account-level consent aligns with user expectations. The key word is "explicitly." The user should understand that their account settings travel with them.
It's also defensible when the alternative creates genuine consent fatigue. If your service requires users to log in on every device and you're asking for consent to dozens of distinct purposes, forcing them to configure preferences separately on each device becomes its own friction problem. But this justification only works if you've actually built the granular controls and clear disclosure the CNIL requires.
The conventional wisdom isn't wrong because it prioritizes user convenience. It's incomplete because it prioritizes engineering convenience while assuming user convenience, then calls the result compliance. The CNIL's guidance forces you to prove that your cross-device architecture serves users, not just your tag infrastructure.
If you can't explain your conflict resolution logic or you're syncing opt-ins but not opt-outs, you're not offering unified consent. You're offering unified tracking with a consent label attached.
