Wearables Security Guide: Data, Pairing and Enterprise Risks

Wearables collect continuous location, health and behavioural data through a chain of weak links, from a Bluetooth radio with no screen to a phone app and a consumer cloud account, and every link has leaked data at scale. Smartwatches, fitness bands, rings, smart glasses, hearables and clinical wearables now sit on most employees and many patients. This guide covers the wearable data chain, Bluetooth pairing and radio risks, companion app and cloud account security, location and aggregation exposure, enterprise risks such as notification leakage and recording glasses, and the product and privacy regulation that applies. It is written for security architects, mobility and endpoint teams, privacy officers and product security teams building or buying wearable devices.

Key takeaways

• Secure the whole chain, not the device. A wearable is a sensor, a radio link, a phone app, a cloud account and an API, and most real exposures happen in the app, account and sharing settings rather than on the wrist.
• Pairing method decides radio security. Bluetooth LE Secure Connections with Numeric Comparison or Passkey Entry resists eavesdropping and man in the middle attacks; Just Works pairing does not protect against an active attacker during pairing.
• Aggregated fitness data reveals locations. The Polar Flow exposure let investigators identify about 6,500 users and over 650,000 exercises at more than 200 sensitive sites, including home addresses.
• Enterprise risk is mostly data on the wrist and in the room. Notifications mirror email and one time codes to watches, and camera glasses can record secure areas, so policy must cover both.
• Health data rules reach consumer devices. The FTC Health Breach Notification Rule covers apps and connected devices that track fitness or sleep, and treats unauthorised disclosure as a breach.

The wearable data chain

Most wearables have little processing power and no direct internet connection. They rely on a phone over Bluetooth Low Energy (BLE), which relays data to the vendor cloud, which then shares it with third party apps, employers, insurers or clinicians through APIs. Each hop has its own identity and its own failure modes.

For the general device side see the IoT Security Guide; this guide focuses on what is specific to devices worn on the body.

Pairing and radio security

NIST SP 800-121 Rev. 2, Guide to Bluetooth Security, remains the main government reference for Bluetooth Classic (BR/EDR) and Bluetooth Low Energy. The Bluetooth Core Specification defines LE Secure Connections, introduced in version 4.2, which uses Elliptic Curve Diffie-Hellman on the P-256 curve for key agreement. Older LE Legacy Pairing can be broken by a passive listener who captures the pairing exchange, so devices still using it should be treated as having an unencrypted link in practice.

• Privacy addresses: a wearable that advertises a fixed Bluetooth address can be tracked by any receiver in range. LE privacy uses resolvable private addresses that change periodically and can only be resolved by bonded devices. Check that the device uses them, and that advertising data does not contain a static serial number or the owner's name.
• Bonding hygiene: wearables store long term keys for each bonded phone. A factory reset must delete them, and second hand or reissued devices must be reset before reuse.
• GATT exposure: attribute services that can be read or written without encryption, such as a firmware update or configuration characteristic, are a common product flaw. Require authenticated and encrypted access (security level 3 or 4 in LE security mode 1) for anything that changes the device.
• Firmware updates: updates delivered over BLE must be signed and verified on the device. ETSI EN 303 645 provision 5.3 (keep software updated) and 5.7 (ensure software integrity) give a testable baseline. Smart meters face the same problem at fleet scale; see our smart meter security guide.
• Vulnerability handling: the Bluetooth SIG runs a Bluetooth Security Response Program for specification level flaws. Vendors still need their own disclosure process (ETSI EN 303 645 provision 5.2).

For radio level attack detail see the Bluetooth, RFID and NFC Security Guide.

Companion apps, cloud accounts and APIs

The companion app and cloud account usually hold years of history, and they are protected by consumer authentication. A stolen account gives an attacker the user's routes, sleep and heart data, and sometimes control of the device.

