IllustrationIoT wearables are body-worn devices that send sensor data to a phone, network or cloud. Many use Bluetooth LE to a phone app that forwards data to the cloud. Direct LTE-M or Wi-Fi removes the phone but costs more power, antenna space and certification work. Pick the link from where data must go and how often.
This guide is for the team that has to build an IoT wearable. It covers the three common links, what each costs in power, how data should reach your cloud, safe firmware updates, and the security basics to plan before the schematic is frozen. Every figure links to the page we read, as of November 2026.
This is an engineering summary and not legal advice. For health wearables it covers general wellness products only, and it is not a guide to medical devices.
How do IoT wearables connect to the internet?
Many wearables reach the internet through a phone. The other two paths put a cellular modem or a Wi-Fi radio in the device. Each one changes the battery, the antenna, the app and the test plan.
Bluetooth LE through a phone
Bluetooth LE was built for low power. The Bluetooth SIG overview says the LE radio "is designed for very low power operation", and lists PHY rates of 2 Mb/s (LE 2M), 1 Mb/s (LE 1M), and 500 kb/s or 125 kb/s for the two LE Coded modes, as of November 2026 (Bluetooth technology overview). Those are raw radio rates. Your app will see less.
The phone app is now part of the product. If the phone is out of range or the app is stopped, data waits on the device. Plan the buffer and sync for that.
Direct cellular
LTE-M modems are made for small, battery-powered devices. Nordic's nRF9160 product brief lists LTE-M and NB-IoT in one package of 10 x 16 x 1.04 mm, output power up to 23 dBm, and support for the PSM and eDRX power saving modes, as of November 2026 (nRF9160 product brief v2.1). The device can send an alert with no phone near. You pay with a SIM, a data plan per unit, a larger antenna and high-power transmit bursts.
Wi-Fi
Wi-Fi suits a device that uploads at home while it charges. Its active current is far higher than Bluetooth LE, and the user must join it to a network through the app.
Which link fits your wearable?
Start from where the data must end up and how fast. If a reading can wait an hour for the phone, Bluetooth LE is the simplest choice. If an alert must reach a caregiver when no phone is near, you need cellular. If the device only syncs at home, Wi-Fi at the dock can work. For the bitrate math behind each link on a voice device, see cellular, Wi-Fi or phone tether.
| Link | Data path | What the device needs | Power picture | Typical fit |
|---|---|---|---|---|
| Bluetooth LE to a phone app | Wearable to phone app to your cloud. | BLE radio, small antenna, a phone app that forwards data. | Radio current in single-digit milliamps on the Bluetooth LE part below. | Bands, rings and patches that sync a few times a day. |
| Direct cellular (LTE-M) | Wearable to the cell network to your cloud. No phone. | Modem, SIM or eSIM, larger antenna, a data plan per unit. | Very low sleep current, short high-power transmit bursts. | SOS, elder care and tracking devices that must report with no phone near. |
| Wi-Fi | Wearable to a known access point to your cloud. | Wi-Fi radio and a network setup flow in the app. | High active current, low deep sleep. | Devices that upload in bulk at home, often on a dock. |
Many products combine links. A cellular wearable often keeps Bluetooth LE for setup and for nearby sync, so it can leave the modem asleep when a phone is present. For the full layer view, from device to app to cloud, and who holds which keys, see our guide to IoT architecture for a connected device.
Any radio worn on the body also raises RF exposure. The FCC rule defines a portable device as one whose radiating structure is generally used within 20 centimeters of the body of the user (47 CFR 2.1093). For the general population, the SAR limit is 1.6 W/kg averaged over any 1 gram of tissue. Hands, wrists, feet, ankles and pinnae are extremities, where the limit is 4 W/kg averaged over any 10 grams (47 CFR 1.1310). Both as of November 2026. A 23 dBm cellular transmitter on the wrist makes this a planning item for Gate 0. Ask your test lab how it will evaluate your device.
How much power do wearable IoT devices spend on the radio?
The table lists published figures for three parts. They come from three vendors under different conditions, so read them as orders of magnitude.
| Part | Active radio | Sleep | Where the figure is | Source |
|---|---|---|---|---|
| TI CC2340R5 (Bluetooth LE) | 5.1 mA transmit at 0 dBm; under 11.0 mA transmit at +8 dBm; 5.3 mA receive | Under 710 nA standby on the CC2340R52 variant; 165 nA shutdown | Features list, SWRS272F, revised May 2026 | TI datasheet, as of November 2026 |
| Espressif ESP32-C3 (Wi-Fi and Bluetooth LE) | 276 to 335 mA peak Wi-Fi transmit, depending on mode; 84 to 87 mA Wi-Fi receive | 130 µA light-sleep; 5 µA deep-sleep with RTC timer and memory; 1 µA power off | Tables 5-7 and 5-9, v2.4; 3.3 V, 25 °C, transmit at 100% duty cycle | Espressif datasheet, as of November 2026 |
| Nordic nRF9160 (LTE-M and NB-IoT) | Output power up to 23 dBm; LTE-M throughput 300 kbps down and 375 kbps up | 2.7 µA PSM floor current; 6 µA average for LTE-M with a 655 second eDRX interval | Product brief v2.1; current at 23 dBm TX, 3.7 V supply | Nordic product brief, as of November 2026 |
Two points stand out. The ESP32-C3 peak Wi-Fi transmit current of 335 mA is about 65 times the CC2340R5 Bluetooth LE transmit figure of 5.1 mA. The two are measured at very different output powers (21 dBm against 0 dBm), so the gap shows scale only. Second, the sleep floors of all three parts are in the single microamps or below. What drains the battery in practice is how often the radio wakes and how long it stays on.
Build the budget state by state:
- List every state: deep sleep, sensing, processing, advertising or paging, connected sync, transmit burst, charging.
- For each state, write the current and the time spent per day. Mark which values come from a datasheet and which you measured on your board.
- Multiply current by time, add up the charge per day, and divide the usable battery capacity by it.
- Add what a chip datasheet leaves out: sensors, regulator losses, flash writes, LEDs, haptics and retries.
- Measure the whole device over a full day profile and replace datasheet values with measured ones.
For cellular, the number of wake-ups matters most. The nRF9160 brief gives a 6 µA average for LTE-M with eDRX at a 655 second interval, as of November 2026 (product brief). Every report on top of that adds a transmit burst, so the reporting policy drives battery life.
How should data move from the wearable to the cloud?
A wearable is offline much of the time. Design the data path so that no reading is lost when the phone is away, the battery dies or a sync fails halfway.
Buffering and sync
- Store first, send later. Write each record to flash with a timestamp and a sequence number before any upload.
- Delete only after an acknowledgment. The cloud confirms the last sequence number it stored, and the device frees space up to that point.
- Size the buffer from the worst gap. Decide how many days without a phone the product must survive, and what it drops first when full.
- Keep time honest. Store uptime with each record and correct it against phone or network time at sync.
- Send summaries when you can. Raw sensor data costs more air time than a computed value.
If the device collects health-related data, have counsel review what the app and cloud must do with it. Keep claims at general wellness level, and see our health wearable development page for this category.
Over-the-air updates
A bad update can stop a wearable from booting, so use a bootloader that keeps a known good image. MCUboot's design document describes a primary and a secondary image slot. A new image is swapped in as a test. If it does not mark itself OK, MCUboot performs a revert swap on the next reboot and boots the old image. Before it copies an image into the primary slot, the bootloader checks that the image's SHA256 hash matches and, for a signed image, verifies the signature with a public key embedded in the bootloader, as of November 2026 (MCUboot design).
Also decide the minimum battery level for an update and whether it runs only on the charger. On cellular, the modem has its own firmware. The nRF9160 brief says its SDK includes secure firmware over the air for both the application and the modem firmware, as of November 2026 (product brief). See our article on OTA update failures.
What security basics does an IoT wearable need?
NIST IR 8259A, the IoT Device Cybersecurity Capability Core Baseline, was published as final in May 2020. NIST describes it as a set of device capabilities generally needed to support common cybersecurity controls (NIST IR 8259A, as of November 2026). It is guidance, and a good design checklist. The six names come from the publication. The decisions are our suggestions.
| IR 8259A capability | Decision for a wearable |
|---|---|
| Device Identification | A unique logical and physical identifier per unit, written on the factory line. |
| Device Configuration | Which settings the user, app and cloud can change, and what a factory reset clears. |
| Data Protection | Encrypt data in flash and on every link. Give the user a way to wipe the device. |
| Logical Access to Interfaces | List BLE services, debug pins, USB and test pads. Lock each one users do not need. |
| Software Update | Updates by authorized entities only, each image verified before install, rollback supported. NIST lists these items. |
| Cybersecurity State Awareness | Which events the device reports, such as failed pairing or a rejected update, and where. |
The FCC Cyber Trust Mark is a separate, voluntary label. The FCC adopted it in March 2024 in Report and Order FCC 24-26, as a voluntary labeling program for wireless consumer IoT products. The order defines a product as one or more IoT devices plus the other components needed to use them, such as companion apps, gateways and cloud services. It relies on NIST IR 8425, which it describes as built on IR 8259A and IR 8259B (FCC 24-26). Read that way, a Bluetooth LE wearable's app and cloud would be part of the labeled product. On April 13, 2026, an FCC bureau notice selected the ioXt Alliance as Lead Administrator and said the previous administrator's initial recommendations were being reviewed by bureau staff (DA 26-354). Both as of November 2026. Date-stamp any plan that depends on the label. See our guide to US IoT security rules for the state law side.
What should you ask your hardware team?
Take this list to your first design review.
- Where must the data end up, how often, and can it wait until a phone or Wi-Fi network is in range?
- What is the power budget per state, and which values are measured on our board?
- How does a sync prove that each record reached the cloud before the device deletes it?
- Does the flash layout hold two firmware images, and does the device revert if a new image never confirms itself?
- What is the minimum battery level for an update?
- Which of the six NIST IR 8259A capabilities does each part of the product cover: device, phone app and cloud?
- Where on the body is it worn, and has the test lab confirmed the RF exposure plan?
Questions about IoT wearables
What are IoT wearables?
Body-worn devices that collect sensor data and send it to a phone, a network or a cloud service, such as a band that syncs to an app or a pendant with its own LTE-M modem.
Do wearable IoT devices always need a phone?
No. A Bluetooth LE wearable relies on a phone app. An LTE-M device uses the cell network directly, and a Wi-Fi device uses an access point. Both cost more power per transmission.
Is the FCC Cyber Trust Mark required for a wearable?
How could Duobay help with a connected wearable?
We plan FCC, lab and module rules from Gate 0. Gate 0 is a paid feasibility study, and it is the point to settle the link, power budget and update design before the schematic is frozen. Firmware source and an SBOM are delivered, and you hold the keys. Tell us about your device.
If you are choosing a link and a power budget for a connected wearable, tell us about your device and we will set up a first call.
Sources
All pages accessed November 5, 2026. Datasheets and rules change, so re-read them before you rely on any figure.
- Bluetooth SIG, Bluetooth technology overview: https://www.bluetooth.com/learn-about-bluetooth/tech-overview/ (accessed 2026-11-05)
- Texas Instruments, CC2340R2 and CC2340R5 datasheet, SWRS272F: https://www.ti.com/lit/ds/symlink/cc2340r5.pdf (accessed 2026-11-05)
- Espressif, ESP32-C3 Series datasheet v2.4: https://documentation.espressif.com/esp32-c3_datasheet_en.pdf (accessed 2026-11-05)
- Nordic Semiconductor, nRF9160 SiP product brief v2.1: https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF9160-SiP-PB-v2.1.pdf (accessed 2026-11-05)
- 47 CFR 2.1093, Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-J/section-2.1093 (accessed 2026-11-05)
- 47 CFR 1.1310, Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-1/subpart-I/section-1.1310 (accessed 2026-11-05)
- MCUboot, Bootloader design: https://docs.mcuboot.com/design.html (accessed 2026-11-05)
- NIST, IR 8259A publication page: https://csrc.nist.gov/pubs/ir/8259/a/final, and the PDF for the capability names (accessed 2026-11-05)
- FCC, Report and Order FCC 24-26: https://docs.fcc.gov/public/attachments/FCC-24-26A1.txt (accessed 2026-11-05)
- FCC, DA 26-354, Lead Administrator selection: https://docs.fcc.gov/public/attachments/DA-26-354A1.txt (accessed 2026-11-05)
Planning a health wearable? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →