How to Choose Your IoT Technology: Connectivity, Embedded OS and Platform (2026)

June 4, 2026

Written by Christian Simard · Last updated 2026-06-04 · 11 min read

Short answer: there is no single “best” IoT technology — there are four decisions that have to fit together: connectivity (how devices talk), embedded OS (what runs on them), protocols (how data moves), and platform (where the fleet is managed). Pick each one from your duty cycle, payload, power budget and compliance needs — not from the latest hype. This guide gives you the 2026 trade-offs for each.

Key takeaways

  • Choose connectivity from range, power and payload: LoRaWAN for low-data wide-area, LTE-M for mobile/updatable, cellular for high-throughput, Wi-SUN/Wirepas/DigiMesh for dense meshes.
  • Choose the OS from maintainability: Yocto for shipping Linux products, Buildroot for simple images, Ubuntu Core for transactional updates, an RTOS for MCU-class devices.
  • OPC-UA and MQTT are not rivals — model data with OPC-UA, transport it with MQTT.
  • The platform is the decision people underestimate: building identity, OTA, RBAC and audit on a hyperscaler is 12–24 months of work before your first feature.
  • Security and data residency should be a platform property, not per-project glue.

The four decisions, in order

Most IoT projects get stuck because they pick a radio or a cloud first and discover the constraints later. Work in this order instead: connectivity → embedded OS → protocols → platform. Each choice narrows the next. A battery sensor reporting once an hour rules out heavy radios and full Linux; a video gateway rules out LoRaWAN. Decide the physics first, the software second.

1. Connectivity: match the radio to the job

Connectivity is a power-and-payload trade-off before it is a coverage one. Use this as a starting matrix, then validate with a real RF site survey.

Technology Best for Range Power Payload
LoRaWAN Metering, parking, agriculture, wide-area sensing Km-scale Very low (years on battery) Small
LTE-M Mobile or firmware-updatable assets, carrier coverage Carrier Low–moderate Moderate
Cellular (LTE Cat-1/4, 5G) Gateways, video, high-throughput nodes Carrier Higher Large
Wi-SUN / Wirepas / DigiMesh Dense utility, lighting and campus meshes Mesh-extended Low–moderate Small–moderate
Wi-Fi / BLE In-building, commissioning, consumer proximity Local Moderate Moderate–large

For most real deployments the answer is a mix — for example LoRaWAN sensors plus a cellular gateway — unified behind one platform so you don’t manage three fleets.

2. Embedded OS: optimize for the next five years, not the demo

The OS choice is really a maintainability choice. The wrong answer is cheap today and expensive at every security patch for the life of the product.

  • Buildroot — fast, simple images on stable hardware; great for tightly-scoped devices.
  • Yocto — the industry default for shipping Linux products: custom BSP, licensing traceability, long-term maintainability across product variants.
  • Ubuntu Core — transactional, snap-based updates with commercial support; strong when you want managed updates out of the box.
  • RTOS (FreeRTOS, Zephyr) — the right layer for MCU-class devices where Linux doesn’t belong.

3. Protocols: OPC-UA and MQTT do different jobs

This is the most common false choice in industrial IoT. OPC-UA is an information-model standard for interoperability between machines, PLCs and historians. MQTT is a lightweight transport for moving telemetry to the cloud. The mature pattern is OPC-UA on the floor, bridged to MQTT (often Sparkplug B) at an edge gateway. Pick the pair, not one or the other.

4. Platform: the decision people underestimate

Once devices talk and run, something has to provision them, push firmware, enforce who-can-do-what, and prove it all to an auditor. You can build that on AWS or Azure — but you then own device identity, governed OTA, role-based access, multi-tenancy, audit and data residency for the life of the product. That is typically 12–24 months of platform engineering before your first differentiating feature ships.

The alternative is to buy the control plane and build your product on top of it. That is exactly the build-vs-buy line where most teams should buy.

Where Fundamentum fits

Once you have picked a radio and an OS, you still need a place to provision devices, push firmware, govern access and prove compliance. That is where Fundamentum, our Canadian IoT platform (PaaS), comes in: device identity, governed OTA, role-based policies and a SOC 2 Type II audit trail — out of the box, so you don’t rebuild that plumbing per project. Fundamentum can interface with AWS, Azure or Google Cloud if your architecture already requires it, but it gives you a sovereign, residency-aware control plane by default. Explore the platform →

SOC 2 Type II. Fundamentum operates within Groupe Vectanor’s SOC 2 Type II perimeter — independently audited by RCGT, report dated April 15, 2026. Your device data is governed, encrypted and traceable end to end.

Frequently asked questions

Cellular, LoRaWAN or LTE-M — which should I pick?

Match the radio to your duty cycle and payload. LoRaWAN fits low-data, battery-first, wide-area sensing (metering, parking, agriculture). LTE-M fits mobile or firmware-updatable assets needing carrier coverage and moderate bandwidth. Full cellular (LTE Cat-1/4, 5G) fits gateways, video or high-throughput nodes. For dense campus or utility meshes, also weigh Wi-SUN, Wirepas or DigiMesh.

Should I move my consumer roadmap to Matter in 2026?

If you build smart-home or building products that benefit from working with Apple Home, Google Home and Amazon Alexa, Matter over Thread is now a credible default — it removes per-ecosystem integrations. If your product is industrial, regulated or wide-area, Matter is usually not the right layer. Decide per product line, not company-wide.

Yocto, Buildroot or Ubuntu Core for my edge device?

Use Buildroot for simple, fast-to-build images on stable hardware. Use Yocto when you need long-term maintainability, licensing traceability and a custom BSP across product variants — it is the industry default for shipping Linux products. Use Ubuntu Core when you want transactional updates and snap-based app delivery with vendor support. For MCU-class devices, the real choice is an RTOS (FreeRTOS, Zephyr), not Linux.

OPC-UA or MQTT for my industrial connectivity?

They solve different problems and often coexist. OPC-UA is an information-model standard for interoperability between machines, PLCs and historians on the OT floor. MQTT is a lightweight transport for moving telemetry north to the cloud. A common pattern is OPC-UA on the line, bridged to MQTT (often via Sparkplug B) for cloud ingestion.

Should I build my IoT platform on AWS/Azure or buy one?

Building on a hyperscaler gives maximum control but means you own identity, OTA, RBAC, multi-tenancy, audit and residency forever — typically 12–24 months of platform engineering before your first feature. A managed platform like Fundamentum gives you that control plane on day one and still interfaces with public clouds if needed. Buy the plumbing, build your differentiator.

How do I keep all of these choices secure and auditable?

Centralize device identity and certificates, sign every firmware image, gate OTA rollouts behind role-based policies, and keep an immutable audit trail. Fundamentum does this within Groupe Vectanor’s SOC 2 Type II perimeter (audited by RCGT, report dated April 15, 2026), so security is a platform property rather than per-project glue code.

CS
Written by Christian Simard — VP Technology & Innovation, Amotus.

Talk to an IoT engineer — free

Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.

Book my free 30-min consultation


On the Same Topic