RTOS Security for Medical Devices: A Practical Guide

Reviewed September 17, 2026

Infusion pumps, ventilators, cardiac monitors, and surgical robotics almost all run on a real-time operating system rather than a general-purpose one, and that choice carries security tradeoffs most teams do not plan for until a reviewer or a penetration tester finds them. An RTOS is built to guarantee timing, not to contain a compromised process the way Linux or Windows attempts to. That difference shapes the entire threat model: the network stack, the bootloader, and the debug interface are not incidental attack surface, they are often the only real perimeter the device has. Manufacturers that treat RTOS security as an afterthought to functional safety tend to discover the gap during FDA review or, worse, in the field.

Why This Matters

An RTOS-level flaw sits underneath every application-layer control a manufacturer builds, which means a single unpatched stack vulnerability or an unsecured bootloader can undo years of otherwise solid secure development work. The FDA's "Cybersecurity in Medical Devices" final guidance, dated February 3, 2026, expects manufacturers to document cybersecurity risk management across the full software bill of materials, and an RTOS with its middleware is one of the largest single components in that bill for most embedded devices. Reviewers increasingly ask specifically how a device manages RTOS and middleware vulnerabilities post-market, not just at clearance.

The CISA 2026 SBOM Minimum Elements, which supersede the 2021 NTIA baseline, expect component-level identification precise enough to track an RTOS version and its included middleware individually. A device that lists only "firmware v2.3" without breaking out the underlying RTOS and network stack version does not meet that bar. Getting RTOS security right is also a practical necessity: many of these platforms cannot be patched in the field as easily as a general-purpose OS, so the design decisions made before release determine most of the device's exposure for its entire service life.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; CISA Cybersecurity Advisories (including ICS medical advisories); CISA Known Exploited Vulnerabilities Catalog.

What Is an RTOS and Why Do Medical Devices Use One?

An RTOS is an operating system built to guarantee that tasks execute within a predictable, bounded time window rather than simply as fast as possible. Medical devices use one because a ventilator's breath cycle or an infusion pump's dosing loop cannot tolerate the scheduling jitter of a general-purpose OS under load. RTOS platforms also offer a small footprint, often a few hundred kilobytes, which suits resource-constrained microcontrollers where a full operating system would not fit.

Which RTOS Platforms Are Common in Medtech?

FreeRTOS, Zephyr, VxWorks, QNX, and Eclipse ThreadX (formerly Azure RTOS) cover most of the market, with embedded Linux running PREEMPT_RT as the contrasting choice when soft real-time is acceptable. FreeRTOS and Zephyr are widely used open source options on microcontroller-class hardware. VxWorks and QNX are commercial platforms common in higher-complexity devices like imaging and surgical systems. Embedded Linux with the PREEMPT_RT patch set trades some determinism guarantees for a fuller feature set, mature process isolation, and a larger ecosystem of security tooling.

Why Does RTOS Security Differ From General-Purpose OS Security?

RTOS security differs because most RTOS configurations were designed around cooperative trust, not adversarial isolation. Many deployments run every task in a single flat memory space with no kernel/user separation, so there is no default boundary preventing one compromised task from reading or corrupting another task's memory. Address space layout randomization is limited or absent on many RTOS builds, and field patchability is constrained by hardware update mechanisms, so vulnerabilities can persist for the device's service life once shipped.

What Is the Real Attack Surface on an RTOS-Based Device?

The real attack surface is the network stack, the bootloader, debug interfaces, the OTA update path, and any third-party middleware bundled with the RTOS. Embedded TCP/IP stacks have historically been a recurring source of vulnerability classes affecting multiple RTOS platforms at once, since many devices license or bundle the same third-party network stack. Bootloaders and debug interfaces such as JTAG or SWD are frequent targets because physical or early-boot access can bypass every control that only activates after the operating system finishes loading. OTA update mechanisms are attack surface too, since an update path that does not verify signatures is a direct path to arbitrary code execution.

[KEY REQUIREMENT] Every third-party network stack, middleware component, and bootloader used with the RTOS needs its own entry in the risk assessment and its own line in the SBOM, not a single blanket entry for "RTOS."

What Controls Actually Reduce RTOS Risk?

The core control set is task isolation, secure boot, a hardware root of trust, and network stack minimization, layered together rather than relied on individually. Where the microcontroller supports it, an MPU or MMU can enforce memory boundaries between tasks even on an RTOS that does not do so by default. Secure boot with cryptographically signed images, backed by a hardware root of trust such as a secure element or a TrustZone-style enclave, prevents unsigned or tampered firmware from executing. Memory-safe coding practices, stack canaries, watchdog timers, disabling unused network services, and shrinking the network stack to only the protocols the device actually needs all reduce the paths available to an attacker.

How Should SBOM and Vulnerability Monitoring Work for an RTOS?

