What Are IoT Devices? Architecture, Types & Examples (2026)

Last updated: May 2026

The term “IoT device” gets thrown around so loosely that it covers everything from a $3 temperature chip soldered to a PCB to a refrigerator-sized industrial edge server managing an entire factory floor. That range is not sloppy language — it reflects a genuine spectrum of what are IoT devices at a hardware and software level. Understanding where on that spectrum a device sits determines every decision that follows: which radio to choose, whether TLS is even possible, how you push firmware updates, and how you defend against the kind of default-credential botnet that took down large swaths of the internet in 2016.

This post gives you a complete picture. We will cover the anatomy of a single IoT device (every hardware and firmware block), the three-class taxonomy from RFC 7228, the connectivity options and when each fits, the full device lifecycle from factory to decommission, and the security attack surface with practical defenses. Real-world examples anchor each concept to something you can point at.

What this post covers: device definition and anatomy, RFC 7228 device classes, connectivity trade-offs, the device lifecycle, security layers, industry examples, gotchas, and an FAQ.

What exactly is an IoT device?

An IoT device is a physical object embedded with a processor, sensors or actuators, and a communications interface that allows it to exchange data with other systems — typically a cloud platform, an edge gateway, or peer devices — without requiring continuous human interaction. The “things” in the Internet of Things are these devices.

That definition matters because it draws a clear line. A laptop running software is not an IoT device — a human operates it interactively. A Raspberry Pi sitting in a server rack running a database is not an IoT device. But a Raspberry Pi strapped to a pump, reading vibration data every 100 ms and pushing it to MQTT, absolutely is. The defining characteristic is the purpose-built sensing or actuation role combined with autonomous, always-on connectivity.

IoT devices today appear in every industry. There are roughly 18 billion connected IoT devices active globally as of 2025, according to analyst tracking, with that figure expected to surpass 25 billion by 2030. However, the more operationally useful lens is not volume but capability class — because a Class 0 sensor node and a Class 2 industrial gateway require completely different engineering decisions even though both are “IoT devices.”

For a broader grounding in what IoT means as a discipline, see our complete technical guide to the Internet of Things.

The anatomy of an IoT device

Every IoT device — regardless of whether it costs $2 or $2,000 — is built from the same fundamental blocks. Understanding these blocks at a component level is what separates engineers who can diagnose field failures from those who just integrate vendor SDKs and hope.

Figure 1: The six functional blocks inside every IoT device. The secure element and power management IC are the two blocks most often omitted in hobbyist designs — and most regretted in production.

Sensors and actuators

Sensors convert physical phenomena into electrical signals — temperature, pressure, humidity, acceleration, light intensity, gas concentration, proximity, sound. Actuators do the reverse: they convert electrical commands into physical action — turning a motor, opening a valve, triggering a relay, driving a display.

The sensor chain matters at a hardware level. A raw analog sensor output goes through signal conditioning (amplification, filtering) before reaching an ADC, then into the MCU. Many modern sensors are fully digital — they integrate the ADC on-chip and communicate via I2C, SPI, or 1-Wire. Choosing sensors with integrated signal conditioning reduces board complexity and improves noise immunity, which is why MEMS sensors from manufacturers like STMicroelectronics and Bosch dominate IoT designs.

MCU / SoC — the processing core

The microcontroller unit (MCU) or system-on-chip (SoC) is the brain. It runs the firmware, handles sensor reads, manages the radio, enforces power states, and implements the protocol stack. Common MCU families in IoT include the ARM Cortex-M series (M0+ for ultralow-power Class 0/1, M4/M33 for Class 2), RISC-V cores in newer designs, and application processors (Cortex-A series) in gateways that need Linux.

Key specifications to evaluate: clock speed (determines processing headroom), flash size (firmware + OTA staging), RAM (stack depth, TLS buffers — TLS 1.3 needs at minimum 20–40 KB for handshake buffers), and whether the chip integrates a hardware crypto accelerator (critical for AES and SHA without burning battery on software crypto).

Secure element