• Account takeover: credential stuffing against health and wellness accounts works because MFA is optional and passwords are reused. The 23andMe credential stuffing breach shows the pattern: about 18,000 accounts accessed with reused passwords led to data on nearly 7 million people because a sharing feature exposed connected users. Wearable platforms with social, family or team features have the same blast radius problem.
• Third party connections: users connect wearable accounts to training apps, insurers and employer wellness platforms with OAuth. Those grants are long lived and broad. Review scopes, set expiry, and give users a single place to revoke them. See the OAuth 2.0 and OpenID Connect Guide.
• API keys in apps: companion apps have shipped with hard coded cloud keys. See iOS Apps Leaking Hard-Coded Secrets for how common this is, and test against OWASP MASVS before release.
• Local data on the phone: health data cached by the app must be protected by the platform keystore and excluded from unencrypted backups.

Location and aggregation exposure

Individually harmless workouts become intelligence when aggregated. In January 2018, the Strava global heatmap revealed the outlines of military bases from activity data. Later that year, Bellingcat and De Correspondent showed that Polar Flow placed all of a user's sessions since 2014 on one global map. From a sensitive site they could open a profile and see where the person lived, and they identified nearly 6,500 users who had logged over 650,000 exercises at more than 200 sensitive sites. Making sessions private only affected new sessions, and profiles showed names and photos even when set to followers only. Polar temporarily suspended its Explore feature.

• Defaults matter more than options: Strava now hides the first and last 200 metres of an activity by default after the first upload and lets users hide starts and ends within a radius of an address or hide the whole map. Strava itself notes that map visibility does not stop someone deducing a hidden location from other information.
• Personnel in sensitive roles: defence, intelligence, executive protection and critical infrastructure staff should have specific guidance on public profiles, heatmap participation and GPS use near sites.
• Product design: privacy changes should apply retroactively, sharing should default to private, and aggregate products should exclude sparse areas where a few users can be singled out.

Enterprise risks and policy decisions

Most organisations do not issue wearables, yet staff bring them to every meeting. The risks are data leaving through the wrist and recording in the room.

• Notification mirroring: a watch shows email subjects, chat messages and one time passcodes to anyone glancing at it, and stores them on a device that is rarely managed. Use app protection policies on the phone to block corporate app notifications from being mirrored, or redact their content.
• Wearables as authenticators: watches can unlock paired phones and computers, approve payments and hold transit or access credentials. That convenience depends on the watch being locked when removed. Require wrist detection and a passcode for any watch used to approve corporate access.
• Camera and microphone glasses: camera glasses record discreetly and some send captures to a cloud AI assistant. Treat them like phones in secure areas, and treat their AI uploads as a data transfer to a third party. See the Employee Monitoring and Privacy Guide where employers want to use wearables to track staff.
• Clinical wearables: remote patient monitoring devices feed clinical decisions, so integrity and availability matter as much as confidentiality. See the Healthcare Identity Security Guide.

Small organisations can usually stop at policy and phone side app protection. Large and regulated organisations that issue wearables should manage them as assets, require supplier evidence against ETSI EN 303 645 or NISTIR 8259A, and review vendor data processing agreements.

Regulation that applies

• FTC Health Breach Notification Rule (16 CFR Part 318): as amended in 2024, it covers an online service such as a website, mobile application or internet connected device that tracks health related data such as fitness or sleep. A breach of security includes unauthorised disclosure, not only hacking. Individuals must be notified without unreasonable delay and no later than 60 calendar days after discovery, and the FTC at the same time when 500 or more people are affected. See the Health Data Privacy Beyond HIPAA Guide.
• HIPAA: applies only when the data is handled by or for a covered entity such as a provider running remote monitoring. Consumer fitness data held by a device vendor is normally outside HIPAA, which is why the FTC rule and state laws matter.
• GDPR: heart rate, sleep and similar data are usually health data under Article 9, and biometric unlock data is special category where used to identify a person.
• Product security: the UK PSTI regime applies to consumer connectable products, including wearables. In the EU, Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive has applied since 1 August 2025 to internet connected and wearable radio equipment, and the Cyber Resilience Act adds vulnerability reporting obligations from 11 September 2026 and full requirements from 11 December 2027. ETSI EN 303 645 is the common technical baseline. See the ETSI EN 303 645 Consumer IoT Guide.

