EU Cyber Resilience Act: What does it mean for FreeRTOS vs. Embedded Linux?

The EU Cyber Resilience Act (CRA) entered into force in December 2024. Starting 11 December 2027, products with digital elements, from smart home controllers to industrial gateways, may only be sold in the EU if they meet the new cybersecurity requirements.

For IoT device manufacturers, this means: security updates over the entire expected lifecycle (minimum 5 years), structured vulnerability handling, an SBOM (Software Bill of Materials) and a conformity assessment.

What does this mean technically? We compare the two most common IoT platforms from a maintenance perspective.

The underestimated reporting deadlines

Before we get to platform choice: the CRA requires not just updates, but also demonstrable response to known vulnerabilities. Once an actively exploited vulnerability is discovered, strict deadlines apply:

Deadline	What
24 hours	Early warning to ENISA: report an actively exploited vulnerability
72 hours	Detailed notification to ENISA and the responsible CSIRT
14 days	Final report once corrective measure is available
Without undue delay	Inform affected users

On top of that: a single point of contact for vulnerability reports, a published coordinated vulnerability disclosure policy, documented processes.

In practice: you need on call capability. If a critical vulnerability goes public on Friday evening, the 24 hour clock runs across the weekend. By Monday morning the window is long gone.

FreeRTOS™: the minimalist classic

Aspect	Assessment
Codebase	Very small. Kernel plus your own drivers, often under 100 KB
Attack surface	Very low. No userland, no shells, no network daemon by default
Known CVEs (stack)	Few; concentrated on the libraries you picked: mbedTLS, FreeRTOS+TCP, FatFS
Update mechanism	DIY: A/B bootloader, signed firmware
Maintenance effort	Low, few dependencies, long MCU lifecycles
SBOM generation	Easy, almost everything in your own repo

Advantage under CRA: The list of components you have to track is manageable and you choose them yourself. When a new mbedTLS CVE drops, you know within minutes whether you’re affected.

On the TCP/IP choice: we go with FreeRTOS+TCP. The stack was adopted by Amazon, audited multiple times, and integrates cleanly with the scheduler (defined tasks, clear memory pools, none of the global state hackery you get elsewhere). The historical CVEs from 2018 have been closed for years. lwIP is an alternative, but you pay for it functionally and in maintenance with the complexity of a stack that wasn’t designed for RTOS threading.

Disadvantage: You have to build the entire update infrastructure yourself. Bootloader, signature verification, rollback protection, OTA server.

Zephyr®: the middleweight

Zephyr is often lumped together with FreeRTOS but is significantly larger. It ships its own networking stack (IPv4/IPv6, TCP, UDP, CoAP, MQTT, LwM2M), Bluetooth stack, USB stack, OpenThread, hundreds of board support packages and an integrated build system.

Aspect	Assessment
Codebase	Medium. With networking and BLE often 500 KB to several MB
Attack surface	Medium. Active network services depending on configuration
Known CVEs	Multiple per release cycle. Zephyr publishes regular security advisories
Update mechanism	MCUboot is integrated, A/B slots and signed images out of the box
Maintenance effort	Medium. You follow the Zephyr LTS branch and pull patches
SBOM generation	West supports SPDX export

Advantage under CRA: MCUboot and the update path are already part of the platform. The LTS branch (every 2 years, 2.5 years of support) gives a predictable update cadence.

Disadvantage: You inherit the complexity of a full networking stack. A built in MQTT client you never use is still CVE material.

Embedded Linux® (Yocto®, Buildroot, Debian): the big brother

Aspect	Assessment
Codebase	Large. Kernel, glibc, OpenSSL, BusyBox, service daemons (often over 100 MB)
Attack surface	High. Shell, SSH, DBus, possibly web server, browser engine
Known CVEs	Many and constantly new. Linux kernel alone has dozens of CVEs per month
Update mechanism	Mature tools available: RAUC, Mender, swupdate
Maintenance effort	High. Yocto rebuild on every relevant CVE, backports, tests
SBOM generation	Tooling available. Yocto generates SPDX SBOM automatically, the cve-check class reports CVEs against your build

Advantage under CRA: Yocto has CVE trackers built in and SBOM generation. That’s gold. The established OTA frameworks (RAUC, Mender) cover the “updates during lifecycle” requirement.

