An IoT operating system is software that manages connected hardware, and the phrase has two quite different meanings. The classic meaning is the small operating system that runs inside a single device, such as a sensor, a smart lock or a gateway. Zephyr, FreeRTOS and RIOT are typical examples. The newer meaning is the operating layer for a whole estate of devices: the software that lets thousands of sensors, meters, machines and robots from different manufacturers share what they know and act together.

Both meanings are legitimate, and they answer different questions. If you're designing a circuit board, you need the first. If you're responsible for a building, a factory or a fleet of sites, you need the second. This guide covers both, starting with the device.

In short

  • A device IoT operating system runs on a microcontroller or embedded processor and manages tasks, memory, radio and power for that one device.
  • The most widely used options are real-time operating systems such as Zephyr and FreeRTOS for small devices, and embedded Linux for gateways and cameras.
  • An estate-level IoT operating system connects devices across protocols and vendors into one shared context that rules, people and AI can act on.
  • An AI IoT platform adds AI that can read that context and, within set permissions, act on real equipment, which makes testing before go-live essential.

Do IoT devices need an operating system?

Not always. The smallest devices often run "bare metal": a single program with a main loop that reads a sensor, sends a packet and goes back to sleep. It's simple and uses almost no memory. Once a device has to juggle several jobs at the same time, such as running a radio stack, encrypting messages, reading three sensors and accepting firmware updates, a small operating system starts paying for itself.

The internet standards body IETF describes constrained devices in classes (RFC 7228). Class 0 devices have far less than 10 KiB of RAM and usually can't run a general operating system at all. Class 1 devices have around 10 KiB of RAM and 100 KiB of flash, enough for a compact real-time operating system. Class 2 devices have around 50 KiB of RAM and 250 KiB of flash, and can run a full IP stack. Above that sit processors with a memory management unit and megabytes of RAM, which can run Linux.

The key difference between the two device-side families is timing. A real-time operating system (RTOS) guarantees that a task runs within a known time, which matters for motor control or radio timing. A general-purpose system such as Linux offers far more features, networking and tools, at the cost of more memory, more power and less predictable timing.

What are the best operating systems for IoT?

There's no single best one. The right choice depends on the chip, the power budget and the team. These are the options most device makers consider today:

Operating system Type Typical hardware License Maintained by
Zephyr RTOS Microcontrollers (Arm Cortex-M, RISC-V and others) Apache 2.0 Linux Foundation project
FreeRTOS RTOS kernel Almost any microcontroller MIT Amazon Web Services
RIOT RTOS Low-power microcontrollers LGPL 2.1 Open-source community
Contiki-NG Event-driven OS Low-power wireless nodes BSD 3-Clause Open-source community
Eclipse ThreadX RTOS Microcontrollers, certified safety use MIT Eclipse Foundation
Embedded Linux (Yocto, Buildroot, Ubuntu Core) General-purpose Gateways, cameras, edge computers GPL kernel, mixed userland Linux Foundation and vendors

A few practical patterns help narrow it down. FreeRTOS is the smallest step up from bare metal: a scheduler and a handful of primitives, with networking added as separate libraries. Zephyr is a fuller system with drivers, Bluetooth, networking and a device tree configuration model, and it has become a popular choice for new designs. RIOT and Contiki-NG grew out of research on low-power wireless networks and are strong on IPv6 over constrained radios. ThreadX is often chosen where safety certification of the kernel matters. Linux takes over when a device needs a camera pipeline, containers or a full web stack, which is why most gateways run it.

In practice, most projects settle on the operating system the chip vendor's software kit supports best, and then on whether the team can keep it updated securely for the ten years a device may stay in the field. That second point is becoming a legal matter too. The EU's Cyber Resilience Act, in force since December 2024 with its main obligations applying from December 2027, requires makers of connected products sold in the EU to handle vulnerabilities and ship security updates over a defined support period. An operating system with an active security team and a clear update path makes that far easier to meet.

IoT operating system vs IoT platform

Once you have hundreds or thousands of devices, a different problem appears. Each device runs its own small operating system perfectly well, yet the estate as a whole has no shared picture. Door sensors report to one app, meters to another, the chiller to the building management system, and the robot to its own fleet software. Nothing connects what one device sees with what another can do.

The older answer was an IoT platform: a cloud service that collects readings, draws charts and sends alerts. That's useful, and it's mostly one-directional. The newer idea is an operating layer for the estate. Just as a device OS lets programs share one chip's memory and radio, an estate-level operating system lets devices, machines and AI from different manufacturers exchange what they observe, coordinate tasks and act within defined permissions.