How to implement

1. Set policy first. Publish an acceptable use rule for personal wearables by zone, using the table above, and brief staff in sensitive roles on location sharing.
2. Control data on the wrist. Deploy app protection policies that redact or block corporate notifications on paired watches. Pilot with one department for two weeks, check that MFA prompts still work, then roll out. Roll back by reverting the policy assignment.
3. Inventory issued devices. Record every corporate wearable with owner, firmware, pairing method, companion account and data destination.
4. Harden pairing and accounts. Require Secure Connections pairing with Numeric Comparison, Passkey Entry or OOB for issued devices, organisation owned cloud accounts with MFA, and reset procedures that clear bonds and data.
5. Assess suppliers. Ask for the declared security update period, ETSI EN 303 645 or NISTIR 8259A evidence, a vulnerability disclosure policy, and where data is processed.
6. Complete a DPIA for any programme that uses wearable data about employees or patients, including retention and third party sharing.
7. Review twice a year. Recheck firmware currency, third party grants and support end dates.

Detection and measurement

Most monitoring happens on the phone and in the cloud account. Watch for companion account sign-ins from new locations and password resets, new third party OAuth grants, firmware version drift across issued devices, unknown Bluetooth devices bonding to managed phones where the MDM reports it, and data egress volumes from clinical hubs.

• Policy coverage: percentage of managed phones with notification protection applied to corporate apps.
• Firmware currency: percentage of issued wearables on the latest vendor firmware within 30 days of release.
• Secure pairing rate: percentage of issued wearables paired with an authenticated method.
• Account MFA rate: percentage of organisation owned wearable cloud accounts with MFA.
• Grant hygiene: number of third party data connections without a reviewed purpose, per quarter.

Framework mapping

For threat modelling, the relevant ATT&CK for Mobile techniques on the paired phone include T1430 Location Tracking, T1429 Audio Capture and T1636 Protected User Data.

Common failure patterns

• Just Works pairing on devices carrying sensitive data: clinical or audio devices paired without authentication in public places.
• Non-retroactive privacy settings: as with Polar Flow, users who switch to private still expose years of history.
• Optional MFA on health accounts: credential stuffing succeeds and family or team sharing multiplies the damage, as the 23andMe breach shows.
• Corporate one time codes on unmanaged watches: MFA codes and sensitive message previews mirrored to a device anyone can read.
• Reissued devices not reset: bonds, accounts and history carried over to the next wearer.
• Forgotten third party grants: wellness programmes and apps keep pulling data years after the user or employer stopped using them.

Practitioner checklist

• Publish a wearable acceptable use policy by zone, including camera glasses.
• Block or redact corporate app notifications on paired watches through app protection policy.
• Require LE Secure Connections with an authenticated pairing method for issued wearables.
• Use organisation owned companion accounts with MFA for every issued device.
• Reset devices, bonds and accounts before reissue or disposal.
• Obtain the security update period, ETSI EN 303 645 evidence and disclosure policy from each supplier.
• Complete a DPIA and confirm whether the FTC Health Breach Notification Rule, HIPAA or GDPR Article 9 applies.
• Brief staff in sensitive roles on heatmaps, public profiles and GPS near sites.
• Review third party data grants and firmware currency twice a year.

Standards and references

• NIST: SP 800-121 Rev. 2, Guide to Bluetooth Security
• NIST: IR 8259A, IoT Device Cybersecurity Capability Core Baseline
• ETSI: EN 303 645, Cyber Security for Consumer Internet of Things
• eCFR: 16 CFR Part 318, Health Breach Notification Rule
• FTC: Health Breach Notification Rule
• Bluetooth SIG: Bluetooth Security
• Bellingcat: Strava and Polar revealing homes of soldiers and spies
• Strava: Map Visibility

Related NHI Mgmt Group resources: XR and Metaverse Security Guide · Bluetooth, RFID and NFC Security Guide · Mobile Device Security Guide · Device and IoT Identity Guide