How a Real-Time Operating System Actually Runs IoT Devices

A real-time operating system (RTOS) for IoT devices is software built around deadlines instead of fairness. A general-purpose OS like Linux or Windows decides what runs next based on scheduling fairness and overall throughput. An RTOS decides based on a clock: a sensor reading, a motor command, or a safety interlock either finishes inside its time window, often measured in microseconds, or the system counts as having failed. That single design choice is why a smart thermostat can run embedded Linux while a pacemaker, an industrial press controller, or an anti-lock brake module cannot.

RTOS vs. General-Purpose OS: The One Difference That Matters

An RTOS guarantees that a task finishes within a fixed deadline. A general-purpose OS like Linux only guarantees the task will run eventually, favoring average throughput over individual timing.

That gap sounds small. It isn’t.

A desktop scheduler can delay a task by 20 milliseconds and nobody notices a dropped video frame. A motor controller that delays a current-sensing task by 20 milliseconds can let a brushless motor spin past its safe current limit before the firmware reacts.

Hard Deadlines vs. Soft Deadlines

A hard real-time deadline is binary. An anti-lock braking system that responds 50 milliseconds late might as well never have responded, because the wheel has already locked and the control window has closed.

A soft real-time deadline degrades instead of failing outright. Video streaming that buffers for an extra 200 milliseconds is annoying, not dangerous. Most consumer IoT devices, like a smart speaker or a fitness tracker, only need soft real-time guarantees. Most industrial, medical, and automotive IoT devices need hard ones, and that distinction, not the word “IoT” itself, is what decides whether a device needs an RTOS at all.

Why Your Phone’s OS Can’t Do This Job

Android and iOS use preemptive multitasking too, but their schedulers favor keeping the screen responsive to a person, not guaranteeing microsecond-level timing to a hardware interrupt.

If you’ve felt a phone stutter under a heavy load, that’s the scheduler choosing to protect the user interface over a background task. An RTOS managing a motor controller or a flight stabilizer is never allowed to make that trade. It has to service the interrupt that matters, every time, within a bound it can prove in advance.

Inside the Scheduler: How an RTOS Picks What Runs Next

FreeRTOS, Zephyr, and Eclipse ThreadX all use priority-based preemptive scheduling, where a higher-priority task interrupts a lower-priority one the instant it becomes ready, instead of waiting for a time slice to expire.

Priority Levels and Priority Inversion

Each task gets a priority number, either fixed at design time or changed at runtime. The scheduler always runs the highest-priority task that’s ready, full stop. That sounds simple until two tasks need the same shared resource, like a sensor bus.

Take a low-priority logging task that grabs a mutex on the I2C bus right before a high-priority sensor task needs it. The high-priority task now waits on the low-priority one, a problem called priority inversion. Most RTOS kernels solve it with priority inheritance, which temporarily boosts the low-priority task until it releases the lock.

Engineers building battery-powered sensor nodes often run into a related trap: according to FreeRTOS’s own kernel documentation, a task that holds a critical section open too long blocks every other interrupt on the chip, including the one managing radio duty-cycling (FreeRTOS, 2026). That single design mistake is a common cause of “random” packet loss in field deployments that has nothing to do with the radio at all.

Interrupt Latency and Worst-Case Execution Time

What a safety certifier wants is the worst-case execution time (WCET): the longest possible delay between an interrupt firing and the right task running, under the worst plausible combination of competing tasks. Average response time barely enters the conversation.

Vendors publish interrupt latency figures in microseconds for exactly this reason. A kernel that averages 2 microseconds but occasionally spikes to 400 microseconds under load is the one that fails a certification audit, not the one with a slower but tighter average.

Three RTOS Options Actually Shipping in IoT Hardware Right Now

FreeRTOS, the Linux Foundation’s Zephyr Project, and the Eclipse Foundation’s ThreadX are three of the real-time operating systems you’ll most often run into on new embedded and IoT hardware in 2026. Each one got there through a different ownership history.

RTOS	Governing body	License	Named milestone	Hardware reach
FreeRTOS	Amazon Web Services	MIT	LTS kernel v11.1.0, support window through June 30, 2026	Cortex-M/A/R, RISC-V, ESP32, dozens of MCU families
Zephyr	Linux Foundation	Apache 2.0	Version 4.3 released November 2025; 1,000+ supported boards as of March 2026	Arm, RISC-V, Xtensa, x86, single- and multi-core
Eclipse ThreadX	Eclipse Foundation	MIT	Version 6.4.1, 2024; carried 12 billion+ cumulative deployments from its prior name, Azure RTOS	Deeply embedded MCUs; IEC 61508, ISO 26262, IEC 62304 certified builds

FreeRTOS: The Default on Resource-Constrained MCUs

