Cross-Device Consent: How to Sync Cookie Preferences Across Desktop and Mobile

Why Cross-Device Consent Matters

A single user might visit your website from a phone during their commute, a laptop at work, and a tablet on the sofa. Each device stores its own cookies, which means each device has its own consent record. The result: the same person sees your cookie banner three times and must make the same choices three times.

This repetition feeds directly into consent fatigue. Visitors grow irritated. Some click "accept all" just to make the banner disappear, which undermines the purpose of informed consent. Others abandon the site entirely.

Cross-device consent synchronisation solves this by linking a user's cookie preferences to their identity rather than their browser. When done correctly, it reduces friction, improves consent quality, and aligns with emerging regulatory guidance.

The CNIL Multi-Device Consent Framework

In January 2026, the CNIL published final recommendations on multi-terminal consent for cookies and trackers. These recommendations, adopted on 18 December 2025, amend the CNIL's existing cookie guidance to address how consent should work when users access services from multiple screens.

The core principle is straightforward: organisations may collect a single consent for the use of trackers across all terminals connected to the same user account. But this mechanism is only valid in what the CNIL calls an "authenticated universe" - meaning the user must be logged in.

Several strict conditions apply:

• Transparency on the first layer - Details of the multi-device consent mechanism must appear on the first layer of the consent interface, not buried in a secondary menu.
• New device notification - When a user logs in on a device not previously linked to their account, a temporary notification must confirm that the account-level preferences now apply to that device.
• Symmetry of choices - If consent can be given globally across devices, refusal and withdrawal must have the same global scope. You cannot globalise acceptance alone.
• Shared device protection - Preferences expressed outside an authenticated session must not be overridden by account-level settings. This protects other users of shared devices such as family computers.

The CNIL also addresses conflicting preferences. When a visitor makes a choice on a device before logging in that differs from their stored account preferences, two approaches are permitted: the most recent device-level choice prevails, or the account preference prevails.

GDPR and ePrivacy Requirements for Synced Consent

The ePrivacy Directive (Article 5(3)) requires consent before storing or accessing information on a user's terminal equipment. The EDPB has confirmed that terminal equipment includes smartphones, laptops, tablets, connected TVs, and smart glasses. Each device qualifies as a separate terminal, which is why per-device consent has been the default approach.

Under GDPR Article 7, consent must be freely given, specific, informed, and unambiguous. For cross-device sync to satisfy these requirements, users must be told that their consent choice will apply across devices at the moment they make that choice. Retroactively applying consent collected before you introduced cross-device sync is not permitted - fresh consent is required.

Withdrawal must remain as easy as giving consent (GDPR Article 7(3)). If a user withdraws consent on one device, that withdrawal must propagate across all linked devices without delay.

Technical Approaches to Cross-Device Consent Sync

There are several architectural patterns for synchronising consent across devices. The right choice depends on whether your users authenticate, how many properties you operate, and your technical resources.

Authenticated Consent via Server-Side Storage

This is the most robust approach and the only one the CNIL explicitly endorses. When a user logs in, their consent preferences are stored server-side against their account identifier. On subsequent logins from any device, the CMP retrieves those preferences from the server and applies them locally.

The flow typically works as follows:

1. User visits your site on Device A and sees the cookie banner.
2. User logs in and gives or refuses consent. The CMP stores preferences both locally (in a cookie like cookie_consent) and server-side (linked to their user ID).
3. User visits on Device B and logs in. The CMP queries the server, retrieves the stored preferences, and applies them. No banner is shown unless a new purpose has been added since the last consent update.
4. If the user changes preferences on Device B, the server record updates, and Device A picks up the change on the next authenticated session.

Centralised Consent API

For organisations operating multiple websites or applications, a centralised consent API acts as a single source of truth. Each property calls the API on page load, passing a pseudonymised user identifier. The API returns the current consent state, and the local CMP configures itself accordingly.

This pattern works well for agencies managing consent across multiple websites, enforcing consistent categorisation across properties.

Hashed Identifier Approach

The CNIL specifically recommends against sharing clear-text personal identifiers (such as email addresses) with consent management providers. Instead, use a technical or pseudonymous identifier to link devices. A hashed email address or an opaque user ID achieves the same linkage without exposing personal data to the CMP layer.

Comparison of Sync Methods

All compliant methods require authentication. There is no privacy-compliant way to sync consent across devices for anonymous visitors, because linking anonymous sessions across devices would itself require a tracking mechanism that needs consent.

Handling Edge Cases

Shared and Public Devices

A family tablet or a library computer may be used by multiple people. The CNIL is clear that authenticated consent preferences must not bleed into unauthenticated sessions. When a user logs out, the device should revert to its local, pre-login consent state. If no local state exists, the banner should reappear.

New Purposes Added After Initial Consent

If you add a new cookie category or tracking purpose after a user has already given cross-device consent, you must re-prompt for that specific purpose. The synced consent record covers only the purposes that were presented at the time of consent. This aligns with the specificity requirement under GDPR cookie consent rules.

Conflicting Preferences Between Devices

Consider a user who rejects analytics cookies on their phone but has previously accepted them on their laptop. When you detect a conflict, you have two compliant options: apply the most recent choice (whichever device it came from), or apply the account-level preference. Document which approach you use in your cookie policy and display it clearly in the consent interface.

Implementation Checklist for Developers

If your site has user authentication and you want to implement cross-device consent sync, follow these steps:

1. Audit your current consent storage. Identify where consent records live today - typically in cookies like cookieyes-consent, CookieConsent, or a custom key. Use a cookie scanner to map all consent-related cookies.
2. Design a server-side consent schema. Store user ID (pseudonymised), consent status per purpose (analytics, marketing, functional), timestamp of last update, and the version of purposes presented.
3. Integrate with your authentication flow. On login, query the consent API. If a server-side record exists, apply it. If not, let the banner appear and store the result both locally and server-side.
4. Handle logout correctly. On logout, revert to the device-local consent state or clear it entirely so the next user sees a fresh banner.
5. Add a new-device notification. When the CMP detects a login on a device with no prior consent record, display a brief notification explaining that account-level preferences have been applied.
6. Test conflict resolution. Simulate scenarios where device-local and server-side preferences differ. Verify that your chosen resolution strategy works and that the user is informed.
7. Update your cookie policy and banner text. Inform users on the first layer of the banner that consent applies across devices when logged in.

What About Mobile Apps?

Mobile app consent operates differently from web consent. Apps use SDKs rather than cookies, and identifiers like IDFA (Apple) or GAID (Google) are device-specific. Apple's App Tracking Transparency framework adds another consent layer that operates independently of any CMP.

If your organisation has both a website and a mobile app, syncing consent between them requires a unified backend. The app SDK and the web CMP must both read from and write to the same server-side consent record, keyed to the user's account.

Google Consent Mode and Cross-Device Sync

Google Consent Mode v2 sends consent signals to Google services, controlling how tags like _ga and _gcl_au behave. When you implement cross-device sync, the consent state retrieved from your server must be passed to Consent Mode on each page load before any Google tags fire.

Frequently Asked Questions

Take Control of Your Cookie Compliance

Whether you choose per-device consent or cross-device sync, accurate cookie detection is the foundation. Kukie.io scans your site, categorises every cookie, and helps you manage consent across every device.

Start Free - Scan Your Website