A secure element (SE) is a tamper-resistant microprocessor dedicated to storing cryptographic keys and performing sensitive operations — device attestation, certificate storage, signing. It is physically separate from the main MCU (or increasingly integrated as a dedicated hardware block, as in ARM TrustZone). Without a secure element, private keys sit in standard flash memory, readable by anyone who can attach a JTAG probe or exploit a buffer overflow. NIST’s IoT Cybersecurity guidance (NISTIR 8259) explicitly calls device identity and key protection foundational requirements.

Power subsystem

Power determines everything about deployment feasibility. The options are mains power (always available, no constraints), Power over Ethernet (PoE, convenient for networked devices, up to 90W with PoE++), batteries (primary or rechargeable), energy harvesting (solar, vibration, thermal gradients), and combinations (battery-backed solar). Power budget math is not optional for battery-powered designs. A device drawing 10 mA continuously from a 3,000 mAh AA cell lasts roughly 300 hours — about 12 days. The same device, spending 99.9% of its time in a 2 µA deep-sleep state with 20 ms awake every 60 seconds, can last years from the same cell. This is why sleep modes and duty cycling are first-class design concerns, not afterthoughts.

Radio module

The radio is the connectivity interface — BLE, Zigbee, Wi-Fi, cellular, LoRa, or Thread. Many modern SoCs integrate the radio on-chip (ESP32, nRF52, STM32WL). The radio selection is a system-level decision, not a component-level one: range, data rate, power consumption, spectrum licensing, existing infrastructure, and security requirements all feed in. We cover this in detail in the connectivity section below.

Firmware and protocol stack

Firmware is the software running on the MCU. For constrained devices, this is typically a bare-metal loop or a real-time operating system (RTOS) like FreeRTOS, Zephyr, or ThreadX (now Eclipse ThreadX). The firmware implements:

Peripheral drivers (sensor reads, GPIO)
Power management state machine
Protocol stack (MQTT, CoAP, LwM2M, or a custom binary protocol)
OTA update client
Security primitives (TLS, DTLS, certificate validation)

Firmware quality is the single biggest variable in IoT device reliability. A poorly written RTOS task that blocks indefinitely will kill a device in the field just as surely as a hardware failure.

Device classes: not all IoT devices are equal

The cleanest taxonomy of IoT devices comes from RFC 7228 (IETF), which classifies constrained nodes by RAM and flash. Understanding these classes prevents the most common IoT architecture mistake: assuming you can run full IP stacks and TLS everywhere.

Figure 2: The constrained-device spectrum from RFC 7228, extended to include gateways and edge servers. Each step up the spectrum adds protocol flexibility but costs power and hardware budget.

Class 0 — deeply constrained nodes

Class 0 devices have less than 10 KB of RAM and less than 100 KB of code flash. They cannot run a full IP stack. They typically communicate over 802.15.4 (Zigbee, Thread) or BLE advertisements, relying entirely on a gateway for IP termination. Examples: simple soil moisture sensors, door/window contact sensors, tire pressure monitors.

Class 1 — constrained nodes with IP capability

Class 1 devices have around 10 KB of RAM and 100 KB of code flash. They can run lightweight IP stacks (6LoWPAN over 802.15.4) and lightweight protocols like CoAP and LwM2M. They cannot run full TLS — DTLS with small record sizes is possible but resource-intensive. Examples: smart metering nodes, basic environmental sensors with cellular modems.

Class 2 — resource-rich constrained devices

Class 2 devices have around 50 KB of RAM and 250 KB of flash. They can run HTTP/HTTPS and MQTT over TLS. Most modern Wi-Fi-enabled IoT chips (ESP32, Raspberry Pi Pico W with external flash) fall here. Examples: smart thermostats, connected appliances, industrial vibration sensors.

Gateways

Gateways run a full OS (commonly Linux), have megabytes to gigabytes of RAM, and serve as protocol translators — aggregating data from Class 0/1/2 devices below them and forwarding to cloud services above. They can run complex local logic, store data when connectivity is lost, and enforce local security policies. Examples: industrial edge gateways, smart home hubs, cellular routers with embedded compute.

Edge servers

Edge servers are compute-dense systems deployed close to the physical environment — in factory substations, at telecom base stations, or in server rooms within a campus. They run full containerized workloads, ML inference, and local data lakes. The boundary between an edge server and a traditional server is deliberately fuzzy; what matters is physical proximity to the data source and latency-sensitivity of the workload.