The RTOS itself, its version, and every middleware component bundled with it must appear in the SBOM as identifiable, versioned entries. A device team monitoring only its own application code for vulnerabilities while treating the RTOS as an opaque black box will miss disclosures against the stack it is actually running. Vulnerability monitoring has to match SBOM component names and versions against public advisories on an ongoing basis, and that matching only works if the SBOM was specific about which RTOS build and which network stack version shipped.

What Does a Realistic Patching Strategy Look Like?

See also: Home Use vs Hospital Device Cybersecurity Requirements, Indications for Use, Predicates, and Cybersecurity Scope, and Breakthrough Device Designation and Cybersecurity.

A realistic patching strategy accounts for the fact that many RTOS-based devices cannot receive updates as fluidly as a phone or a server. Field constraints, bandwidth, connectivity, safety interlocks that block updates during active use, and hardware without a rollback partition all limit how quickly a patch can reach a deployed device. Manufacturers need to design the OTA mechanism, including signature verification and a rollback path, before release, because retrofitting a secure update mechanism into fielded hardware is far harder than building it in from the start.

What Does the FDA Expect Documented for RTOS Security?

The FDA expects the RTOS, its configuration, and its associated middleware documented as identified components within the SPDF, with evidence that their specific risks were assessed rather than folded into a generic application-level threat model. That documentation should show which isolation, boot integrity, and network-minimization controls were applied and why, tied to the SBOM entries for the RTOS and its components. Reviewers also look for a postmarket monitoring and patching plan that acknowledges the RTOS's specific field-update constraints rather than assuming updates work the same way they would on a general-purpose OS.

RTOS Security Capability Comparison

The table below compares security-relevant capability areas at a general level; specific platform configurations vary by vendor, release, and how a manufacturer integrates the RTOS, so this is a framework for evaluation rather than a ranking.

How Blue Goat Cyber Approaches This

Blue Goat Cyber evaluates RTOS-based devices by mapping the actual attack surface, network stack, bootloader, debug interfaces, and update path, rather than treating the RTOS as a single opaque component. Our medical device threat modeling work identifies which middleware and network stack components are bundled with the RTOS so they can be assessed and tracked individually. We also support SBOM services for medtech so the RTOS and its components are captured with the version-level specificity the CISA 2026 minimum elements expect. When testing is warranted, our medical device penetration testing engagements probe the boot chain, update path, and exposed services specific to the platform in use.

Related reading: Code and Data Integrity Controls Every Device Maker Needs, MedJacking Explained: What the Term Covers and What Doesn't.

Frequently Asked Questions

Is FreeRTOS secure enough for a medical device?

FreeRTOS can be used securely, but security depends entirely on the manufacturer's configuration, not the kernel alone. Task isolation, secure boot, and network stack minimization have to be added and configured by the integrator, since the base kernel does not enforce them by default.

Why don't RTOS platforms have ASLR like Linux or Windows?

Many RTOS platforms run in a flat, deterministic memory layout specifically because address randomization can interfere with the timing guarantees the RTOS exists to provide. Some newer RTOS and hardware combinations add partial mitigations, but broad ASLR support is not standard across the category.

What is the difference between RTOS security and functional safety?

Functional safety addresses unintended failures like a stuck sensor or a timing fault, while RTOS security addresses intentional, adversarial actions like a network attacker exploiting a stack vulnerability. The two overlap in practice, since a security failure can trigger a safety hazard, but they require different analysis methods.

Do I need an MPU to secure an RTOS-based device?

An MPU is one of the most effective controls available for containing a compromised task on a microcontroller-class device, so it should be used wherever the hardware supports it. Without an MPU, task isolation typically has to rely on software discipline alone, which is a weaker control.

How does embedded Linux with PREEMPT_RT compare to a traditional RTOS for security?

Embedded Linux with PREEMPT_RT offers more mature process isolation, ASLR, and a larger security tooling ecosystem than most traditional RTOS platforms, at the cost of a larger footprint and softer real-time guarantees. It is a reasonable choice when hard real-time determinism is not strictly required.

What should go in the SBOM for an RTOS-based device?

The SBOM should list the RTOS itself by name and version, along with every bundled middleware component such as the network stack, file system, and any third-party libraries, each with its own version identifier. A single combined "firmware" entry is not sufficient for vulnerability monitoring or FDA review.

CTA

If your device runs on an RTOS and your SBOM still lists it as a single opaque firmware entry, that gap is worth closing before an FDA reviewer or an attacker finds it first. Contact us to scope a threat model and SBOM review built around your specific RTOS and middleware stack.

Continue the RTOS security series

Dive deeper with these companion articles:

• VxWorks Vulnerabilities in Medical Devices
• SoC Security in Medical Devices: Reducing Attack Surface