Cookie Consent for Connected TV and IoT: The 2026 Compliance Frontier

Cookie consent has always assumed a browser. A visitor lands on a webpage, a banner appears, they click a button. That model doesn't hold up when the surface is a 55-inch television running a streaming app, a voice assistant on a kitchen counter, or a fitness tracker on someone's wrist.

Connected TV (CTV), smart speakers, wearables, and smart home devices now collect personal data at a scale that rivals the browser — often more intimately. Yet the consent infrastructure that's developed over the past decade barely acknowledges they exist. This is the compliance frontier for 2026: how do you obtain meaningful, legally valid consent on platforms that have no cookie jar, no banner, and sometimes no screen at all?

Why CTV and IoT Are a Consent Problem

The word "cookie" in cookie consent is a misnomer. What privacy law regulates isn't the cookie file itself — it's the collection of personal data and the storage of information on a user's device. Cookies are the most common web mechanism, which is why the ePrivacy Directive focused on them. But the legal principle is technology-neutral.

Connected TVs don't use browser cookies. They rely on device identifiers (Android's Advertising ID, Apple's IDFA equivalent for tvOS), Automatic Content Recognition (ACR) that fingerprints what's on screen, and IP-based household graphs that link a TV to every other device on the same network. Under the GDPR, these trigger the same consent requirements as a marketing cookie.

IoT devices go further. A smart speaker records voice commands. A wearable tracks heart rate, location, and sleep patterns — categories that often qualify as special category data under Article 9 GDPR, requiring explicit consent. A smart thermostat learns occupancy patterns. The data is personal, the collection is continuous, and the "notice and choice" model that works on a web page has no obvious equivalent.

The Growth of CTV Advertising

CTV advertising is growing rapidly as viewing shifts from linear broadcast to streaming. Ad-supported tiers have made CTV inventory one of the fastest-growing segments in digital advertising. Programmatic CTV ad buying relies on the same audience-targeting logic as display — behavioural segments, retargeting, cross-device graphs — which means it depends on the same personal data and demands the same consent foundations.

The difference is infrastructure maturity. Web advertising has had over a decade to build consent plumbing: the IAB's Transparency and Consent Framework (TCF), consent management platforms, standardised consent strings passed through the ad-tech supply chain. CTV has almost none of this. Consent signals are fragmented across device manufacturers, app platforms, and ad exchanges, with no equivalent of the TCF consent string.

The principle is straightforward: if you're processing personal data to serve targeted advertising, the lawful basis requirements of the GDPR, CCPA, and other frameworks apply regardless of whether the data came from a browser cookie or a smart TV's device identifier.

Why Traditional Cookie Banners Don't Work Here

A cookie banner is a web UI pattern: an HTML overlay dismissed with a click or tap. It assumes a browser, a pointing device, and a visual layout where a banner can appear without obscuring content. None of these hold on most IoT devices, and they hold only partially on CTV.

No browser, no DOM

Smart speakers have no screen. Wearables have screens too small for a multi-option consent dialogue. Connected TVs run native apps — there's no DOM to inject a banner into, no cookie jar to write a preference to, and no JavaScript tag manager to gate scripts behind consent.

Input constraints

TVs use a remote: directional pad, select button, maybe voice. Smart speakers accept only voice. Wearables have a tiny touchscreen or a single button. The UX patterns that work for web consent — toggles per category, a "manage preferences" panel with explanatory text — are physically impossible on most of these surfaces.

Session model differences