Picture a logistics yard. A patrol robot sees and hears only its own surroundings. A battery-powered LoRaWAN contact sensor on a gate at the far end of the yard reports that the gate opened long after the yard closed, when nobody should be there. On its own, the robot never finds out. Connected through a shared operating layer, the gate's event becomes a task for the robot to go and check, an alarm for the night guard, and a record of what happened. That's what physical AI means in practice: connecting all physical things so they share context and can act as a group, with robots as one participant among sensors, doors, cameras, meters and machines.

We build Kilo as that estate-level layer. LoRaWAN, mioty and MQTT devices and vehicle trackers connect to it directly, and Modbus, BACnet or OPC UA equipment arrives through edge gateways, so hardware from different manufacturers reports into one place. You draw rules that decide what happens next and send commands to the equipment that accepts them, and because those commands move real things, you step through each rule in a debugger with the commands mocked before it goes live. If it's the estate meaning your project needs, you can connect a first batch of devices to Kilo's operating system for IoT and physical AI and grow the estate from there.

What is an AI IoT platform?

An AI IoT platform, sometimes shortened to AIoT platform, combines a connected device estate with AI that can work on it. The term covers a wide range. At one end, AI runs on the device itself, for example a camera that classifies images locally. At the other end, AI works across the whole estate: answering questions about live readings, finding devices that have stopped reporting, building automation from a described goal, or sending commands to equipment.

A concrete example of the estate-wide kind: someone asks "which freezers were above 5 °C for more than an hour last week?" and gets a list and a chart, without exporting data into a spreadsheet or writing a query.

That second kind changes what the platform has to guarantee. When an AI only summarizes data, a wrong answer is an inconvenience. When an AI can switch a relay, close a valve or send a robot somewhere, the platform needs clear permissions for what it may touch, explicit confirmation before it acts, a record of every command and its outcome, and a way to test scenarios before they run against real equipment.

What is the best AI IoT platform?

It depends on what you need the AI to do. Lists of AI IoT companies mix chip makers, camera vendors, cloud providers and software platforms, which makes direct comparison difficult. A more useful approach is to compare on the questions that decide day-to-day operation:

Question Why it matters
Which devices and protocols can it receive data from without custom code? Decides how much of your estate it can see
Can the AI only read data, or also act on equipment? Acting needs a much higher standard of control
How does the price change as devices and users grow? A cheap pilot can become an expensive estate
How are AI actions limited, confirmed and recorded? You need to know who did what and why
Can you export your data and device setup if you leave? Decides how hard a later move would be
Where can it run (cloud, on-premise, at the edge)? Affects latency, data control and offline operation
How large is the user and integrator community? Decides how easily you find help and people

Weight the answers by your situation. A single-site team with a few dozen sensors cares most about how quickly it can start. A company with many sites and mixed equipment cares most about protocol coverage, permissions and how long the vendor will support it. A team that plans to let AI send commands to equipment should put the questions about acting and about limits first.

IoT operating system FAQ

Is Linux an IoT operating system?

Yes, embedded Linux is widely used on the larger IoT devices, such as gateways, cameras and industrial edge computers. It usually runs on a processor with a memory management unit and typically tens of megabytes of RAM. Since kernel 6.12, released in November 2024, the real-time PREEMPT_RT patches are part of mainline Linux, which makes it more suitable for time-sensitive tasks.

Is Android an IoT operating system?

Google built a dedicated version, Android Things, for IoT devices, but it shut the service down in January 2022. Standard Android is still used on kiosks, smart displays and handheld terminals, where a touchscreen and app ecosystem matter more than low power.

Do AI IoT platforms lock you in?

They can. Cloud IoT services do get discontinued: Google retired its Cloud IoT Core service in August 2023, and its users had to migrate their devices elsewhere. Platforms that accept open protocols such as LoRaWAN and MQTT, and that let you hold your own device keys, make a future move far less painful.

What is the difference between an IoT OS and firmware?

Firmware is the complete software image on a device. The operating system, if there is one, is the part of that firmware that schedules tasks and manages hardware, while the application code on top does the device's actual job.

Five battery-powered sensors in one building, for example a door contact, two temperature sensors and two leak sensors, show the estate meaning at small scale: put them on one dashboard and add a rule that alerts you when a leak sensor trips. That setup runs on Kilo's free plan as it stands. Kilo Electronics stocks LoRaWAN sensor nodes, though hardware from any compatible supplier works the same way.