FreeRTOS runs under long-term support as kernel version 11.1.0 through June 30, 2026, after which teams starting new designs are expected to move to the next LTS branch. AWS maintains the kernel under an MIT license, which is part of why it shows up, in some form, inside more low-cost microcontroller projects than any other RTOS on this list.

Zephyr: Built for Portability, Not One Vendor

Seventy percent of surveyed organizations in the United States and Canada, and 62% in Europe, already ship Zephyr in commercial products, according to Linux Foundation Research published in March 2026. Another 69% plan to expand that use further, and the project has grown from roughly 100 contributors at its 2016 launch to more than 3,000 today, supporting over 1,000 hardware boards across Arm, RISC-V, and x86.

That growth happened because no single chip vendor controls Zephyr’s release direction. A team can prototype on one microcontroller and port to a cheaper one later without rewriting the application layer.

Eclipse ThreadX: A Paid RTOS That Went Free

Azure RTOS used to require a license fee until 2023, when Microsoft donated the ThreadX kernel, already running on 12 billion devices, to the Eclipse Foundation under the MIT license. It’s now governed independently of any single vendor.

That move matters for safety-critical IoT work specifically. ThreadX carries IEC 61508, ISO 26262, and IEC 62304 certification lineage, which puts it on short lists for medical devices and automotive controllers where an uncertified kernel is disqualifying on day one, regardless of how well it performs.

When a Full Linux Distribution Still Wins

Not every connected device needs hard real-time guarantees, and treating “IoT device” as a synonym for “needs an RTOS” wastes engineering time. A smart-city gateway that aggregates data from dozens of sensors, runs containerized analytics, and needs a full TCP/IP and TLS stack is usually better served by embedded Linux, even though Linux can’t guarantee microsecond-level timing.

The same logic applies once a project moves past a single node. A team handling industrial IoT sensor deployment across an entire factory floor, where the real bottleneck is power budgets and wireless coverage rather than scheduling precision, often gets more value from Linux’s wider driver support than from an RTOS’s timing guarantees nobody in that deployment actually needs.

The IoT RTOS Security Story Most Explainers Skip: BadAlloc

In 2021, Microsoft and the U.S. Cybersecurity and Infrastructure Security Agency disclosed 25 integer-overflow vulnerabilities, named BadAlloc, in multiple real-time operating systems including FreeRTOS and Zephyr (CISA, 2021).

What Actually Broke

The flaw sat inside memory allocation functions like calloc and realloc. An attacker who controlled the size parameter passed to one of these functions could trigger an integer overflow, which led to a heap-based buffer overflow. CISA assigned some of the affected vulnerabilities a CVSS score as high as 9.8 out of 10, the practical ceiling for severity.

Affected products spanned Amazon FreeRTOS 10.4.1, Zephyr versions before 2.5, ARM Mbed OS, and several embedded C libraries, touching device categories from consumer smart-home gear to industrial control systems and medical equipment.

BadAlloc was dangerous because of its reach: the same flaw pattern sat inside kernels already running across medical equipment, factory floors, and smart-home hubs at the same time.

What Changed in RTOS Security Since Then

If you’re specifying hardware for a European launch, ask your RTOS vendor for a software bill of materials before you ask about clock speed. The EU’s Cyber Resilience Act requires vulnerability reporting starting September 11, 2026, and full compliance by December 11, 2027, and an RTOS vendor without SBOM tooling already in place will struggle to meet either date.

Zephyr’s more recent releases have leaned into this directly, adding Trusted Firmware-M integration and SBOM generation tooling as standard features rather than bolt-ons. The same memory-allocation class of bug that caused BadAlloc now shows up wherever resource-constrained devices outnumber the security staff watching them, including the cybersecurity challenges in smart city networks that lean on these same RTOS kernels at the sensor layer.

Choosing an RTOS for Your Own IoT Project

Picking an RTOS in 2026 starts with three constraints that have nothing to do with marketing: available memory, certification requirements, and how long the device has to stay supported in the field.

A consumer gadget with a two-year support window and no certification needs can default to FreeRTOS or Zephyr and move on. A device headed for a hospital, a vehicle, or a factory floor cannot skip the certification question, no matter how good the scheduler benchmarks look. Project scale changes the calculus too. A single battery-powered sensor and a smart city deployment that needs IoT sensor integration strategies across thousands of nodes are not the same decision, even when both run the same kernel underneath.

Certification Requirements Eliminate Half the List Immediately

A medical device needs IEC 62304 lineage. An automotive controller needs ISO 26262. An industrial safety system needs IEC 61508. Pick the wrong uncertified kernel and you’re not choosing a slower path to certification, you’re choosing a kernel swap partway through development, which routinely adds 6 to 12 months to a schedule that didn’t budget for it.

Five Questions to Ask Before You Commit

• Does the kernel already carry the certification your industry requires, or will you be paying to certify it yourself?
• What’s the worst-case interrupt latency the vendor publishes, not the average?
• Who maintains security patches, and how fast have they shipped fixes for past CVEs?
• Does your hardware have the RAM and flash headroom for the kernel plus your application, with margin for the next two firmware revisions?
• Will you still be able to source security updates five years from now, given your hardware’s expected service life?

Skip any one of these and the cost shows up later, usually as a redesign instead of a code review.

 

People Also Ask

What is the difference between an RTOS and a regular operating system?

An RTOS guarantees that high-priority tasks finish within a fixed time window, while a regular OS like Windows or Linux favors average throughput and fairness across tasks. The difference matters most in devices where a late response, not just a slow one, counts as a failure, such as motor controllers, medical devices, and safety interlocks.

Can Linux run on IoT devices instead of an RTOS?

Yes, for devices that don’t need hard real-time guarantees. Embedded Linux distributions handle networking, multiple processes, and a large driver library well, which suits gateways and hubs. Devices that must hit microsecond-level deadlines, like motor controllers or safety interlocks, still need a true RTOS underneath.

Which RTOS is best for IoT devices?

There’s no single best option; the right choice depends on certification needs, hardware support, and licensing. FreeRTOS suits low-cost microcontroller projects, Zephyr suits teams wanting vendor-neutral hardware portability, and Eclipse ThreadX suits projects needing pre-built safety certification lineage for medical or automotive use.

Is FreeRTOS free to use commercially?

Yes. FreeRTOS is maintained by Amazon Web Services and distributed under the MIT license, which permits commercial use, modification, and redistribution without licensing fees. Some FreeRTOS-adjacent libraries and cloud connectivity add-ons carry separate terms, so check those individually before shipping a product.

What happens if an RTOS misses a deadline?

The outcome depends on whether the deadline is hard or soft. Missing a hard deadline, like a brake controller’s current-sensing loop, can mean the safety window has already closed by the time the system responds. Missing a soft deadline, like a video buffer refill, just causes a visible but non-dangerous glitch.

Do all IoT devices need an RTOS to work?

No. Many IoT devices, including smart speakers, thermostats, and most consumer gateways, run fine on embedded Linux or even simple polling loops because nothing they do has a hard timing requirement. An RTOS earns its complexity only when a missed deadline has a real consequence.

FAQs

What’s the practical difference between FreeRTOS, Zephyr, and Eclipse ThreadX?

FreeRTOS is a minimal, MIT-licensed kernel maintained by AWS, popular for low-cost microcontroller projects that need a small footprint and a huge base of existing examples. Zephyr, governed by the Linux Foundation, trades some of that minimalism for built-in networking, security tooling, and support for over 1,000 boards, which suits teams who want to avoid being locked into one chip vendor. Eclipse ThreadX, formerly Microsoft’s Azure RTOS, carries existing IEC 61508, ISO 26262, and IEC 62304 certification lineage, which makes it a common default for medical and automotive projects where certification cost and timeline matter more than kernel features.

How much RAM does an RTOS actually need?

This varies enormously by kernel configuration, task count, and which libraries you link in, so there’s no single honest number to quote without testing your own build. The more useful approach is to build a minimal application with your target task set, check the linker map for actual RAM and flash usage, and leave headroom for at least two future firmware revisions. Teams that skip this step routinely discover they’re out of RAM only after committing to a board.

Can I run an RTOS and Linux on the same IoT device?

Yes, and it’s a common pattern in industrial and automotive designs. A heterogeneous multi-core processor, or two separate chips connected over a fast interface, can run an RTOS like Zephyr or FreeRTOS on the real-time-critical core for motor control or sensor timing, while a Linux core handles networking, a user interface, or cloud connectivity. The split keeps hard deadlines isolated from a general-purpose OS that was never designed to guarantee them.

Is an RTOS secure by default?

No, and the 2021 BadAlloc disclosure is the clearest evidence of that: 25 memory-allocation vulnerabilities, some with a CVSS score of 9.8, were found across multiple widely deployed RTOS kernels. Security in an RTOS context depends on how quickly the maintainer ships patches, whether the vendor publishes a software bill of materials, and whether your own application code validates input sizes before passing them into allocation functions. Choosing a well-maintained kernel is a starting point, not a finish line.

Do I need a certified RTOS for a medical or automotive IoT device?

In nearly all cases, yes. Medical devices typically require IEC 62304 lineage, automotive controllers require ISO 26262, and industrial safety systems require IEC 61508, and regulators expect to see that certification trail documented for the actual kernel version you ship, not just the RTOS brand name in general. Starting a safety-critical project on an uncertified kernel and certifying it later is possible but routinely adds months to a schedule, so this decision belongs at the very start of hardware selection, not after firmware is already written.