Choosing a controller for an IoT product is really a trade-off between radio, power, security, and how much firmware work you want to own. In 2026, the best microcontroller for one build can be the wrong choice for another, especially once you factor in Wi-Fi, BLE, Thread, certification, and battery life. I am going to narrow the field to the parts that actually matter, explain what each one is good at, and show where I would use them in a real embedded design.
The practical shortlist for connected embedded projects
- ESP32-S3 is my default starting point for Wi-Fi-first IoT because it combines wireless, enough processing headroom, and a very deep ecosystem.
- Nordic's nRF54L line is the better fit when battery life, Bluetooth LE, Thread, or Zigbee matter more than raw convenience.
- STM32WB and STM32U5 make sense when security, industrial discipline, or low-power design need to come first.
- RP2350 is a strong choice for control-heavy embedded systems, but it is usually a better base for a design with a separate radio module.
- For the UK market, a pre-certified wireless module is often worth the extra cost because it can reduce RF and compliance friction later.
What people really want from an IoT controller
When people ask for the right IoT controller, they are usually not looking for a textbook definition. They want a shortlist, a sane default, and a way to avoid buying the wrong board. That is why the dominant intent here is comparative with a buying edge: the real question is which chip fits the radio, power budget, and firmware stack you can actually support.
I start with five questions. Does the device need Wi-Fi, or only short-range wireless? Is it battery-powered, mains-powered, or both? Does it need secure boot and signed updates? How much RAM and flash does the application really need? And do you want a bare chip, or a module that saves time on antenna and compliance work?
That framing matters because an IoT design fails for boring reasons far more often than for glamorous ones. A part that looks fast on paper can still be the wrong answer if it draws too much current, lacks the right radio, or locks you into a toolchain your team will not enjoy maintaining. Once that baseline is clear, the shortlist becomes much easier.
The chips I would shortlist in 2026
I would not compare the whole market. I would compare the parts that keep showing up in successful connected products, then cut anything that cannot justify its place. For me, these are the candidates that deserve a real design review.
| Option | What it gives you | What it costs you | Best fit |
|---|---|---|---|
| ESP32-S3 | Wi-Fi 4, Bluetooth 5 LE, dual-core CPU up to 240 MHz, broad peripheral set, PSRAM support | Higher peak power, less friendly for ultra-long battery life, RF layout still matters | Smart-home hubs, connected displays, OTA-heavy nodes, rapid product development |
| nRF54L15 | 128 MHz Cortex-M33, ultra-low-power multiprotocol radio, Bluetooth LE, Thread, Zigbee, Matter support | No Wi-Fi, newer platform, fewer hobbyist examples than ESP32 | Battery sensors, locks, mesh devices, modern low-power wireless products |
| STM32WB | Dual-core wireless design with Bluetooth LE, Zigbee, Thread, and Matter support | More stack management, no Wi-Fi, not as simple as a single-purpose MCU | Appliance control, home automation, certified wireless products |
| STM32U5 | Cortex-M33, TrustZone, strong low-power profile, security-focused architecture | No integrated radio, so connectivity usually comes from a separate module | Secure industrial nodes, data loggers, regulated or security-sensitive builds |
| RP2350 | Dual Cortex-M33 or dual Hazard3 cores at 150 MHz, 520 KB SRAM, TrustZone, SHA-256, TRNG | No built-in radio, so connectivity must be added separately | Deterministic control systems, custom embedded hardware, compute-led designs |
If I had to give one general answer, I would still start with ESP32-S3 for most connected prototypes and a fair number of production products. It is not the lowest-power option, but it is the fastest route from idea to a working system. Once the design becomes battery-led or mesh-led, Nordic or STM32 starts to look more attractive.
The newer Nordic parts deserve special attention if your device lives on a battery. They are not just faster; they are designed to do more work per milliwatt, which is the metric that actually matters in the field. If you have been using older BLE hardware, the jump in efficiency is noticeable.How I choose between Wi-Fi, BLE, Thread, and no radio
Wi-Fi and cloud connectivity
If the device needs a browser-based setup screen, cloud OTA, or direct MQTT over Wi-Fi, I start with ESP32-S3. Wi-Fi buys convenience, but it also brings peak current spikes, so I treat power design as seriously as firmware. A battery node that sleeps deeply and wakes briefly can work; a device that stays chatty usually cannot unless the battery is large.
For anything that must feel instantly connected to the internet, Wi-Fi remains the easiest user experience. That is especially true in consumer IoT, where provisioning has to be simple enough for a non-technical person to finish without thinking about the stack underneath.
BLE, Thread, Zigbee, and Matter
If the device talks to a phone, a hub, or a smart-home fabric, I care more about radio efficiency and certification than top-end CPU. This is where Nordic's newer nRF54L parts are the strongest modern choice, and STM32WB stays relevant when you want a dual-core wireless design with a mature industrial ecosystem. This is also the zone where protocol choice matters most: BLE is simple, Thread and Zigbee help with mesh, and Matter adds interoperability on top.
If the product has to run for months or years on a small battery, the networking model matters more than the MCU clock rate. A well-chosen low-power wireless part can make the difference between a device that ships and one that constantly needs larger batteries, more enclosure space, or more field maintenance.
Read Also: Smart Thermostat - The Perfect IoT Example Explained
No radio on the chip
If the design already has Ethernet, cellular, or a separate wireless module, a non-radio MCU can be the cleaner answer. RP2350 and STM32U5 both make sense here because they let the application processor focus on control, local UI, signal handling, and security. That split often simplifies validation and makes the architecture easier to reason about.
I also like this approach when the communications strategy may change later. If a team is not sure whether the final product will use Wi-Fi, LTE, or something else, keeping the compute core separate from the radio can reduce the cost of a future redesign.
The trade-offs that usually decide the real winner
Chip datasheets are useful, but they do not tell the full story. The real decision usually comes down to five things that are easy to underweight at the start and painful to fix later.
- Power budget matters more than headline speed. Check average current and peak transmit current, not just sleep mode numbers.
- Security is no longer optional for connected devices. Secure boot, signed OTA updates, and hardware crypto should be on the checklist from day one.
- Toolchain maturity can save or sink a project. ESP-IDF, Zephyr, STM32Cube, and similar stacks each have a different learning curve.
- Peripheral fit is often the hidden constraint. USB, ADC accuracy, PWM, UART count, I2C/SPI bandwidth, and CAN can matter more than MHz.
- Certification and packaging decide how hard production will be. In the UK, a pre-certified wireless module can save serious time because radio and compliance work is easier when the RF side is already approved at module level.
This is also where the board-versus-module decision shows up. A development board is great for testing, but a production module can reduce antenna risk, speed up layout, and make the path to compliance less painful. That is why the same chip can look cheap in a lab and expensive in a product.
Where each option fits in actual IoT products
When I map these parts to real products, the answer gets much less abstract. The right controller depends on the shape of the device, not just its feature list.
| Product type | What I would pick | Why |
|---|---|---|
| Smart-home hub or connected display | ESP32-S3 | Wi-Fi, BLE, and enough headroom for UI, OTA, and local processing |
| Battery-powered sensor or tracker | nRF54L15 | Low-power wireless is the priority, and the radio stack is built for it |
| Mesh accessory, lock, or lighting node | nRF54L15 or STM32WB | Thread, Zigbee, BLE, and Matter are the right tools for this class of device |
| Secure industrial logger | STM32U5 | Security and power discipline matter more than having wireless on the die |
| Control-heavy embedded system with separate comms | RP2350 | Strong deterministic control, good memory, and a clean base for external connectivity |
For a one-off prototype, I sometimes pick a cheaper board such as an ESP32-C3 or a Raspberry Pi Pico 2 just to validate the system quickly, then move to the production part later. That is fine if it is a deliberate stepping stone. It is a mistake only when the prototype part is allowed to become the product by accident.
In practical terms, this is where I make the final cut: Wi-Fi means ESP32-S3; battery-first mesh means Nordic; security-heavy industrial work points me toward STM32; and control-first designs often fit RP2350 better than a wireless chip that is pretending to be a general-purpose computer.
The choice I would make first on a new IoT build
If the product must speak Wi-Fi and you want to move quickly, I would ship with ESP32-S3 first. If battery life is the main KPI and Wi-Fi is not required, I would move straight to Nordic's nRF54L line. If the project is security-heavy or industrial, STM32U5 or STM32WB is usually the better engineering decision. And if the whole point is deterministic control with connectivity handled elsewhere, RP2350 stays on my shortlist.
That is the shape of the answer I would give any team building connected hardware in the UK right now. There is no single best microcontroller for every IoT build; the right answer is the one that matches your radio, power budget, security plan, and compliance path before it matches your benchmark.