Connectivity options and when to choose each

Connectivity is where IoT architecture decisions get genuinely hard. There is no universally correct answer — only trade-offs between range, power, bandwidth, cost, and infrastructure dependency.

Figure 3: IoT connectivity options across the range-vs-power-vs-bandwidth space. Move right on the range axis and power cost generally rises; the LPWAN protocols are the exception — they achieve wide range at very low power by sacrificing bandwidth.

For a detailed comparison of IoT protocol stacks and how they interoperate, see our IoT protocols comparison guide.

BLE and Zigbee — short-range, ultra-low-power

Bluetooth Low Energy operates in the 2.4 GHz ISM band. BLE 5.x supports ranges up to roughly 100 m line-of-sight, data rates from 125 kbps (LE Coded, long range) to 2 Mbps (LE 2M PHY). Power consumption during connection is a function of connection interval — a device advertising every 1 second draws microamps to low milliamps depending on the radio and the MCU wake overhead. BLE is the right choice for wearables, medical devices, consumer peripherals, and any application where a smartphone acts as the gateway.

Zigbee uses 802.15.4 at 2.4 GHz and forms mesh networks where each node can relay packets for others, making it excellent for dense smart-building deployments where every light switch and sensor acts as a range extender. Throughput is low, latency is variable in large meshes, and the Zigbee Alliance’s merger into the Connectivity Standards Alliance (and the resulting Matter protocol) means new deployments should evaluate Thread over Zigbee for home automation use cases.

Wi-Fi — high bandwidth, infrastructure-dependent

Wi-Fi 6 (802.11ax) gives IoT devices access to high bandwidth and existing enterprise/home network infrastructure. The major cost is power — Wi-Fi requires periodic association with an access point, and radio TX power during active communication is orders of magnitude higher than BLE or Zigbee. Wi-Fi is the correct choice when devices need to transfer large payloads (camera streams, batch sensor files, OTA firmware images) and are mains-powered or have large batteries. It is almost always the wrong choice for battery-powered sensors that report a few bytes every minute.

LoRaWAN — long range, LPWAN, community networks

LoRaWAN (Long Range Wide Area Network) achieves multi-kilometer range at sub-mA active current by using a chirp spread spectrum modulation that spreads the signal energy across a wide bandwidth. The trade-off is extremely low data rate — typically a few hundred bytes per message, with regulatory duty-cycle limits in unlicensed bands restricting how often a device can transmit. LoRaWAN is excellent for agricultural monitoring, smart metering, asset tracking, and environmental sensing in areas without cellular coverage. The Things Network provides community-operated LoRaWAN infrastructure in many regions.

NB-IoT and LTE-M — cellular LPWAN

NB-IoT (Narrowband IoT) and LTE-M are 3GPP standards built on licensed cellular spectrum. They deliver reliable, nationwide coverage (wherever the carrier has deployed them), support deep penetration indoors and in basements, and include SIM-based device authentication — a significant security advantage over unlicensed-band LPWAN. NB-IoT has lower power consumption and supports devices that send small data packets infrequently. LTE-M supports voice, higher bandwidth (up to 1 Mbps), and mobility/handoff between towers, making it suitable for asset trackers in vehicles. Both are the preferred choice for smart metering, utility monitoring, and any regulated industry where carrier SIM-based identity matters.

5G NR — high bandwidth, low latency, enterprise IoT

5G’s role in IoT is primarily for bandwidth-intensive and latency-sensitive applications: HD video surveillance, autonomous vehicle perception, robotic control, and augmented-reality-assisted maintenance. 5G network slicing allows industrial deployments to get guaranteed bandwidth and latency QoS, which is impossible on shared Wi-Fi. The power and cost premium of 5G modules means they are appropriate for rich Class 2+ devices and gateways, not constrained nodes.

For a deep dive into how MQTT runs across these transport layers, see our complete MQTT protocol guide.

The IoT device lifecycle

Devices are not static. They are provisioned, operated, updated, and eventually decommissioned. Treating the lifecycle as an engineering concern — not just an operational one — is what separates maintainable IoT deployments from field maintenance nightmares.

Figure 4: The complete IoT device lifecycle. The OTA update loop runs continuously through the operational phase; decommissioning is the phase most often skipped, creating orphaned device identities that become security liabilities.