Web consent follows a session model: first visit triggers a banner, preferences stored in a cookie for subsequent visits. IoT devices often have long-lived sessions (a TV logged into a streaming app for months) or no sessions at all (a smart thermostat that's always on). The "first visit" trigger doesn't map cleanly.

Consent Interfaces for Keyboard-Free Platforms

Solving consent on non-browser platforms means designing interaction patterns that are legally sufficient while usable on constrained hardware.

CTV: Remote-navigable consent screens

The most direct approach for connected TVs is a full-screen consent dialogue rendered natively, navigable with a standard remote. The design principles from WCAG-compliant cookie banners carry over: focus states must be visible, "reject" must be equally prominent and reachable with the same number of button presses as "accept," and category-level choices should work without text input.

Progressive disclosure fits well. The first screen presents the core choice (accept, reject, or customise). Selecting "customise" navigates to a second screen with purpose-level toggles operable via the directional pad — the layered approach adapted for a 10-foot UI readable from across a room.

Smart speakers: Voice-based consent flows

Voice is the only input channel for screenless speakers. A consent flow might sound like: "This skill collects usage data to personalise your experience. Say 'allow' to consent, 'deny' to opt out, or 'tell me more' for details." The challenge is making this genuinely informed — GDPR requires clear, specific information about what data is collected and why.

Tiered voice consent addresses this: the device gives a short summary and asks for a top-level choice, then offers to read category-level details on request. First layer concise, second layer comprehensive — the layered banner approach through audio.

Wearables and small screens: Progressive disclosure

Devices with very small screens can present a simplified consent prompt on-device, then direct users to a companion app for granular control. The on-device prompt captures the minimum — "This device collects health data. Tap to allow, or manage settings in the app" — while the companion surface provides full category-level choices.

This split-surface approach works legally as long as the initial prompt constitutes informed consent for default processing and the detailed controls are genuinely accessible.

How Privacy Laws Apply to Non-Browser Contexts

A persistent misconception holds that privacy regulations are "about cookies" and don't apply to devices without them. The regulations are about personal data and terminal equipment — cookies are just one trigger.

GDPR and the ePrivacy Directive

Article 5(3) of the ePrivacy Directive covers "the storage of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user." Connected TVs, smart speakers, and wearables are all terminal equipment. The GDPR's consent requirements (Article 6 and Article 7) apply to any personal data processing, regardless of collection mechanism.

CCPA and US state laws

The CCPA/CPRA applies to "personal information" from California residents — device identifiers, CTV viewing history, and biometric data all qualify. The opt-out model ("Do Not Sell or Share") must be honoured on these platforms. Virginia, Colorado, Connecticut, and other states follow similar patterns. For a comparison, see our guide on GDPR vs CCPA vs PECR.

India's DPDP Act

India's Digital Personal Data Protection Act requires consent before processing and applies regardless of device or interface. Its device-agnostic framing makes it directly relevant to smart home devices, wearables, and connected TVs operating in India.

Industry Solutions Taking Shape

The gap between what the law requires and what the technology supports is narrowing, driven by several developments.

Cross-device consent registries

Rather than trying to replicate per-device cookie banners, some approaches centralise consent in a registry that all devices in a household can query. A user sets their consent preferences once — on a phone app, a web dashboard, or during device setup — and every connected device in the household respects those choices. This is conceptually similar to how regional consent for global websites works: one policy decision, applied contextually across surfaces.

Platform-level consent APIs

Device manufacturers and operating system vendors are building consent infrastructure into the platform layer. Privacy dashboards on TV operating systems, app-level consent prompts modelled on mobile app tracking transparency, and household-level privacy controls are becoming more common. These aren't yet standardised the way the TCF standardised web consent, but they're moving in that direction.

Identity-layer consent signals

As the advertising industry moves toward first-party and cookieless tracking models, consent signals are increasingly attached to identity layers (authenticated user IDs, publisher-provided IDs) rather than to browser storage. This decoupling is inherently cross-platform: a consent signal tied to a user's account works on their phone, their TV, and their smart speaker without requiring a per-device cookie mechanism.

CookieBeam's API-First Approach

A CMP built entirely around injecting a JavaScript banner into a web page hits a wall the moment the platform isn't a browser. An API-first architecture — where consent collection, storage, and signal distribution are exposed as APIs rather than locked inside a widget — can serve any platform that makes an HTTP call.

CookieBeam is built on this principle. Consent state is stored server-side and accessible via API:

• A CTV app calls the consent API during its native onboarding flow, renders consent in its own design language, and stores the response against the device or user account.
• A smart speaker skill queries consent status before activating data collection and records voice-based decisions through the same API.
• A wearable's companion app manages granular preferences on the phone and syncs them to the device.
• A smart home hub acts as a household consent controller, setting preferences once for all connected devices.

The key insight: the consent decision and the consent interface don't have to be coupled. The interface fits the device — remote-navigable screen, voice dialogue, companion toggle. But the decision itself — what was consented to, when, under which notice version — is the same data model regardless of surface.

This also solves cross-device consistency. When preferences live in a centralised API store keyed to an account or household, every device gets the same answer. Withdrawal on any device propagates everywhere — meeting the GDPR's requirement that withdrawal be effective, not just theoretically possible.

Practical Recommendations

If you collect data through non-browser platforms, here's where to start:

1. Audit data flows by device type. Map what each device collects, what identifiers it uses, and where that data goes.
2. Design for the actual input method. Don't port a web banner to a TV. Design natively for the remote, for voice, or for the companion app. Equal prominence for accept and reject is non-negotiable.
3. Centralise consent state. Use an API-based store that every device can query. Per-device silos create inconsistency and make withdrawal impractical.
4. Use progressive disclosure. Essential information first, details on demand — second screen on TV, "tell me more" on speakers, linked web page on wearables.
5. Plan for withdrawal from day one. Every platform that collects consent must offer an equally accessible way to revoke it. See our guide on consent expiry and re-consent.
6. Log everything. Capture the device, interface version, timestamp, and specific purposes — the same audit trail as web consent, extended to every surface.

The Road Ahead

The connected device ecosystem is moving faster than privacy regulation can prescribe interface-level requirements. But the principles are stable: informed, freely given, specific, and unambiguous consent, with withdrawal as easy as granting it. Those requirements don't mention browsers, cookies, or banners — they describe a quality of choice that must be achievable on any device.

The organisations that get ahead of this won't be the ones waiting for regulators to issue CTV-specific guidance. They'll be the ones that recognise consent is a data problem, not a widget problem, and build the API infrastructure to solve it once across every platform they touch.

For more on how privacy-first approaches are reshaping tracking beyond the browser, read our guide on first-party cookieless tracking and Google's Privacy Sandbox and Topics API.