Cross-domain and cross-device consent sync in OneTrust
What it is
Cookies are scoped to the domain that set them, so a visitor's consent choice does not automatically carry over to a sibling domain, a genuinely separate top-level domain, or a mobile app running alongside your web property. OneTrust supports syncing consent across those surfaces by linking it to a persistent identifier - a parent-domain cookie for same-registrable-domain subdomains, or an identity-linked consent profile for separate domains and web-plus-app setups - rather than by any automatic cross-origin mechanism, since browsers don't provide one.
When you need it
You operate multiple distinct top-level domains under one company and don't want a visitor re-prompted for consent on each one.
You run both a web app and a mobile app and want a signed-in visitor's consent choice to apply consistently across both surfaces.
You're consolidating regional or brand-specific sites and need consent state to follow a known visitor rather than resetting at every domain boundary.
How to implement it
- 1
Map which properties genuinely need shared consent state
Don't sync more than necessary - two properties with identical audiences and identical vendor lists benefit from sync; two with different actual data practices may be better served by independent prompts. Subdomains of one registrable domain are the simple case; see this site's own cookie-consent-persistence QA page for that pattern specifically.
- 2
For subdomains of one registrable domain, use a parent-domain cookie
Scope the consent cookie's domain attribute to the parent (webclat.com rather than a specific subdomain) so every subdomain reads the same value - no cross-device profile needed for this case.
- 3
For genuinely separate domains or web-plus-app, use identity-linked profile sync
OneTrust's cross-device/cross-domain capability associates consent to a persistent identifier - an authenticated user ID is the most reliable, a device-linked identifier the fallback for anonymous visitors - rather than only a cookie.
- 4
Confirm the bridging identifier is actually available at consent-check time
If the identifier is only set after login, an anonymous visitor on either surface needs a defined fallback (a fresh prompt, most commonly) rather than an error or a silent skip.
- 5
Decide explicitly how to resolve conflicting consent states across surfaces
If a visitor's choice differs between two synced surfaces (accepted analytics on one, declined on the other), document whether the most recent choice wins or the strictest one does - this is a policy decision that should be made once and applied consistently, not resolved ad hoc by whichever code path runs first.
How to verify it worked
Accept consent on surface A while authenticated, then load surface B in the same session and confirm no re-prompt fires.
Test with the bridging identifier deliberately absent (a logged-out session) and confirm the fallback behavior is a fresh, correct prompt rather than an error or an incorrectly inherited state.
Revoke consent on one surface and confirm it propagates to the other within whatever sync window your implementation defines - don't assume propagation is instant without checking.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.