Zephyr vs FreeRTOS vs NuttX in 2026: Choosing an RTOS for Industrial Edge Devices
Most RTOS comparisons rank schedulers. That is the wrong axis. On an industrial edge device with a ten-year service life, the scheduler is the part you will never touch again after month three; the parts that will consume your budget for a decade are drivers, the security-fix path, and the release train you are pinned to. Framed that way, Zephyr vs FreeRTOS vs NuttX is not a kernel question at all — it is a question about who owns your driver risk and how a CVE fix reaches a device already bolted to a machine. There is a decision-forcing date on the calendar right now: Zephyr 4.3.0 leaves support on 15 October 2026, four weeks from today, and any product still pinned to it stops receiving backported security fixes on that date.
What this covers: the real comparison axis (driver and governance models), the verified 2026 release and support picture for all three projects, a weighted decision matrix, each project’s security and functional-safety posture, and the failure modes that show up in year three rather than week one.
Context and Background
The three projects arrived at the same market from completely different directions, and those origins still determine their shape in 2026.
FreeRTOS is the oldest and the narrowest by design: a kernel, distributed under MIT, that you compile into a vendor’s SDK. It owns task scheduling, queues, semaphores, stream buffers and timers, and essentially nothing else. Everything below the kernel — clock trees, pin multiplexing, DMA, the Ethernet MAC — belongs to the silicon vendor’s HAL. AWS stewards the project and wraps it in a curated bundle of IoT libraries released as a dated Long Term Support line.
Zephyr took the opposite bet. It is a Linux Foundation project that imported Linux’s configuration machinery wholesale: devicetree describes hardware, Kconfig selects software, and west manages a multi-repository workspace. Drivers live in-tree behind project-owned APIs, so a gpio_pin_set() call means the same thing on a Nordic nRF part, an STM32 and a RISC-V SoC. That portability is bought with build-system complexity that is genuinely hard for a team arriving from a vendor IDE.
Apache NuttX sits in a third place. It is a small-footprint RTOS whose stated design principle is POSIX and ANSI standards compliance — it gives you open(), read(), ioctl(), pthread_create(), a shell (NSH), and device files under /dev. Its own documentation describes portability to over 15 CPU architectures, including microcontrollers with only single kilobytes of RAM and flash (NuttX security documentation). For a team whose mental model is Linux userspace, NuttX shortens the conceptual distance more than either alternative.
None of that is controversial. What is under-discussed — and what this post argues — is that these three architectural stances produce three completely different maintenance profiles, and the maintenance profile is what you are actually buying. If your firmware also carries a model, the same reasoning applies one layer up; our walkthrough of running TensorFlow Lite Micro on constrained edge hardware shows how quickly the RTOS choice constrains what you can schedule alongside inference.
The Real Axis: Who Owns Your Driver Risk
The honest one-paragraph answer: choose FreeRTOS when you are committed to one silicon family and want the vendor to own every driver; choose Zephyr when you expect to change silicon at least once and want a project-owned hardware abstraction plus an in-tree networking and security stack; choose NuttX when POSIX semantics and a Linux-like userspace model are worth more to you than ecosystem size. Everything below is the reasoning behind that compression.
Figure 1: Where the driver boundary sits in each RTOS, and what a silicon change costs as a result.
The diagram traces the same application call down three different stacks. Under Zephyr the call lands on a project-owned driver API whose backing implementation is selected by devicetree and Kconfig, so changing silicon is largely a matter of changing the board description and rebuilding. Under FreeRTOS the call lands in the vendor’s HAL, which is a different HAL on every vendor, so a silicon change means rewriting the driver layer. Under NuttX the call lands on a POSIX device file whose backing driver comes from an upstream board port, so the cost depends entirely on whether your part already has a port you can adopt.
Zephyr buys portability with build-system complexity
Zephyr’s devicetree is not decoration. It is a compile-time description of the hardware that generates the macros drivers instantiate against, which means the driver binary is specialised to your board without the driver source knowing anything about your board. The practical consequence is that a peripheral you enable on one SoC generally behaves identically on another, because both implementations satisfy the same zephyr,gpio or zephyr,i2c binding contract.
The cost is a learning curve that is real and frequently underestimated. A developer needs to hold four layers simultaneously: the devicetree source and overlays, the bindings that validate them, Kconfig symbol dependencies, and the west manifest that pins which module repositories are checked out. A build failure can originate in any of them, and the error messages do not always name the right layer. Budget several weeks of ramp-up per engineer, not several days.
The payoff arrives in year two. When a part goes on allocation — an ordinary event in industrial electronics — a Zephyr codebase can often move to a substitute part by writing a board definition. A FreeRTOS codebase bonded to a vendor HAL generally cannot.
FreeRTOS makes the vendor your dependency, for better and worse
The FreeRTOS kernel is small enough to read in an afternoon, and that is a genuine engineering virtue: there is very little in it that can surprise you, and the assert coverage keeps improving. Kernel V11.3.0, released in March 2026 and currently the latest tagged kernel release, adds asserts that catch stack overflow at task-creation time and an assert against recursive-mutex counter overflow, alongside new ports for Arm China STAR-MC3 and Cortex-M52, MPU support on the Cortex-R82 port, and FPU and vector context save for RISC-V (FreeRTOS-Kernel releases).
But the kernel is the entire deliverable. Your Ethernet driver, your flash driver, your low-power state machine and your clock configuration all come from the vendor SDK. That is a transfer of risk, not an elimination of it. If the vendor’s MAC driver has a buffer-lifetime bug, you are waiting on the vendor’s release cycle, which is generally opaque, sometimes tied to a support contract, and frequently slower than an upstream open-source project. You have outsourced the work and outsourced the schedule with it.
The counter-argument is strong in a specific case: when the hardware is fixed for the product’s whole life, the vendor’s HAL is the most tested code you will ever run on that part, because every other customer of that part is running it too. Test hours are a real asset. Single-vendor commitment is a legitimate strategy, not a failure of nerve — it just needs to be a decision rather than an accident.
NuttX trades ecosystem size for a familiar mental model
NuttX’s POSIX surface is the feature. A driver is a character or block device; an application opens it, reads it, and configures it with ioctl(). Engineers who have written Linux device drivers are productive almost immediately, and code can be exercised on a host using the simulator build before hardware exists. For teams building instrumentation with a filesystem, a shell and multiple concurrent I/O streams, that ergonomic advantage compounds.
The trade is ecosystem depth. Board support, wireless stacks and vendor engagement are thinner than Zephyr’s, and considerably thinner than the FreeRTOS-plus-vendor-SDK combination for any given part. NuttX also documents an explicit philosophical position that shapes its threat model: because it targets microcontrollers with kilobytes of memory, it declines to add validation “outside a generic nature,” and its security documentation states plainly that function-parameter and incoming-data validation “rests on the custom application/firmware developer.” That is a defensible stance for a kilobyte-class RTOS. It is also a requirement you inherit.
The 2026 Release and Support Picture
This is where most comparison articles go stale, and where the decision actually gets made. All figures below were re-confirmed against project sources on 19 September 2026.
Figure 2: Three release trains with three different upgrade obligations.
The diagram contrasts the upgrade rhythm each project imposes. Zephyr offers a choice of two rhythms — annual on the stable line, multi-year on LTS. FreeRTOS offers a long, dated bundle with an optional commercial extension. NuttX offers neither; there is no maintenance branch, so remediation is always a forward move onto the newest release.
Zephyr: two release cadences, and a deadline next month
Zephyr’s releases page currently lists three supported releases:
| Zephyr release | Released | End of life | Status |
|---|---|---|---|
| 4.4.0 (current point 4.4.1) | 2026-04-14 | 2027-04-12 | Latest stable |
| 4.3.0 (current point 4.3.1) | 2025-11-14 | 2026-10-15 | Stable |
| 3.7.0, LTS3 (current point 3.7.2) | 2024-07-26 | 2029-07-27 | Long Term Support |
Two things follow. First, 4.3.0 — shipped in November 2025 and still the release many fielded builds were frozen against — goes end-of-life on 15 October 2026. After that date it stops receiving security backports, because Zephyr’s documented policy backports each security fix to the current LTS plus the most recent two releases only. If you are on 4.3 in November you are running unpatched by construction, whatever your SBOM says.
Second, Zephyr has moved to a six-month cadence targeting April and October, with 4.5 slated for October 2026 (the release-management wiki lists feature freeze in the week of 28 September 2026 and release in the week of 19 October 2026). The next LTS is 4.6 in April 2027, designated LTS4. LTS releases are branched and maintained independently for roughly five years and published every two and a half to three years.
That produces a clean strategic fork. Teams that want features take the stable line and accept an uplift roughly every twelve months. Teams that want stability sit on 3.7 LTS until 4.6 lands, then plan one large migration. The expensive mistake is the third option nobody chooses deliberately: pinning to a stable release and then not upgrading, which is exactly the position 4.3 users are in this month.
For context on what moves between releases: 4.3 replaced the legacy USB device stack with a new one built on the modern UDC API supporting multiple simultaneous controllers and runtime configuration, added an experimental CPU frequency-scaling subsystem and a cpu_load subsystem exposing scheduler-statistics-based CPU usage, introduced a compiler-instrumentation-based tracing subsystem, and shipped an OCPP library for EV charging stations. Zephyr 4.4 then became the first release to support Zephyr SDK 1.0, moved the minimum C standard to C17, added the OpenRISC architecture, added Wi-Fi P2P and WireGuard to the networking stack, expanded experimental USB host support, and introduced new OTP, biometrics and wake-up-controller driver APIs. Neither of those is a small delta. Skipping two of them is not a weekend.
FreeRTOS: a dated bundle with an unusually long tail
FreeRTOS handles longevity differently and, for a certain kind of product, better. The current line is 202604-LTS, whose component manifest pins FreeRTOS Kernel 11.3.0, FreeRTOS-Plus-TCP 4.4.1, coreMQTT 5.0.2, coreHTTP 3.1.3, corePKCS11 3.6.4, coreJSON 3.3.1, coreSNTP 2.0.0, the Cellular Interface 1.4.2, backoffAlgorithm 1.4.2, SigV4 1.3.1, AWS IoT Device Shadow 1.4.2, Device Defender 1.4.1, Jobs 2.0.1, Fleet Provisioning 1.2.2 and MQTT File Streams 1.2.0 — every one of them supported until 30 April 2028 (FreeRTOS-LTS).
Three details in that manifest matter more than the version numbers:
The bundle is versioned by date with a patch suffix (202604.01 is the first patch to the April 2026 line), so your SBOM entry is a single coordinate rather than fifteen. For a regulated product that is a meaningful reduction in paperwork.
Backward compatibility with the previous 202406.xx line holds except for coreMQTT, coreSNTP and AWS IoT Jobs, all three of which took major-version bumps with their own migration guides. An LTS-to-LTS move is therefore not automatically a drop-in, which is the assumption most teams make when they budget the upgrade.
The AWS IoT OTA library has not been part of LTS since the 202212 line; MQTT File Streams is included instead, and the recommended pattern is a modular OTA design built on it. Teams carrying old OTA code forward are carrying something the LTS no longer covers.
Beyond the two-year window, AWS offers an Extended Maintenance Plan providing security patches and critical bug fixes on a chosen LTS version for up to an additional ten years. For a device with a fifteen-year field life and a change-control process that makes every kernel uplift a qualification event, that is an option none of the other two projects offers, and it is frequently the deciding factor in industrial and medical programmes.
NuttX: rolling, quarterly, no LTS
NuttX’s download page shows a steady rhythm: 12.10.0 on 2025-07-07, 12.11.0 on 2025-10-05, 12.12.0 on 2025-12-31, 12.13.0 on 2026-04-02, then the 13.x line with 13.0.0 on 2026-07-12 and 13.0.1 on 2026-09-15. Roughly quarterly, with a point release when one is warranted.
What the page does not show is any maintenance branch. There is no NuttX equivalent of Zephyr’s LTS3 or the 202604-LTS bundle. The project’s own security documentation states the consequence directly: security fixes “are usually part of the standard release cycle,” with special patch releases only for urgent cases. Look at the CVE records and the pattern is consistent — CVE-2025-48769, a use-after-free in fs/vfs/fs_rename, affects versions from 7.20 before 12.11.0 and is fixed in 12.11.0; CVE-2025-48768 affects 10.0.0 before 12.10.0 and is fixed in 12.10.0; CVE-2025-35003, a set of Bluetooth HCI and UART stack overflows, affects 7.25 before 12.9.0 and is fixed in 12.9.0.
Read that as an operating requirement, not a criticism. Running NuttX in the field means committing to a forward-upgrade posture: you must be able to take a whole new upstream release, revalidate, and ship it, on a quarterly-ish rhythm, for the life of the product. Teams with the CI and test-fixture discipline to do that get a very current, very clean codebase. Teams that freeze a version and walk away end up carrying an unpatched kernel with no supported remediation path, and they usually do not discover this until an auditor asks.
A Weighted Decision Matrix
A matrix is only useful if the weights are yours. The weights below are a starting point for a connected industrial sensor or controller with a ten-year service life, a five-person firmware team and at least one network interface. Change them and the answer legitimately changes — that is the point.
Ratings are qualitative and deliberately so. Any numeric score here would be invented precision.
| Criterion | Weight | Zephyr | FreeRTOS + vendor SDK | NuttX |
|---|---|---|---|---|
| Hardware portability across vendors | 20% | Strong — devicetree plus project-owned driver APIs | Weak — HAL is vendor-specific by construction | Moderate — POSIX API is stable, board ports vary |
| In-tree networking and TLS | 15% | Strong — IP stack, TLS and Wi-Fi/BLE in-tree | Moderate — FreeRTOS-Plus-TCP plus core libraries in LTS | Moderate — POSIX sockets and a network stack, thinner wireless |
| Security update path and CVE handling | 15% | Strong — PSIRT, CVEs, backports to LTS plus two releases | Strong — dated LTS with two-year support, EMP extension | Weak-to-moderate — fixes ride the next release, no LTS branch |
| Long-term support window | 15% | Strong on LTS (~5 years), weak on stable (~12 months) | Strongest — 2 years plus optional 10-year extension | Weakest — no maintenance branch |
| Functional-safety route | 10% | In progress — IEC 61508 SIL 3 targeted, not complete | Indirect but available — SafeRTOS is pre-certified | No project certification route |
| Toolchain, CI and reproducibility | 10% | Strong — Zephyr SDK, west, twister, but complex |
Strong — vendor IDE plus plain CMake, simple to reproduce | Moderate — Kconfig-based, simulator build aids CI |
| OTA and secure boot | 8% | Strong — MCUboot is the native path | Moderate — MQTT File Streams pattern plus vendor bootloader | Moderate — bootloader choice is largely yours |
| Talent availability and ramp-up | 7% | Moderate — large community, steep devicetree curve | Strong — most widely known embedded kernel | Moderate — instant for POSIX-fluent engineers, niche otherwise |
For the profile described above, Zephyr wins on the portability and networking weights, FreeRTOS wins decisively on support-window and simplicity, and NuttX wins only when the POSIX ergonomics or an existing board port are worth the maintenance obligation. Re-weight for a single-SKU device on fixed silicon with a fifteen-year life and FreeRTOS plus EMP typically wins outright. Re-weight for a product family spanning three SoC vendors and Zephyr usually wins before you finish filling in the table.
Figure 3: A selection procedure that resolves the hardest constraints first.
The flow orders the gates by irreversibility. A certified-safety requirement is the least negotiable, so it comes first and usually routes you off the general-purpose options entirely. Silicon commitment comes next, because it determines whether portability has any value. Only then do networking requirements and team fluency break the remaining tie. Running the gates in this order prevents the common failure of picking on developer preference and discovering the safety constraint in month eight.
Security, CVE Handling and the Functional-Safety Route
This section is where the three projects diverge most sharply, and where marketing copy is least reliable. Everything here is from primary project sources.
Figure 4: The path a vulnerability takes from private report to a patched device in the field.
The sequence shows the hop that determines your real exposure: the gap between a fix landing on a release branch and a signed image reaching hardware. Projects control the left half of that diagram. You control the right half, and the right half is usually the longer one.
Zephyr has the most formal process of the three
Zephyr runs a PSIRT with a documented pipeline. Reports go to a draft GitHub security advisory or to vulnerabilities@zephyrproject.org and are acknowledged and analysed within one week. Issues move through New, Triage, Assigned, Review, Accepted and Public states. Embargo is capped at 90 days — 30 days intended for the project to fix, 60 for external parties building products on Zephyr to apply and distribute fixes. Developers are instructed not to reveal the security nature of a commit or reference the CVE number while embargoed. Every issue treated as a vulnerability gets a CVE, each release ships a list of CVEs fixed, and detail is published after embargo (Zephyr security vulnerability reporting).
Two operational details matter to an industrial integrator. First, backports go to the current LTS and the most recent two releases — that is the concrete meaning of a support window, and the reason the 4.3 EOL date is a hard deadline rather than a suggestion. Second, there is a vulnerability-alerts mailing list, joinable through the project’s Vulnerability Registry after vetting, that receives advisory links, CVE numbers, affected subsystems, severity and backport status during embargo. If you ship products on Zephyr and are not on that list, you are learning about your own exposure at the same time as the public. Zephyr also publishes documentation on the EU Cyber Resilience Act and ETSI EN 303 645, which is the kind of material a compliance team will ask for by name.
FreeRTOS externalises safety to a separate certified product
FreeRTOS itself is not a certified safety kernel, and it is important to state that plainly. The safety route is SafeRTOS, from WITTENSTEIN high integrity systems, and the relationship is precise: SafeRTOS is based on the functional model of the FreeRTOS kernel but is not the FreeRTOS kernel. WHIS engineers took the FreeRTOS functional model, ran a full HAZOP on it, derived a safety-requirements set, and put that through an IEC 61508-3 SIL 3 development lifecycle to produce a separate code base and design assurance pack. SafeRTOS is available pre-certified to IEC 61508 SIL 3 and ISO 26262 ASIL D by TÜV SÜD, and was first independently certified by TÜV SÜD in 2007 (FreeRTOS SafeRTOS partner page).
The two share a scheduling algorithm and similar APIs, which is why the migration story is credible. But it is a commercial product with a different licence and a different code base, so “we can move to SafeRTOS later” is a procurement and porting decision, not a configuration flag. Plan it as a project.
Zephyr’s safety certification is real work in progress, not a completed claim
Zephyr’s Safety Committee scope is IEC 61508, targeting SIL 3 and Systematic Capability 3 for a limited source scope, with all Kernel components in scope. The project’s own Safety FAQ is refreshingly blunt about status: as of 2025 the safety leadership targeted an end-to-end example of the certification practice and artifacts for 2026, and completion of the project certification “depends heavily on community and company contributions and may not happen before 2027 or later.” Do not read a target as a certificate.
Four constraints from that FAQ will shape any programme that plans to lean on it. Specific target hardware, devices and compilers are explicitly not in scope, so as an integrator you must qualify your own compiler for your platform — the project ships source, not qualified binaries. Libraries outside the certification scope are yours to qualify. Safety evidence and the safety manual are to be provided to specific tiered members only, which is a membership-tier question for your procurement team, not an engineering one. And on automotive: there is a contract with an assessor and an objective to certify to ISO 26262 ASIL D, but the project does not plan to perform MC/DC coverage as ASIL D prescribes, which the FAQ itself names as a resulting gap. Medical (IEC 62304 / ISO 14971) and appliance (IEC 60730 / IEC 60335) standards are listed as interest without firm targets; rail (EN 50176) and aerospace (DO-178C) are explicitly not planned.
NuttX handles CVEs through the Apache process, and has no safety route
NuttX vulnerabilities are handled under the Apache Security Team guide. The Apache Security Team is the CVE Numbering Authority covering all Apache projects and the only body that can allocate IDs for ASF issues. Reports go to security@nuttx.apache.org, automatically copied to security@apache.org; details stay out of the public tracker until formal announcement; commits must not reference the security nature of the change; and the public announcement goes to the release-announcement destinations, the reporter, the project security list and oss-security@lists.openwall.com.
That is a mature disclosure process. What it does not come with is a backport branch or a functional-safety certification programme. For a device under IEC 61508 or IEC 62443 scrutiny, that combination — quarterly forward upgrades as the only remediation path, plus no certification artifacts — is usually disqualifying at the gate, regardless of how good the code is. It is the single most important thing to establish before a team falls in love with the POSIX API.
Trade-offs, Gotchas, and What Goes Wrong
The failure modes below are the ones that surface in year two or three, long after the selection meeting.
The stale-pin trap. A team picks a Zephyr stable release, ships, and never plans an uplift. Twelve months later the release is EOL, security fixes stop being backported, and the jump to current spans two migration guides including a C-standard change and a USB stack replacement. The upgrade that was never budgeted becomes a quarter of engineering time under deadline pressure. Zephyr’s stable line is an explicit annual commitment; treat the EOL date as a scheduled release, not a risk item.
The LTS-to-LTS drop-in assumption. FreeRTOS LTS bundles are backward compatible except where component majors move. Moving from 202406.xx to 202604 means migrating coreMQTT v2 to v5, coreSNTP v1 to v2 and Jobs v1 to v2, each with its own guide. Budget an integration sprint, not a manifest edit.
Forward-only remediation without the CI to support it. NuttX’s model works well for teams with hardware-in-the-loop CI that can revalidate a full upstream bump in days. Without it, the quarterly obligation becomes a permanent backlog item and the device silently ages out of patchability.
Certification claims that do not survive an audit. “Zephyr is going for SIL 3” is true and not the same as “our kernel is certified.” Likewise, SafeRTOS’s certification does not transfer to FreeRTOS. Assessors ask for certificates and scope statements; vague inheritance claims fail.
Compiler qualification arriving as a surprise. Zephyr explicitly excludes target hardware and compilers from its certification scope. On a safety programme, compiler qualification is a line item with real cost and lead time, and it is not the RTOS project’s job.
Vendor-HAL bugs you cannot fix. The flip side of outsourcing drivers to a silicon vendor is that a defect in their MAC or flash driver is on their schedule. Before committing, ask the vendor for their security-advisory process and patch history in writing. Many do not have one.
Missing the embargo channel. Zephyr’s vulnerability-alerts list exists precisely so product builders can prepare during the 60-day external window. Not joining it converts a planned patch into an incident.
Wireless stack assumptions. If the product needs a certified wireless profile, that constraint may override everything above. Matter, Thread and Bluetooth mesh availability differ sharply across the three; our Matter 2.0 architecture deep dive covers what the stack actually demands of the host RTOS. The same is true on the long-range side, where the LoRaWAN, NB-IoT and LTE-M comparison shows radio choice constraining power management and scheduling in ways the RTOS cannot paper over.
Practical Recommendations
Decide the irreversible things first and the pleasant things last. Safety and certification scope, silicon commitment and support-window obligations are irreversible within a product generation. Developer ergonomics are not, and should never lead.
Write down the support window you are actually buying and put its expiry in the release calendar. If that is Zephyr stable, you owe an uplift every twelve months. If it is Zephyr LTS, you owe a large migration every two and a half to three years. If it is a FreeRTOS LTS bundle, you owe a bundle migration every two years or a commercial extension decision. If it is NuttX, you owe a quarterly forward upgrade for the life of the product.
Then build the plumbing that makes that obligation survivable: hardware-in-the-loop CI, a reproducible toolchain pin, a signed-image OTA path proven on real hardware before first ship, and a named person subscribed to each upstream’s security channel.
A selection checklist worth running before the decision is minuted:
- Name the safety standard and target level in writing, or record that none applies. This gate resolves first.
- Confirm the support window and EOL date of the exact release you intend to ship, from the project’s own release page.
- Verify the backport policy covers that release for the product’s expected patch lifetime.
- Subscribe to the upstream security channel: Zephyr’s Vulnerability Registry, the FreeRTOS LTS repository notifications, or the NuttX and Apache announcement lists.
- Inventory every driver you need and record who owns it — upstream project, silicon vendor, or you.
- Prove one full upgrade end to end on a dev unit before first ship, and time it. That number is your annual maintenance budget.
- Confirm the bootloader and OTA story on your part, including rollback and anti-rollback counters.
- Ask the silicon vendor, in writing, for their HAL security-advisory process.
- If considering Zephyr for safety, check the membership tier required to receive safety evidence before assuming access.
Frequently Asked Questions
Is Zephyr 4.3 still supported in September 2026?
Yes, but barely. Zephyr’s releases page lists 4.3.0 as supported with an end-of-life date of 15 October 2026, with 4.3.1 as the current point release. After that date, 4.3 stops receiving backported security fixes, because Zephyr backports each security issue only to the current LTS and the two most recent releases. Teams on 4.3 should be planning a move to 4.4 (EOL 12 April 2027) or to 3.7 LTS (EOL 27 July 2029) now, not in October.
Which of the three has a certified functional-safety kernel?
None of the three open-source kernels is itself certified today. The available pre-certified path is SafeRTOS from WITTENSTEIN high integrity systems, which is based on the FreeRTOS functional model but is a separate code base, available pre-certified to IEC 61508 SIL 3 and ISO 26262 ASIL D by TÜV SÜD. Zephyr’s Safety Committee targets IEC 61508 SIL 3 with all kernel components in scope, but its own FAQ says project certification may not happen before 2027 or later. NuttX has no project certification route.
What is the current FreeRTOS LTS release and how long is it supported?
FreeRTOS 202604-LTS is the current line. It pins FreeRTOS Kernel 11.3.0 together with FreeRTOS-Plus-TCP 4.4.1, coreMQTT 5.0.2, coreHTTP 3.1.3, corePKCS11 3.6.4 and the rest of the AWS IoT library set, all supported until 30 April 2028. AWS separately offers an Extended Maintenance Plan providing security patches on a chosen LTS version for up to an additional ten years, which is the longest support option available across the three projects.
Does NuttX have a long-term support branch?
No. Apache NuttX ships roughly quarterly — 12.13.0 on 2 April 2026, 13.0.0 on 12 July 2026 and 13.0.1 on 15 September 2026 — and its security documentation states that fixes are usually part of the standard release cycle, with special patch releases only in urgent cases. The CVE records bear this out: each is listed as fixed in a specific forward release rather than backported. Running NuttX in the field therefore means committing to forward upgrades as the remediation mechanism.
How much does Zephyr’s devicetree learning curve really cost?
Expect weeks, not days, per engineer, because a developer must hold four interacting layers at once: devicetree sources and overlays, the bindings that validate them, Kconfig dependencies, and the west manifest that pins module repositories. Build errors do not always originate in the layer they appear to. The offsetting benefit arrives when you change silicon — a part substitution that is a board-definition exercise under Zephyr is typically a driver-layer rewrite under a vendor HAL.
Can I mix approaches, for example FreeRTOS now and Zephyr later?
Technically yes, practically it is expensive. Application logic written against POSIX-ish or abstracted interfaces ports reasonably; anything touching peripherals does not, because that is exactly where the three models differ. The pragmatic hedge is architectural, not operating-system-level: isolate hardware access behind your own thin interface from day one, keep protocol and business logic free of RTOS calls, and the eventual port becomes a driver-layer project rather than a rewrite.
Further Reading
- Rust embedded no_std firmware for microcontrollers — how memory-safe firmware interacts with each of these RTOS driver models.
- Edge AI with TensorFlow Lite Micro on ESP32: implementation guide — what running inference alongside real-time tasks demands of the scheduler.
- Matter protocol 2.0 smart home architecture deep dive — where wireless certification requirements override RTOS preference.
- LoRaWAN vs NB-IoT vs LTE-M for industrial IoT — radio selection constraints that reach back into power management and scheduling.
- Zephyr Project releases and support policy — the authoritative EOL table and backport policy.
- FreeRTOS LTS component manifest — exact library versions and support dates for 202604-LTS.
- Apache NuttX security documentation — CVE list, handling process and the project’s stated validation boundary.
By Riju — about
