Concept renderHardware is the physical board, chips, battery and enclosure. Firmware is the code stored on the device that starts and runs that hardware: bootloader, RTOS and drivers. Software is code that changes more freely, such as embedded Linux services, the phone app and the cloud. Each layer updates through a different path.
Every hardware review uses these three words, and each speaker draws the lines in a different place. This guide walks through one wearable, from the chip up to the cloud, then covers who should hold each source and how each layer updates.
Sources were read on November 5, 2026. This is an engineering summary and not legal advice.
Firmware vs software vs hardware: what is the difference?
The NIST glossary's key test is whether code can be rewritten while it runs. That line is blurrier on modern devices, because firmware in flash can be replaced by an update. It still points to the layer that needs the most care when you change it. For letting an AI agent drive bench instruments, see AI Hardware Debugging: Agents and Lab Instruments.
| Term | NIST glossary wording | In a wearable | Source |
|---|---|---|---|
| Hardware | The material physical components of a system. | The board, chips, sensors, microphone, battery, antenna and enclosure. | NIST CSRC glossary, as of November 2026 |
| Firmware | Computer programs and data stored in hardware, typically in read-only memory (ROM) or programmable read-only memory (PROM), such that the programs and data cannot be dynamically written or modified during execution of the programs. | The image in flash that starts the chip and runs it: bootloader, RTOS, drivers and application code. | NIST CSRC glossary, as of November 2026 |
| Software | Computer programs and associated data that may be dynamically written or modified during execution. | Code on top of an operating system: embedded Linux services, the phone app, the cloud backend. | NIST CSRC glossary, as of November 2026 |
A simple way to hold them apart: hardware is what you can drop on a desk. Firmware makes that object start up and behave like a product. Software runs on top of an operating system, on the device or off it.
What does each layer look like in a wearable?
Take a wrist band or a voice pendant. Sensors, battery and radio sit on a small board. A low-power chip runs the firmware. A phone app pairs over Bluetooth LE, and a cloud backend stores data and serves updates. Some, such as camera wearables, use a Linux SoC and add an embedded Linux layer. The Espressif examples come from the ESP32-S3 documentation for ESP-IDF, as of November 2026.
| Layer | What it does | Who usually writes it | How often it changes |
|---|---|---|---|
| Boot ROM | Runs first after reset. On the ESP32-S3 it loads the second stage bootloader from flash into RAM. | Chip vendor | Never. Espressif says this code is in mask ROM and cannot be modified. |
| Bootloader | In ESP-IDF, the second stage bootloader loads the partition table and the main app image from flash. | Chip vendor base, configured by your firmware team | Rarely. A failed bootloader update can leave a device that does not start. |
| RTOS | Schedules tasks such as sensor sampling, Bluetooth LE and audio capture. ESP-IDF integrates FreeRTOS as a component. | Open source kernel in the chip SDK, configured by your team | With the firmware image. |
| Drivers | Talk to the parts on your board: IMU, heart-rate sensor, PMIC, microphone, flash. | Your firmware team, often from vendor sample code | With the firmware image, and with each board revision. |
| Application firmware | Product logic: sampling, storage, the BLE protocol to the phone, power states. | Your firmware team | Over the air, from the phone app or your backend. |
| Embedded Linux software | Linux SoC designs only: kernel, root file system, services and your own processes. | Distribution or SoC vendor base, plus your team | Package or image updates. |
| Phone app | Pairing, settings, data display, and the relay for firmware updates on BLE devices. | Your app team | App store releases, installed when users choose. |
| Cloud backend | Accounts, device registry, storage, model calls, update hosting. | Your backend team | Server deploys, at any time. |
Sources for the Espressif rows: ESP-IDF application startup flow and ESP-IDF FreeRTOS overview, as of November 2026. Other rows describe common practice.
Hardware
A hardware change means a new revision, new samples and often new tests. It is the slowest layer to change, and it limits every layer above it. Flash size, RAM and the choice of a Linux-class processor set your firmware and software options for the life of the product.
Firmware: bootloader, RTOS and drivers
On a microcontroller wearable, firmware is one image built from several parts. Espressif describes three startup stages for the ESP32-S3, as of November 2026. The ROM bootloader loads the second stage bootloader into RAM. The second stage bootloader loads the partition table and the main app image from flash. Then the application starts, along with the second CPU and the RTOS scheduler. ESP-IDF integrates FreeRTOS, and Espressif says all ESP-IDF applications are written based on it. Your drivers and product logic compile into that same image. Other chip families follow the same pattern: fixed code in the chip, a bootloader you configure, then an RTOS and your application.
Embedded Linux software
A Linux SoC adds a full operating system. Boot firmware runs first, then the kernel, then services and your processes. Boot firmware and operating system can have separate update paths. Raspberry Pi is a public example, as of November 2026. Its flagship models since the Raspberry Pi 4B store the bootloader in an on-board SPI flash EEPROM. A systemd service called rpi-eeprom-update runs at startup and applies a new bootloader image if one is available. Plan for the same split on a Linux wearable. For the chip choice itself, read MCU or Linux SoC for an AI wearable.
App and cloud
The phone app and the backend are ordinary software, and they change much faster than the device. On a Bluetooth LE wearable the app often carries firmware updates to the device, so it is part of the firmware update path.
Firmware vs embedded software: where is the line?
People use "embedded software" for all code that runs on a device. "Firmware" usually means the image on a microcontroller, or the boot code below the operating system on a Linux device. On an MCU wearable the two words often mean the same image. On a Linux wearable they point to different layers with different owners. For the parts of an embedded system and how bare metal, an RTOS and embedded Linux compare, see what an embedded system is.
Gaps cause more trouble than labels, such as a bootloader configuration nobody owns. Write each layer into your PRD with three facts: where it runs, who owns it, and how it updates. The layer table above works as the template. Our firmware development page shows how that work maps to development gates. If you are deciding who writes the firmware, see whether to hire, contract or outsource a firmware engineer.
Who owns the source for each layer?
Owning a device means you can rebuild every image it runs without the original team. Most layers mix vendor code, open source and your code. Use the table as a handover checklist, and have your lawyer read the IP terms.
| Layer | What source exists | What you should receive |
|---|---|---|
| Hardware design files | Schematics, PCB layout, BOM, enclosure CAD. | Native files plus exports, so another team can build the same board. |
| Bootloader | Vendor or open source bootloader, plus your configuration. | The exact source and configuration of the production build, and the signing setup. |
| RTOS and SDK | Vendor SDK and open source kernel under their own licenses. | The SDK version, recorded in the SBOM, and any patches your team made. |
| Drivers and application firmware | Your code. | Full source, build instructions, toolchain version and release scripts. |
| Embedded Linux image | Distribution packages, kernel, device tree, your services. | The image build recipe, your device tree and services, and an SBOM of every package. |
| Phone app and cloud | Your code, plus store and cloud accounts. | Source in your repository, deployed in your own accounts. |
| Keys | Firmware signing keys, device certificates, the certificate authority. | Held by you. A supplier should never be the only holder. |
The test is simple. Give the handover to an engineer outside the project and ask for the release image. If it matches, you own it in practice. The SBOM and source-file handover checklist lists the files in detail.
How do updates differ for hardware, firmware and software?
A failed cloud deploy can be rolled back on your own servers. A failed firmware update in the field can leave a device that does not start. That gap is why firmware updates need more design work.
| Layer | How it updates | What to design for |
|---|---|---|
| Hardware | New board or enclosure revision. | Radio circuit changes can need new FCC filings. |
| Bootloader | Factory programming, sometimes a protected field update. | Decide before launch whether it is ever updated in the field, and how a failed update recovers. |
| Application firmware | Over the air into a second slot, then a reboot. ESP-IDF requires at least two OTA app slot partitions plus an OTA data partition. | Rollback if the new image is not confirmed. Anti-rollback so old vulnerable images cannot boot. |
| Embedded Linux software | Package manager or full image update. | A bootable system after a failed update, and a separate path for boot firmware. |
| Phone app | App store release. | Old app versions in the field. App and firmware must agree on a protocol version. |
| Cloud backend | Server deploy. | Old firmware in the field. Keep the APIs older devices call. |
Source for the application firmware row: ESP-IDF over-the-air updates, as of November 2026. Other rows are engineering reasoning.
How a two-slot firmware update works
In ESP-IDF, as of November 2026, the new image goes into the slot that is not running, and with rollback enabled it must confirm it works or the bootloader returns to the previous image on the next reboot. Sign every image and keep the signing keys in your own hands; why firmware OTA updates brick devices covers rollback, anti-rollback and power loss in detail.
What a security baseline expects from updates
NIST's IoT device cybersecurity core baseline, NISTIR 8259A (May 2020), lists software update as a core capability, as of November 2026. Its elements include remote or local updates, verifying and authenticating an update before installing it, rollback by authorized entities, restricting updates to authorized entities, and the ability to enable or disable updating. Use them as acceptance criteria for your update design.
When a firmware change touches FCC rules
Radio settings often live in firmware. Under 47 CFR 2.1043, as of November 2026, software changes in a transmitter that do not affect radio frequency emissions need no additional filings. Changes to the basic frequency determining and stabilizing circuitry, the modulator or the maximum power rating need a new grant. Software changes to a software defined radio beyond approved parameters, such as frequency range, modulation type or maximum output power, are Class III permissive changes. The grantee files them, and the modified software cannot be loaded until the change is acknowledged. Ask your test lab before any update that changes transmit power, channels or radio modes.
What should you ask your hardware team?
Take this list to your first architecture review. Each answer should name a person or a file.
- Draw the layer map for our device. Which code runs on the chip, on Linux if any, on the phone and in the cloud?
- Which firmware parts come from the vendor SDK, which are open source, and which did our team write?
- Is the bootloader ever updated in the field? If yes, how does a failed update recover?
- How many OTA slots does the flash layout have, and what happens if power drops mid-update?
- What confirms that a new image works, and what triggers a rollback?
- Which firmware changes could touch radio settings, and who checks them against the FCC grant?
- Who holds the signing keys and the device certificate authority today?
Is firmware hardware or software?
Firmware is software stored on the device that runs the hardware. The NIST glossary describes firmware as programs and data stored in hardware that cannot be dynamically written or modified during execution, and software as programs that may be (NIST firmware entry, as of November 2026). Flash-based firmware is still updated, through a controlled path.
Can a firmware update affect FCC certification?
It can. Under 47 CFR 2.1043, software changes in a transmitter that do not affect radio frequency emissions need no additional filing. Software changes to a software defined radio beyond approved parameters are Class III permissive changes (eCFR, as of November 2026). Ask your test lab before you ship an update that changes radio settings. This is not legal advice.
How could Duobay help with firmware for our device?
Duobay writes firmware as part of the custom devices it designs: AI recording wearables, health wearables, trackers, companions and audio hardware. Firmware source and an SBOM are delivered, IP and all source files are assigned to you at every paid gate, and you hold the keys. The app and backend are an option. Tell us about your device.
If you want a layer map, an update plan and a source handover list for your wearable, tell us about your device.
Sources
All pages accessed November 5, 2026. Re-read them before you rely on any rule or figure.
- NIST CSRC glossary, firmware: https://csrc.nist.gov/glossary/term/firmware (accessed 2026-11-05)
- NIST CSRC glossary, software: https://csrc.nist.gov/glossary/term/software (accessed 2026-11-05)
- NIST CSRC glossary, hardware: https://csrc.nist.gov/glossary/term/hardware (accessed 2026-11-05)
- NIST, NISTIR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020): https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259A.pdf (accessed 2026-11-05)
- Espressif, ESP-IDF application startup flow, ESP32-S3: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-guides/startup.html (accessed 2026-11-05)
- Espressif, ESP-IDF FreeRTOS overview, ESP32-S3: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/system/freertos.html (accessed 2026-11-05)
- Espressif, ESP-IDF over-the-air updates, ESP32-S3: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/system/ota.html (accessed 2026-11-05)
- Raspberry Pi documentation, Raspberry Pi hardware: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html (accessed 2026-11-05)
- eCFR, 47 CFR 2.1043, Changes in certificated equipment: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-J/section-2.1043 (accessed 2026-11-05)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →