Concept renderAn IoT architecture for a connected product has six layers: the device, the link (BLE through a phone, Wi-Fi or cellular), cloud ingest, storage and processing, the app, and the update service. For each layer, decide where data and keys live, who controls the cloud account, and how signed firmware updates reach the device.
Most IoT architecture guides draw the same stack: sensors, a network, a cloud, an app. That picture is too general to build one product from. You need narrower answers. Which link carries the data? Where does each key live? Whose cloud account holds the records? How does a firmware fix reach a unit already in a customer's home? Every standard and vendor figure below links to the page we read, as of November 2026.
What is IoT architecture for a connected product?
IoT architecture is the plan for how a device, its link, the cloud and the app divide the work: what runs where, what data moves, and who controls each part. Three paths decide most of the design.
- The data path. How a reading or recording gets from the device to storage.
- The trust path. Which keys prove that a device is genuine, that a message came from it, and that a firmware image came from you.
- The update path. How new firmware reaches the device, and how the device recovers when an update fails.
Public baselines give a checklist for the trust and update paths. NIST IR 8259A, published in May 2020, lists six capabilities a securable IoT device generally needs: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness (NIST IR 8259A, as of November 2026). The European standard ETSI EN 303 645 V3.1.3 (September 2024) sets out provisions for consumer IoT, from unique passwords to secure updates and user data deletion (ETSI EN 303 645, as of November 2026). Neither picks a radio or a cloud for you. They describe what the finished system must be able to do.
What does an IoT architecture diagram look like for one device?
A box-and-arrow diagram hides what causes trouble later: who holds which key and who controls each box. A table shows it. Each row is one layer.
| Layer | What runs there | Data it holds | Keys it holds | Who controls it |
|---|---|---|---|---|
| 1. Device | Sensors, processor, firmware, bootloader. | Raw readings and buffers waiting to upload. | Identity key, network credentials, firmware-signature public key. | The product owner, through firmware and the update service. |
| 2. Link | BLE to a phone, Wi-Fi to a home or office router, or a cellular modem and SIM. | Data in transit only, if the link is encrypted end to end. | Pairing keys (BLE), Wi-Fi password, cellular network keys on the SIM. | Split with the phone owner, router owner or carrier. |
| 3. Cloud ingest | An MQTT broker or HTTPS API that devices connect to. | Messages as they arrive, queues for devices that are offline. | Server certificate, the record of which device identities may connect. | Whoever owns the cloud account that hosts it. |
| 4. Storage and processing | Databases, files, rules, calls to model or speech APIs. | The long-term record: history, audio, location, user profiles. | Database and storage keys, third-party API keys. | Whoever owns the cloud account. |
| 5. App and dashboard | Phone app for users, web dashboard for support. | Cached views and the user session. | User sign-in tokens on the phone. | The product owner, published under its app store accounts. |
| 6. Update service | Build server, signing step, image hosting and rollout control. | Firmware images and the rollout plan. | The private firmware signing key, kept offline. | The product owner. This key can change every device in the field. |
The last column is where data sovereignty is decided. If layers 3 and 4 run in a cloud account your company owns, your company holds the records and the keys. If they run in a supplier's account, the supplier controls them day to day, whatever the contract says about ownership. Moving a fleet of devices from one account to another later usually means new credentials on every unit. Decide the account before the first prototype connects.
How do the IoT layers change with BLE, Wi-Fi or cellular?
This section covers only what the link changes in the architecture: whether the phone app sits in the data path, what the user does at setup, and how updates travel. For choosing the link itself, with power and range trade-offs, see IoT wearables: connectivity, power and security.
| Question | BLE through a phone | Wi-Fi | Cellular |
|---|---|---|---|
| How data reaches the cloud | The device sends to the phone app over BLE. The app forwards to the cloud over the phone connection. | The device connects to the user's router and talks to the cloud directly. | The device connects through a carrier network and talks to the cloud directly. |
| Setup step for the user | Pair the device with the app. | Send the Wi-Fi name and password to the device, usually from the app. | Usually none for the user. A SIM or eSIM profile and a carrier plan must be in place before shipping. |
| Credentials on the device | BLE bonding keys. | The Wi-Fi password plus the device identity for the cloud. | Network keys on the SIM, plus the device identity for the cloud. |
| When the link drops | Offline whenever the phone is away or the app is stopped. It must buffer. | Offline when the router or line is down. It must buffer and reconnect. | Offline in poor coverage. It must buffer and reconnect. |
| Firmware update path | The app carries the image to the device over BLE. | The device downloads the image over Wi-Fi. | The device downloads the image over the cellular link, which costs data on every unit. |
BLE through a phone
The app becomes part of the data path and the update path. It takes on buffering, retries, upload and firmware delivery, so budget app work as part of the device.
Wi-Fi
The trust path starts at setup, when the Wi-Fi password has to reach the device safely. Espressif's unified provisioning framework sends it over BLE or over a SoftAP with an HTTP server. Its Security 1 scheme uses a Curve25519 key exchange with AES-256-CTR, and Security 2 uses SRP6a key derivation with AES-256-GCM (ESP-IDF provisioning, as of November 2026). Smart home devices built on the Matter protocol use BLE for setup, then join over Wi-Fi or Thread. For which Wi-Fi band to support, see 2.4 GHz vs 5 GHz Wi-Fi for IoT.
Cellular
No phone or router sits in the path, but the carrier controls one layer and every message and update costs data. For voice devices, see cellular, Wi-Fi or phone tether.
Where should data and keys live in each layer?
List every key before you write firmware. Each needs a storage place and an owner.
| Key or credential | Where it lives | Who holds it |
|---|---|---|
| Device identity key (one per unit) | On the device, in secure storage such as a Secure Element, a Trusted Execution Environment or encrypted storage tied to the hardware. | The device. The cloud keeps only the public part or the certificate. |
| Firmware signing key | Offline, at the product owner. The device holds only the public key. | The product owner. Losing it means you cannot ship updates. Leaking it means someone else can. |
| Flash encryption key | Inside the chip. On the ESP32, Espressif states the key sits in an eFuse that software cannot read. | The chip itself. Nobody needs a copy. |
| Wi-Fi password | On the device, in secure storage, after provisioning. | The end user. |
| Cellular network keys | On the SIM or eSIM. ETSI EN 303 645 gives LTE-M root keys in a UICC as an example. | The carrier. |
| Cloud database and storage keys | In the cloud account, in its secret store. | The cloud account owner. |
| Model, speech and other API keys | Server side in the cloud account. Keep them off the device and out of the app. | The cloud account owner, under its own vendor contracts. |
Sources for the rows above: provision 5.4-1 and its examples in ETSI EN 303 645, and Espressif's flash encryption page, both as of November 2026. Espressif also states that flash encryption alone may not stop someone from modifying the firmware, and recommends using it together with Secure Boot.
Passwords and data in transit
ETSI EN 303 645 provision 5.1-1 says that where passwords are used, in any state other than the factory default, each device password must be unique per device or set by the user. Provision 5.8-2 requires best practice cryptography for sensitive personal data sent between the device and its associated services, and gives content of communication and timestamped location data as examples (as of November 2026). For a recording wearable or a tracker, treat the whole upload path as sensitive.
Deletion and outages
Clause 5.11 covers easy deletion of user data and notes that users also expect backup copies to be deleted. Provision 5.9-2 says a device should keep working locally without network access and recover cleanly after power loss. The first needs a deletion path through every layer that stores data. The second needs a local buffer and defined offline behavior.
How does a firmware update travel back to the device?
The update path runs the stack in reverse: build server, signing, cloud, link, device, bootloader. ETSI EN 303 645 provision 5.3-2 says a consumer IoT device shall have a secure update mechanism unless a use-case resource constraint prevents it, and provision 5.7-1 says the device should verify its software using secure boot (as of November 2026).
The Espressif ESP-IDF documentation shows what the device side looks like on one common chip family, as of November 2026 (ESP-IDF OTA):
- Two slots. Safe updates need at least two OTA app partitions plus an OTA data partition, which is two flash sectors (0x2000 bytes). The new image is written to the slot that is not running.
- Self-test before commit. With app rollback enabled, a new image boots in a pending-verify state. The app runs its own checks and marks itself valid. If the device resets before that, the bootloader returns to the previous image. Rollback is off by default, so someone has to turn it on.
- Anti-rollback. A security version stored in eFuse stops the device from booting firmware with a lower version. On the ESP32 the field allows 32 increments (16 on the ESP32-S3, per its OTA page), so plan which releases raise it.
The cloud side matters as much. Under provision 5.9-3, ETSI EN 303 645 gives examples of notifying devices in batches so they do not all download an update at once, and of reconnecting after a randomized delay (as of November 2026). A staged rollout with a stop rule is the cloud half of a safe update. For failure modes on the device side, see OTA update failures that brick devices.
What should you ask your hardware team?
Take this list to an architecture review, with your own team or with any outside firm.
- Whose cloud account does the device connect to in the prototype, and whose account does it connect to at launch?
- Which keys exist, where is each one stored, and who has a copy of the firmware signing key today?
- Are there any default passwords, and is each one unique per device as ETSI EN 303 645 provision 5.1-1 describes?
- What does the device do when the link is down for a day, and how much does it buffer?
- How does a firmware image travel from the build server to the device, and what checks its signature?
- How are updates rolled out: to every device at once, or in batches with a stop rule?
- How does a user delete their data, and does deletion reach backups?
- Will we receive the firmware source, the build scripts and the SBOM so another team could rebuild the image?
Duobay's engineering page describes how device, app and cloud work is split. By default we deliver the device plus an SDK tested against your backend. The app and backend are an option, deployed in your own cloud account, with you holding the keys.
Questions about IoT architecture
Do I need MQTT?
No. It is one common way to publish device messages to a broker. The OASIS MQTT 5.0 standard (March 7, 2019) defines three delivery levels and a Will message the server publishes after a connection closes without a normal disconnect (OASIS MQTT 5.0, as of November 2026). HTTPS calls also work. For how MQTT, HTTP and CoAP compare on a battery device, see MQTT vs HTTP vs CoAP for battery devices.
Which security baseline should the architecture follow?
Two public documents make a good checklist: the six device capabilities in NIST IR 8259A (May 2020) and the provisions in ETSI EN 303 645 V3.1.3 (September 2024), as of November 2026. Whether either one is required for your product in your market is a legal question. This is not legal advice.
Can I keep the cloud in my own account if an outside team builds the device?
Yes, if you set it up that way from the start. Create the account under your company, give the outside team scoped access, and keep the signing key and production credentials yourself. Ask for the firmware source and SBOM at each handover.
How could Duobay help with my device architecture?
Duobay builds the device and an SDK tested against your backend. As an option, we build the app and backend and deploy them in your own cloud account, so you hold the keys. We do not publish prices. Tell us about your device and we will walk through the architecture with you.
If you want to map the layers, keys and update path for your product, tell us about your device.
Sources
All pages accessed November 5, 2026. Re-read them before you rely on any provision or figure.
- ETSI EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements: https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf (accessed 2026-11-05)
- NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020): https://csrc.nist.gov/pubs/ir/8259/a/final (accessed 2026-11-05)
- Espressif, ESP-IDF Over The Air Updates (OTA): https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/ota.html (accessed 2026-11-05)
- Espressif, ESP-IDF Over The Air Updates (OTA), ESP32-S3: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/system/ota.html (accessed 2026-11-05)
- Espressif, ESP-IDF Unified Provisioning: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/provisioning/provisioning.html (accessed 2026-11-05)
- Espressif, ESP-IDF Flash Encryption: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/flash-encryption.html (accessed 2026-11-05)
- OASIS, MQTT Version 5.0 (OASIS Standard, March 7, 2019): https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html (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 →