EU Cyber Resilience Act: Was bedeutet das für FreeRTOS vs. Embedded Linux?

Der EU Cyber Resilience Act (CRA) trat im Dezember 2024 in Kraft. Ab dem 11. Dezember 2027 dürfen Produkte mit digitalen Elementen, von der Smart Home Steuerung bis zum Industriegateway, in der EU nur noch verkauft werden, wenn sie die neuen Cybersicherheitsanforderungen erfüllen.

Für Hersteller von IoT Geräten heisst das: Sicherheitsupdates über den gesamten erwarteten Lebenszyklus (mindestens 5 Jahre), strukturierte Schwachstellenbehandlung, eine SBOM (Software Bill of Materials) und eine Konformitätsbewertung.

Was bedeutet das technisch? Wir vergleichen die zwei häufigsten IoT Plattformen aus Wartungssicht.

Die unterschätzten Meldefristen

Bevor wir zur Plattformwahl kommen: Der CRA verlangt nicht nur Updates, sondern auch nachweisbare Reaktion auf bekannte Schwachstellen. Konkret gelten enge Fristen, sobald eine aktiv ausgenutzte Schwachstelle entdeckt wird:

Frist	Was
24 Stunden	Early Warning an ENISA: aktiv ausgenutzte Schwachstelle melden
72 Stunden	Detaillierte Meldung an ENISA und das zuständige CSIRT
14 Tage	Abschlussbericht nach Verfügbarkeit der Gegenmassnahme
ohne unangemessene Verzögerung	Betroffene Nutzer informieren

Dazu kommen dauerhafte Pflichten: ein Single Point of Contact für Schwachstellenmeldungen, eine veröffentlichte Coordinated Vulnerability Disclosure Policy, dokumentierte Prozesse.

Das heisst praktisch: Du brauchst Bereitschaft. Wird eine kritische Lücke am Freitagabend öffentlich, läuft die 24h Frist über das Wochenende. Wer erst am Montagmorgen reagiert, hat sie längst gerissen.

FreeRTOS™: der minimalistische Klassiker

Aspekt	Bewertung
Codebasis	Sehr klein. Kernel plus eigene Treiber, oft unter 100 KB
Angriffsfläche	Sehr gering. Kein Userland, keine Shells, kein Netzwerkdienst by default
Bekannte CVEs (Stack)	Wenige; konzentriert auf die ausgewählten Bibliotheken: mbedTLS, FreeRTOS+TCP, FatFS
Updatemechanismus	Selbst zu implementieren: A/B Bootloader, signierte Firmware
Wartungsaufwand	Niedrig, wenige Abhängigkeiten, lange MCU Lebenszyklen
SBOM Erstellung	Einfach, fast alles im eigenen Repo

Vorteil unter CRA: Die Liste der Komponenten, die du tracken musst, ist überschaubar und du wählst sie selbst aus. Wenn eine neue CVE für mbedTLS kommt, weisst du innerhalb von Minuten, ob du betroffen bist.

Zur TCP/IP Wahl: Wir setzen auf FreeRTOS+TCP. Der Stack ist von Amazon übernommen, mehrfach auditiert und integriert sauber mit dem Scheduler (definierte Tasks, klare Memory Pools, kein global state Frickel). Die historischen CVEs aus 2018 sind seit Jahren geschlossen. lwIP ist eine Alternative, aber funktional und wartungstechnisch erkauft mit der Komplexität eines Stacks, der nicht auf RTOS Threading ausgelegt wurde.

Nachteil: Du musst die gesamte Updateinfrastruktur selbst bauen. Bootloader, Signaturverifikation, Schutz vor Rollback, OTA Server.

Zephyr®: das mittlere Gewicht

Zephyr wird oft mit FreeRTOS in einen Topf geworfen, ist aber deutlich grösser. Es bringt einen eigenen Netzwerkstack (IPv4/IPv6, TCP, UDP, CoAP, MQTT, LwM2M), Bluetooth Stack, USB Stack, OpenThread, hunderte Boardsupport-Pakete und ein integriertes Buildsystem mit.