Provisioning and identity

Provisioning is the act of giving a device its unique identity and enrolling it in a management platform. Good provisioning practice injects a unique X.509 certificate (or at minimum an asymmetric key pair) into the secure element at the factory, before the device leaves the manufacturer’s control. This is called zero-touch provisioning when combined with an enrollment protocol that auto-registers the device in a cloud device registry (AWS IoT, Azure IoT Hub, Google Cloud IoT Core) on first connect.

The alternative — shipping devices with a default shared credential and relying on operators to change it in the field — is the exact attack vector that powered the Mirai botnet in 2016, which compromised hundreds of thousands of devices by credential-stuffing default usernames and passwords.

Operations and telemetry

During normal operations, a device collects sensor data, applies local filtering or aggregation, and publishes to a broker or cloud endpoint. The device management plane runs in parallel: the platform monitors heartbeats, tracks device shadow state, handles remote command delivery, and watches for anomalies in telemetry patterns that might indicate hardware degradation or compromise.

OTA firmware updates

Over-the-air (OTA) updates are not optional in production IoT. Vulnerabilities are discovered constantly; if you cannot patch a fleet of 10,000 deployed sensors without physically touching them, you have a permanent security liability. A production-grade OTA pipeline:

Signs the firmware image with an asymmetric key held in a HSM.
Distributes the image via a content delivery network.
Verifies the signature on the device before applying.
Maintains a rollback partition so a bad update can be undone on next boot.
Reports update status back to the management platform.

Standards like SWUpdate, RAUC, and the MCUboot bootloader provide the device-side primitives. Platform-side, AWS IoT Jobs, Azure Device Update, and Eclipse hawkBit handle orchestration.

Decommissioning

Decommissioning is the lifecycle phase most often ignored, with serious consequences. A decommissioned device that still has a valid certificate and is enrolled in the device registry is an open door. Proper decommissioning revokes the device certificate in the CA, removes the device from the registry, performs a cryptographic wipe of keys and flash, and documents the disposal. Hardware destined for recycling should be de-identified — serial numbers and IMEI values removed from management databases before the device leaves the operator’s custody.

IoT device security: layers and attack surface

The attack surface of an IoT device is larger than most engineers initially appreciate. Mirai and its successors demonstrated that shipping products with default credentials at scale is catastrophic. But weak credentials are only one layer of the problem.

Figure 5: Security layers across the device-to-cloud stack and the threat vectors they address. Each layer in isolation is insufficient — the Mirai botnet succeeded because communications credentials were weak even when physical hardware was intact.

NIST’s foundational publication NISTIR 8259A defines the core device cybersecurity capabilities: device identification, device configuration, data protection, logical access to interfaces, software updates, and cybersecurity event awareness. These map directly to the layers below.

Secure boot

Secure boot ensures the device only executes firmware signed by a trusted key. At power-on, the hardware root of trust (burned into OTP fuses or the secure element) verifies the bootloader signature, which then verifies the RTOS image signature before passing control. A device without secure boot can be reflashed with arbitrary firmware via physical access — trivial with a $10 serial adapter and a few minutes.

Device identity and mutual TLS

Every device should have a unique cryptographic identity — an X.509 certificate issued by a known CA, stored in the secure element. When connecting to a broker or cloud endpoint, mutual TLS (mTLS) authentication requires both sides to present certificates. This prevents both eavesdropping and impersonation. DTLS 1.3 provides equivalent protection for UDP-based protocols like CoAP, which is critical for Class 1 devices that cannot run TCP.

Least-privilege resource access

A device that publishes temperature readings should not have permission to subscribe to command topics for other devices, access firmware update streams, or write to log buckets. Topic-level ACLs in MQTT brokers and resource-level policies in cloud IoT platforms enforce this. The principle is the same as for any system: the blast radius of a compromise is bounded by the permissions the compromised identity holds.

Disabling debug interfaces in production

JTAG and UART debug interfaces that are left enabled in production firmware provide an attacker with a direct path to memory dumps, firmware extraction, and cryptographic key recovery. Production builds should lock these interfaces. Many MCU vendors provide hardware lock bits that disable debug access permanently — use them.

The Mirai lesson and what it means today

