Consent on a Wrist: Smartwatch Data, Companion Apps, and Choices Too Big for the Screen
A smartwatch is a sensor platform with a screen the size of a postage stamp. It measures heart rate, movement, sleep, location, and sometimes blood oxygen and temperature, streaming the lot to a companion app on the phone, which forwards selections of it to the maker's cloud and, often, to research programs, fitness platforms, and advertisers' measurement tools. The consent surface for all of this is a setup wizard on the phone, scrolled through on unboxing day, plus a settings page nobody revisits.
That arrangement strains the idea of informed choice in specific, fixable ways. This guide looks at where consent decisions actually sit in a wearable stack, which of them the standard setup flow handles badly, and what makers and app developers can do about the mismatch between continuous collection and one time permission.
The setup wizard is doing too much
Unboxing day bundles everything: account creation, pairing, software update, health permissions, notification access, location, analytics, and marketing, presented as a cheerful staircase of continue buttons. Bundling is the first failure. A person who wants the watch to tell time and count steps cannot reach basic function without walking past, and often through, data sharing choices framed as part of setup. Separate the stairs. Function critical permissions, the sensors the purchased features need, belong in setup. Optional sharing, product analytics, research programs, advertising measurement, belongs in a later, calmer moment with honest defaults, ideally after the user has seen what the device collects, because only then is the choice informed by anything real.
Health adjacent data is not ordinary telemetry
Heart rate variability, sleep staging, cycle tracking, and oxygen saturation sit adjacent to medical data, and in some jurisdictions and contexts they are health data outright, with the consent standards to match. Wearable platforms tend to file them under fitness and process them with product analytics tooling that would never be allowed near a clinic's systems. The review question for any wearable data flow is whether the tooling receiving it is appropriate for its sensitivity: an advertising SDK has no business in the path of reproductive health data, and crash reporting should not be shipping sensor logs. Map the flows by data type, not by feature, and let the most sensitive type on any path set the rules for that path.
The watch face should say little and mean it
The watch itself cannot host a privacy center, and pretending otherwise produces consent theater on a one inch screen. What the wrist can do well is status and interruption: a clear indicator when location or microphone is active, a one tap pause for sensing, and honest prompts when a new feature wants a new data type. The failure to avoid is the silent expansion, where an update enables a new metric, a new sharing partner, or a new inference, and the only notice is a line in release notes. New collection deserves a new choice, made in the companion app where explanation fits, with the watch limited to alerting that something is waiting for the user's attention.
Retention and the secondhand problem
Wearables are resold, gifted, and handed down, and their data histories are stickier than the hardware. Accounts accumulate years of continuous physiology, and the deletion path is usually a settings page maze ending at a support ticket. Consent design includes the exit: a clear, self serve way to export and delete the full history, and a device reset that genuinely detaches the hardware from the account. Test the secondhand journey as a privacy feature. If a buyer can see the previous owner's data, or the previous owner cannot remove theirs, the platform's consent story fails at exactly the point where a stranger's data is exposed, which is the failure regulators remember.
Related reading
These earlier guides cover connected questions in more depth: Email Tracking and Consent: Pixels, Clicks, and the Rules Beyond the Banner, Dark Patterns in Cookie Banners: Designs That Invalidate Consent, and Consent for Connected Cars and In Vehicle Screens.
Frequently asked questions
Is smartwatch data legally health data?
It depends on the data type, the jurisdiction, and what the maker claims and infers from it. Some wearable data is regulated health data in some places, and several types, reproductive and cardiac especially, attract health level scrutiny even where the device is sold as a wellness product. Treating it as sensitive by default is the safer design standard.
We make an app that reads wearable data. What is our consent duty?
Your app inherits the sensitivity of what it reads. You need your own clear explanation and choice for what you take from the platform, how long you keep it, and whom you share it with, separate from the platform's setup flow. 'The watch maker got permission' does not transfer to your analytics or advertising uses.
Should sensor collection pause when consent is withdrawn?
Yes, for the categories withdrawn. Withdrawal inside the companion app should propagate to the watch's collection and to queued uploads, not just stop a cloud dashboard from updating. Test the propagation end to end; the gap between the toggle and the sensor is where wearable privacy claims usually break.
How do we handle consent for a child's wearable?
With the strictest settings in the product: parental setup and control, no advertising or profiling categories at all, minimal retention, and data sharing off by default. Children's continuous location and health data is among the most sensitive consumer data that exists, and several jurisdictions regulate it specifically.