Aspekt	Bewertung
Codebasis	Mittel. Mit Networking und BLE oft 500 KB bis mehrere MB
Angriffsfläche	Mittel. Aktive Netzwerkdienste je nach Konfiguration
Bekannte CVEs	Mehrere pro Release-Zyklus. Zephyr veröffentlicht regelmässig Security Advisories
Updatemechanismus	MCUboot ist integriert, A/B Slots und signierte Images out of the box
Wartungsaufwand	Mittel. Du folgst dem Zephyr LTS Branch und ziehst Patches nach
SBOM Erstellung	West unterstützt SPDX Export

Vorteil unter CRA: MCUboot und der Update-Pfad sind bereits Teil der Plattform. Der LTS Branch (alle 2 Jahre, 2.5 Jahre Support) gibt eine planbare Update-Kadenz.

Nachteil: Du erbst die Komplexität eines vollen Networking Stacks. Ein eingebauter MQTT Client den du nie benutzt, ist trotzdem CVE-Material.

Embedded Linux® (Yocto®, Buildroot, Debian): der grosse Bruder

Aspekt	Bewertung
Codebasis	Gross. Kernel, glibc, OpenSSL, BusyBox, Systemdienste (oft über 100 MB)
Angriffsfläche	Hoch. Shell, SSH, DBus, evtl. Webserver, Browserengine
Bekannte CVEs	Viele und ständig neue. Allein der Linux Kernel hat dutzende CVEs pro Monat
Updatemechanismus	Reife Tools verfügbar: RAUC, Mender, swupdate
Wartungsaufwand	Hoch. Yocto Rebuild bei jeder relevanten CVE, Backports, Tests
SBOM Erstellung	Tooling vorhanden. Yocto generiert SPDX SBOM automatisch, die cve-check Klasse meldet CVEs gegen den Build

Vorteil unter CRA: Yocto hat eingebaute CVE Tracker und SBOM Generierung. Das ist Gold wert. Die etablierten OTA Frameworks (RAUC, Mender) erfüllen die Anforderung “Updates während Lebenszyklus”.

Nachteil: Allein OpenSSL hatte in den letzten 5 Jahren mehrere kritische CVEs pro Jahr. Jede dieser CVEs erfordert: bauen, testen, signieren, OTA Rollout an alle deployten Geräte. Das skaliert nur, wenn die Infrastruktur von Anfang an steht.

Und wieso macht eigentlich niemand Embedded BSD?

Spannende Frage am Rande: NetBSD läuft auf so ziemlich allem, was einen Prozessor hat, vom VAX über ARM bis zum SH4. FreeBSD treibt jede zweite Firewall der Welt an (pfSense, OPNsense, JunOS). Und Apple hat das Potential schon Ende der 90er erkannt: macOS und iOS basieren bis heute auf Darwin, dessen Userland aus FreeBSD stammt. Die permissive BSD Lizenz erlaubte Apple, eigene proprietäre Schichten draufzusetzen, ohne den Kernel offenlegen zu müssen. Beide BSDs haben aus Sicht des CRA eigentlich gute Argumente:

Aspekt	Vorteil bei BSD
Lizenz	BSD/MIT statt GPL. Keine Verpflichtungen aus Copyleft, du musst keine Quellen weitergeben
Angriffsfläche	Schlanker als typische Linux Distributionen, weniger Kitchen Sink
Netzwerkstack	Historisch hervorragend, OpenBSD und PF sind State of the Art
Dokumentation	Konsistent, gepflegt, eine Quelle der Wahrheit (Handbook)
Umgang mit CVEs	Klare Sicherheitsmeldungen, schnelle Patches

Warum macht es trotzdem fast niemand im IoT?