Mirai infected primarily IP cameras and DVRs by credential-stuffing against Telnet with a list of roughly 60 common default username/password combinations. The infected devices then launched massive DDoS amplification attacks. The lesson is not merely “change default passwords” — it is that at scale, any shared static credential becomes a systemic vulnerability. Per-device unique certificates, mTLS, and the elimination of Telnet/HTTP management interfaces are the structural fixes.

Real-world IoT device examples across industries

Understanding what are IoT devices in the abstract is useful; seeing them concretely in deployment is more so.

Consumer: Smart thermostats (Nest, Ecobee) are Class 2 devices with Wi-Fi and a Cortex-A application processor. Smart speakers integrate multiple microphone arrays, Wi-Fi + BLE, and dedicated DSP silicon. Wearables like fitness trackers sit at Class 1/2 with BLE as the primary radio and a smartphone as the gateway.

Industrial / IIoT: Vibration sensors on rotating machinery are Class 1/2 constrained nodes, often connected via WirelessHART or ISA100.11a (industrial mesh protocols). PLCs with IoT extensions are Class 2 to gateway-class, communicating via OPC-UA over Ethernet. Asset trackers on shipping containers are NB-IoT or LTE-M devices with GNSS receivers, designed for years of operation on a single battery pack.

Healthcare: Continuous glucose monitors (CGMs) are Class 1/2 BLE devices connecting to a smartphone app acting as gateway; the gateway handles the TLS connection to the cloud. ICU monitoring equipment is mains-powered, Wi-Fi connected, and subject to strict IEC 62443 and FDA 21 CFR Part 11 requirements for security and auditability.

Smart city / utilities: Smart electricity meters are Class 1/2 devices, increasingly NB-IoT or LoRaWAN connected, sending interval consumption data to utility head-end systems. Environmental air quality stations are LoRaWAN or cellular, solar-powered, with Class 2 hardware running Python on constrained Linux. Traffic cameras and pedestrian detection systems are gateway-class or edge-server-class, running computer vision inference at the edge.

Trade-offs, gotchas, and what goes wrong

Even well-designed IoT systems fail in predictable ways. These are the failure modes worth internalizing before you ship.

Memory pressure kills TLS. Class 1 devices that technically support DTLS often fail in the field because the TLS handshake requires larger buffers than expected when connecting to servers presenting large certificate chains. The fix: pin to a lightweight certificate, use TLS session resumption to amortize handshake cost, or move TLS termination to a gateway.

OTA updates that brick devices. An OTA update that corrupts the primary firmware partition without a verified rollback path will permanently brick the device. In a field-deployed fleet of thousands, a bad rollout without a staged canary deployment and automatic rollback is a catastrophic event. MCUboot’s A/B partition scheme with a watchdog-guarded boot test mode is the industry standard mitigation.

Power budgets that die in winter. Battery-powered outdoor devices that were characterized at 25°C may fail when lithium cell capacity drops significantly at -20°C. Cold-weather deployments need to be characterized at temperature extremes, and energy harvesting calculations need to account for reduced solar irradiance in winter months at high latitudes.

Device proliferation without lifecycle management. At scale, organizations commonly find that their device registry contains tens of thousands of devices that are no longer in service, still have valid certificates, and have no documented location. This is not a theoretical risk — it is a compliance and audit failure mode that shows up in virtually every mature IoT deployment that did not treat decommissioning as a first-class concern from the start.

Radio coexistence in the 2.4 GHz band. BLE, Wi-Fi, and Zigbee all operate at 2.4 GHz. In dense deployments — smart buildings, hospitals, factories — these radios interfere with each other. Thread and Zigbee use 802.15.4 channel hopping; BLE adaptive frequency hopping handles this automatically. Wi-Fi channel selection and transmit power management require explicit planning in high-density environments.

Default NTP assumptions. Many IoT devices default to public NTP servers (pool.ntp.org) for time synchronization. In networks with strict egress firewall policies — common in industrial and healthcare deployments — NTP traffic is blocked, certificate validation fails because the device clock is wrong, and TLS connections are rejected. Plan time synchronization explicitly.

Practical recommendations

Choosing the right IoT device architecture is not about picking the most capable hardware — it is about matching capability class to the actual requirements, then engineering each layer correctly.