Disadvantage: OpenSSL alone had multiple critical CVEs per year over the last 5 years. Each of these CVEs requires: build, test, sign, OTA rollout to all deployed devices. This only scales if the infrastructure is in place from the start.

And why does nobody actually do Embedded BSD?

Fun side question: NetBSD runs on pretty much anything with a CPU, from VAX through ARM to SH4. FreeBSD powers every other firewall on the planet (pfSense, OPNsense, JunOS). And Apple recognized the potential back in the late 90s: macOS and iOS are still based on Darwin, whose userland comes from FreeBSD. The permissive BSD license let Apple stack proprietary layers on top without having to open source the kernel. Both BSDs have strong arguments under CRA:

Aspect	BSD advantage
License	BSD/MIT instead of GPL. No copyleft obligations, no need to release sources
Attack surface	Slimmer than typical Linux distros, less kitchen sink
Network stack	Historically excellent, OpenBSD/PF is state of the art
Documentation	Consistent, maintained, single source of truth (Handbook)
CVE discipline	Clear security advisories, fast patches

So why does almost no one do this in IoT?

• SoC vendors ship Linux BSPs. When NXP®, ST or Allwinner release a new chip, you get Yocto layers and kernel patches, not NetBSD drivers.
• Driver gaps for new peripherals. Cameras, BLE stacks, exotic I/O are often only available for Linux or as vendor blob.
• Engineering talent. Every embedded developer knows Linux (Android, Yocto). BSD experience is scarce.
• Ecosystem. Docker®, K3s®, Balena, Home Assistant®: all centered on Linux.
• Update frameworks. RAUC, Mender, swupdate are only available for Linux.

Verdict: Technically NetBSD would be a serious candidate for a CRA compliant IoT product with a long lifespan. In practice, it fails because the entire SoC industry has standardized on Linux. Those who do it anyway gain a maintenance advantage but have to absorb the driver risk themselves.

If you’re building a product that has to run for 20+ years and you can carry the driver risk: look at NetBSD. Otherwise Linux/Yocto is the pragmatic path.

What does this mean in numbers?

A realistic estimate of maintenance effort over 5 years for a typical IoT product with around 10,000 devices in the field:

Platform	CVE patches per year (estimated)	Person days maintenance/year
FreeRTOS + mbedTLS + FreeRTOS+TCP	3–6	5–15
Zephyr (networking, BLE, MCUboot)	8–20	15–35
NetBSD / FreeBSD (embedded build)	5–15	20–40
Embedded Linux (Yocto, slim build)	15–30	30–60
Embedded Linux (with web server, browser)	50+	60–120

These numbers are rough. What matters: Embedded Linux is not free just because the OS is free. The CRA turns hidden maintenance effort into a legal obligation for the first time.

Practical recommendations

Choose FreeRTOS if your device does little and you want to pick every component yourself (e.g. sensor with BLE, simple industrial control). Lowest maintenance burden, but you build the update infrastructure yourself.

Choose Zephyr if you need networking, BLE or USB out of the box and the LTS cadence works for you. You get MCUboot for free but accept more CVEs than with pure FreeRTOS.

Choose Embedded Linux / Yocto if you need userland software (database, browser, complex network stacks), high volumes justify the infrastructure investment, and Yocto, RAUC and CVE monitoring are planned from day 1.

What to avoid: custom distros without CVE tracking, old kernel versions without LTS support, service daemons you don’t need.

What we offer

swissEmbedded has developed embedded systems since 2002, from lean FreeRTOS sensors to IoT gateways built on Yocto. For new projects we advise on platform appropriate architecture with CRA compliance in mind: update mechanism, SBOM strategy, CVE monitoring, lifecycle planning.

For existing systems, we analyze the maintenance footprint and identify where you can reduce the attack surface or automate the update process. We also help you build the response capability (monitoring, on call duty, reporting channels).

Keywords: FreeRTOS, Zephyr, Embedded Linux, Yocto, MCUboot, Cyber Resilience Act, FreeRTOS vs Linux embedded, CRA compliance consulting, embedded SBOM, CVE monitoring, IoT security Switzerland, embedded consulting Zurich