• SoC Hersteller liefern Linux BSPs. Wenn NXP®, ST oder Allwinner einen neuen Chip bringen, gibt’s Yocto Layer und Kernelpatches, nicht NetBSD Treiber.
• Treiberlücken bei neuen Sensoren. Kameras, BLE Stacks, exotische I/O sind oft nur für Linux verfügbar oder als Vendor Blob.
• Engineering Talent. Jeder Embedded Entwickler kann Linux (Android, Yocto). Erfahrung mit BSD ist Mangelware.
• Ökosystem. Docker®, K3s®, Balena, Home Assistant® sind alle Linux zentrisch.
• Updateframeworks. RAUC, Mender, swupdate gibt’s nur für Linux.

Verdikt: Technisch wäre NetBSD ein ernsthafter Kandidat für ein konformes IoT Produkt mit langer Lebensdauer. In der Praxis scheitert es daran, dass die ganze SoC Industrie auf Linux normiert ist. Wer es trotzdem macht, hat einen Wartungsvorteil, muss aber das Treiberrisiko selbst tragen.

Wenn du ein Produkt baust, das 20+ Jahre laufen muss und du das Treiberrisiko stemmen kannst: schau dir NetBSD an. Sonst ist Linux mit Yocto der pragmatische Weg.

Was bedeutet das in Zahlen?

Eine realistische Schätzung des Wartungsaufwands über 5 Jahre für ein typisches IoT Produkt mit rund 10’000 Geräten im Feld:

Plattform	CVE Patches pro Jahr (geschätzt)	Personentage Wartung/Jahr
FreeRTOS + mbedTLS + FreeRTOS+TCP	3–6	5–15
Zephyr (Networking, BLE, MCUboot)	8–20	15–35
NetBSD oder FreeBSD (embedded Build)	5–15	20–40
Embedded Linux (Yocto, schlanker Build)	15–30	30–60
Embedded Linux (mit Webserver, Browser)	50+	60–120

Diese Zahlen sind grob. Entscheidend ist: Embedded Linux ist nicht kostenlos, nur weil das Betriebssystem gratis ist. Der CRA macht den versteckten Wartungsaufwand erstmals zur gesetzlichen Pflicht.

Praktische Empfehlungen

Wähle FreeRTOS, wenn dein Gerät wenig macht und du jede Komponente selbst auswählen willst (z.B. Sensor mit BLE, einfache Industriesteuerung). Geringster Wartungsaufwand, aber du baust die Updateinfrastruktur selbst.

Wähle Zephyr, wenn du Networking, BLE oder USB out of the box brauchst und die LTS Kadenz für dich passt. Du bekommst MCUboot gratis, akzeptierst aber mehr CVEs als bei reinem FreeRTOS.

Wähle Embedded Linux mit Yocto, wenn du Software im Userland brauchst (Datenbank, Browser, komplexe Netzwerkstacks), hohe Stückzahlen die Investition in Infrastruktur rechtfertigen, und Yocto, RAUC und CVE Monitoring von Tag 1 mitgeplant sind.

Was du vermeiden solltest: Custom Distributionen ohne CVE Tracking, alte Kernelversionen ohne LTS Support, Systemdienste, die du nicht brauchst.

Was wir anbieten

swissEmbedded entwickelt eingebettete Systeme seit 2002, von schlanken Sensoren auf FreeRTOS bis zu IoT Gateways auf Yocto. Bei neuen Projekten beraten wir Sie zur plattformgerechten Architektur mit Blick auf die Konformität nach CRA: Updatemechanismus, SBOM Strategie, CVE Monitoring, Lifecycle Planung.

Für bestehende Systeme analysieren wir die Wartung und identifizieren, wo Sie die Angriffsfläche reduzieren oder den Updateprozess automatisieren können. Auch beim Aufbau der Reaktionsfähigkeit (Monitoring, Bereitschaftsdienst, Meldewege) unterstützen wir Sie.

Schlüsselwörter: FreeRTOS, Zephyr, Embedded Linux, Yocto, MCUboot, Cyber Resilience Act, FreeRTOS oder Linux Embedded, CRA Konformität Beratung, SBOM Embedded, CVE Monitoring, IoT Sicherheit Schweiz, Embedded Consulting Zürich