Start with the device class. Classify your application’s RAM, flash, and power budget before selecting a chip. If you genuinely need TLS and MQTT, you need at least Class 2 hardware. Do not fight the constraints with software workarounds on Class 0/1 hardware.

Choose connectivity by deployment context. For dense indoor deployments with existing Wi-Fi infrastructure: Wi-Fi or BLE. For outdoor wide-area deployments with low data rates: LoRaWAN or NB-IoT. For mobile assets or vehicles: LTE-M. For bandwidth-intensive fixed deployments: Wi-Fi 6 or 5G.

Invest in the secure element upfront. Retrofitting hardware-backed key storage after deployment is impossible. If the BOM cost of a secure element is a concern, use an MCU with an integrated TrustZone core — the ARM Cortex-M33 and M55 support TrustZone at no extra chip cost.

Design the OTA pipeline before the first device ships. Once 10,000 devices are in the field without a working OTA path, you are stuck. Build the A/B firmware partition scheme, signature verification, and staged rollout orchestration into the architecture from day one.

Treat decommissioning as a feature. Include certificate revocation and secure wipe sequences in the firmware from the start. Document the decommission procedure in the device management playbook.

Quick checklist:
– Secure element or TrustZone for key storage
– Unique per-device X.509 certificate injected at factory
– Secure boot with signature verification
– JTAG/UART locked in production builds
– OTA with A/B partitions, rollback guard, and staged rollout
– Connectivity choice validated against actual power budget at temperature extremes
– Decommission procedure documented and tested

Frequently asked questions

What is an IoT device in simple terms?

An IoT device is a physical object — a sensor, a machine component, a consumer appliance, or an industrial controller — that has a built-in processor and wireless radio allowing it to send and receive data over a network without human operation. The “IoT” part means the device participates in a larger system where its data is collected, processed, and acted on automatically, typically via a cloud or edge platform.

What are the main types of IoT devices?

IoT devices split into three functional types: sensors (collect physical data — temperature, vibration, location), actuators (perform physical actions — open valves, drive motors, control lighting), and combined sensor-actuator devices. They also split by capability class (RFC 7228 Class 0, 1, and 2 constrained nodes, gateways, and edge servers), and by industry (consumer, industrial, healthcare, smart city). These taxonomies are orthogonal — a healthcare actuator can be a Class 2 device on BLE.

How is an IoT device different from a regular computer?

A regular computer is a general-purpose machine operated interactively by a human. An IoT device is purpose-built for a specific sensing or actuation role, runs continuously without human interaction, is often severely resource-constrained (kilobytes of RAM rather than gigabytes), and is designed to operate unattended for months or years. The networking model is also different — IoT devices typically use lightweight protocols (MQTT, CoAP) over low-power radios, not HTTP over Wi-Fi.

What connectivity protocol should I use for an IoT device?

Match the protocol to the application requirements. BLE or Zigbee for short-range, ultra-low-power, battery-operated sensors in a building. Wi-Fi for high-bandwidth, mains-powered devices with existing network infrastructure. LoRaWAN for long-range, low-data-rate outdoor deployments. NB-IoT or LTE-M for wide-area deployments needing carrier-grade reliability, SIM-based authentication, or mobility. 5G for high-bandwidth or latency-critical industrial applications. There is no universally correct answer — power budget, range, data rate, and cost all trade off against each other.

How are IoT devices secured?

Secure IoT devices use layered defenses: a unique per-device cryptographic identity (X.509 certificate) stored in a tamper-resistant secure element or TrustZone, secure boot to prevent unauthorized firmware, mutual TLS for all network communications, topic-level or resource-level ACLs to enforce least privilege, and a robust OTA update pipeline to patch vulnerabilities without physical access. NISTIR 8259A provides the authoritative baseline for IoT device security capability requirements.

What happens when an IoT device is decommissioned?

Decommissioning should include: revoking the device’s certificate in the issuing CA so it can no longer authenticate to any platform, removing the device from the device registry, performing a cryptographic erase of all keys and sensitive data in flash, physically destroying or sanitizing hardware before disposal or re-use, and documenting the decommission in the asset management system. Skipping decommissioning leaves orphaned device identities in production systems — a security and compliance liability that compounds over time.