CRA & Updates: Welche Mechanismen sich für welche Produkte eignen

Ein Servicetechniker, der mit einem USB-Stick zur Maschine fährt, ein Installer, der manuell heruntergeladen und vor Ort eingespielt wird, oder eine Firmware, die per JTAG geflasht werden muss: Das sind keine Ausnahmen, sondern der Alltag in der Industrie. Vom klassischen Windows-Installer über OTA-Update-Frameworks (Over-the-Air) bis zum Firmware-Flasher gibt es viele Wege, Software auf ein Gerät zu bringen, und keiner davon ist automatisch CRA-konform.

Der Cyber Resilience Act (CRA) tritt ab 11.12.2027 in vollem Umfang in Kraft. Annex I, Teil II verpflichtet Hersteller dazu, Schwachstellen über die gesamte Supportdauer effektiv zu behandeln. Das klingt nach einem Prozess-Thema, ist aber zunächst eine technische Voraussetzung: Wer keine Update-Infrastruktur hat, kann keine Patches liefern. Dieser Artikel gibt dir einen Überblick über die gängigen Update-Mechanismen, ihre Sicherheitsanforderungen und wie du den richtigen für dein Produkt auswählst.

Der CRA und die Pflicht zur Updatefähigkeit

Annex I, Part II des CRA beschreibt die Anforderungen an das Vulnerability Handling. Im Kern geht es darum, Schwachstellen effektiv zu behandeln, und das setzt technisch voraus, dass du überhaupt die Möglichkeit hast, ein Update einzuspielen. Was das im Detail bedeutet, haben wir in unserem Artikel CRA umsetzen: Anforderungen an die Behandlung von Schwachstellen ausführlich beschrieben.

Wichtig ist dabei die Trennung von Feature-Updates und Security-Patches. Der CRA schreibt vor, dass Sicherheitsupdates kostenfrei bereitgestellt werden müssen. Wer Feature- und Security-Updates bündelt, kann neue Funktionen nicht mehr separat verkaufen, weil das Update für den Sicherheitsteil zwingend kostenlos sein muss. Daraus folgt oft eine technische und organisatorische Trennung: Security-Patches laufen auf einem eigenen Kanal, Feature-Updates auf einem anderen. Das hat Konsequenzen für dein Branching-Modell und deine Release-Strategie. Wie du das langfristig organisierst, beschreibt unser Artikel CRA & Long-Term-Support: Warum Git und Code allein nicht reichen.

Hersteller müssen darüber hinaus einen Support-Zeitraum explizit benennen. Wer sieben Jahre Support verspricht, verspricht auch sieben Jahre Update-Fähigkeit. Das bedeutet: Du triffst heute eine Architekturentscheidung, die dich für viele Jahre begleitet.

Windows-basierte Produkte: HMI, Desktop-Software und Windows IoT

Viele Maschinen-HMIs (HMI, Human-Machine Interface) und industrielle Desktop-Anwendungen laufen auf Windows. Dort gibt es eine strukturierende Grenze, die das Update-Management ordnet: App-Updates (deine eigene Software) und OS-Updates (das Betriebssystem selbst) sind zwei separate Aufgaben mit sehr unterschiedlichen Werkzeugen.

Für App-Updates gibt es zwei grundlegend unterschiedliche Ansätze, die nicht direkt vergleichbar sind: MSI/EXE-Installer über Toolsets wie WiX oder NSIS, und das modernere MSIX-Format.

WiX ist ein verbreitetes Framework für MSI-Installer: XML-basiert, Source-Control-freundlich, mit Burn-Bootstrapper für mehrstufige Installations- und Update-Bundles. Die Kommandozeilen-Tools sind ab v4 weiterhin open source; kommerzielle IDE-Erweiterungen wie das HeatWave-Plugin werden von FireGiant (dem Unternehmen hinter WiX) kostenpflichtig angeboten. Wer eine C#-Schnittstelle statt XML bevorzugt, kann auf WixSharp zurückgreifen. NSIS ist eine kompakte, vollständig freie Alternative für einfachere Szenarien ohne den Toolchain-Overhead von WiX.

MSIX ist ein dazu separates, moderneres Paketformat: Block-Level-Differenz-Updates über AppxBlockMap.xml laden nur geänderte 64-KB-Blöcke herunter, und alle Pakete müssen kryptografisch signiert sein. Deployment läuft über Microsoft Store, App Installer oder Intune. Für Air-Gap-Umgebungen ohne Intune-Infrastruktur ist MSIX aufwändiger als ein klassisches MSI: Das Signaturzertifikat muss auf jedem Zielgerät als vertrauenswürdig hinterlegt sein.

Bei Windows IoT Enterprise übernimmst du als Hersteller die Verantwortung für den OS-Patch-Rollout. Die Optionen reichen von Windows Update for Business (WUfB) mit zeitgesteuerten Update-Ringen für vernetzte Geräte, über WSUS für On-Premise-Umgebungen, bis hin zu Offline-Servicing per .msu-Pakete per USB für Air-Gapped-Systeme. Der LTSC-Kanal trennt Sicherheits- von Feature-Updates, was direkt zur CRA-Anforderung passt. Wichtig dabei: Teste Patches vor dem Rollout auf Kompatibilität mit Treibern und HMI-Software, und halte dokumentiert, welcher Patchstand auf welchem Gerät installiert ist.

OTA-Updates für IoT und Embedded Linux

Over-the-Air bedeutet: Remote-Update ohne physischen Zugriff auf das Gerät. Für vernetzte Produkte, Gateways und Embedded-Linux-Systeme ist das nicht nur Komfort, sondern oft die einzige skalierbare Option für eine wachsende Geräteflotte.

Mit Eclipse hawkBit steht eine Open-Source-OTA-Lösung unter EPL-2.0 (Eclipse Public License) zur Verfügung, die für große Flotten ausgelegt ist. hawkBit bietet drei APIs: eine Management API für Geräte- und Software-Repositories, eine DDI API für HTTP-Polling und eine DMF API über AMQP/RabbitMQ. Das Rollout Management unterstützt phased Rollouts mit konfigurierbaren Erfolgs- und Fehlerschwellen und ist damit gut geeignet, neue Firmware schrittweise auszurollen. hawkBit ist Java-basiert und für Self-Hosting konzipiert. Damit geht ein nicht trivialer Betriebsaufwand einher: PostgreSQL oder MySQL als Datenbank, RabbitMQ für die DMF-Integration und ein eigenes Deployment und Monitoring der Spring-Boot-Anwendung sind Voraussetzung. Für Teams ohne dedizierte Infrastrukturkapazität ist das eine erhebliche Hürde.

Mender deckt ein breiteres Spektrum ab: Full-Image-Updates, App-Updates, Container-Updates und Bootloader, auf Plattformen wie Yocto, Debian oder Zephyr RTOS. Das Projekt steht unter Apache-2.0-Lizenz; der Hosted Service ist laut Preisseite (Stand März 2026) bis 10 Geräten kostenlos, ab da wird ein kommerzielles Abonnement fällig.

RAUC (Robust Auto-Update Controller) ist der minimalistische, auf Embedded Linux spezialisierte Update-Client. Er ist unter LGPL-2.1 lizenziert, unterstützt A/B-System-Updates mit automatischem Rollback, signiert Bundles per X.509 und streamt Updates direkt per HTTPS ohne Zwischenspeicher. Build-System-Support für Yocto (meta-rauc), Buildroot und PTXdist ist vorhanden. RAUC wird oft in Kombination mit hawkBit als Backend betrieben. Zur Lizenz: LGPL-2.1 erlaubt den Einsatz in proprietären Produkten; in der gängigen Praxis läuft RAUC als eigenständiger Prozess, was die Lizenzfrage erheblich vereinfacht. Wer RAUC statisch in ein Firmware-Binary einbinden will, sollte die LGPL-2.1-Bedingungen vorher prüfen. Für Container-basierte IoT-Flotten auf Raspberry Pi oder Jetson-Boards bietet sich balena an, das Delta-Updates mit Dashboard-basiertem Fleet-Management kombiniert. balena ist ab einer bestimmten Gerätezahl kostenpflichtig; für kommerzielle Produkte mit wachsender Flotte sollte das Preismodell frühzeitig bewertet werden.

Firmware-Flasher und Programmiergeräte

Viele Microcontroller haben kein vollwertiges Betriebssystem und keinen IP-Stack. Moderne PLCs (z. B. Siemens S7-1200/1500, Allen-Bradley ControlLogix) bringen zwar Ethernet-Schnittstellen mit sich und sprechen PROFINET, EtherNet/IP oder Modbus TCP, aber ein allgemeines OTA-Framework wie Mender oder hawkBit greift trotzdem nicht: Updates laufen über herstellerspezifische Engineering-Tools (TIA Portal, Studio 5000) oder proprietäre Protokolle, nicht über offene HTTP-basierte Kanäle. Die Werkzeuge unterscheiden sich je nach Einsatzort klar in zwei Kategorien: Entwicklungs- und Produktions-Programmer versus Feld-Update-Kanäle.

MCUBoot ist ein sicherer Bootloader für Echtzeit-Betriebssysteme (RTOS, Real-Time Operating System) wie Zephyr oder das Nordic SDK. Er unterstützt Image-Signierung per ECDSA (P-256 und P-384 sind der aktuelle Standard) sowie RSA, das in neueren Versionen als Legacy gilt und für neue Designs nicht mehr empfohlen wird. MCUBoot kennt A/B-Slots nativ und schützt mit Sequenznummern vor Downgrade-Angriffen. Der STM32 UART-Bootloader und USB DFU nach der DFU-1.1-Spezifikation sind standardisierte Protokolle ohne proprietäre Tool-Abhängigkeit. Das Open-Source-Tool dfu-util kann DFU-Updates skriptgesteuert und damit CI/CD-integriert ausführen.

Debug-Programmer wie SEGGER J-Link, ST-LINK oder CMSIS-DAP (über JTAG/SWD, standardisierte Hardware-Debug-Schnittstellen) sind primär für Entwicklung und Serienproduktion gedacht und als Feld-Update-Kanal nicht geeignet. Wer Geräte in der Produktion mit Flash-Inhalten ausliefert, setzt Gang-Programmer ein (Geräte zur parallelen Serienprogrammierung, z. B. XELTEK oder Elnec), die viele Chips parallel programmieren. Im Feld braucht dieselbe MCU dann einen separaten Update-Kanal: typischerweise UART/DFU oder ein proprietäres Protokoll vom übergeordneten Gateway.

Air-Gapped-Umgebungen und Service-Einsätze

Der Servicetechniker mit dem USB-Stick aus dem Intro ist kein Randfall. Viele industrielle Systeme (CNC-Maschinen, Prüfstände, Anlagen in Produktionshallen ohne dauerhaften Netzwerkzugang) werden genau so aktualisiert. OTA-Infrastruktur ist dort keine Option, und das ändert sich mit dem CRA nicht. Was sich ändert, ist die Anforderung, dass auch dieser Kanal sicher und nachvollziehbar sein muss.

Die Signierungsanforderungen sind dabei dieselben wie beim OTA-Kanal. Ein RAUC-Bundle, das über USB eingespielt wird, muss genauso kryptografisch signiert sein wie ein Remote-Update. RAUC und Mender unterstützen beide manuelle Installationen ohne Backend-Verbindung: bei RAUC mit rauc install /media/usb/firmware-2.1.3.raucb, bei Mender mit mender install /media/usb/firmware-2.1.3.mender. Die Signaturprüfung läuft lokal auf dem Gerät mit dem eingebetteten Public Key des Herstellers, ohne Server-Verbindung.

Für Windows-basierte Systeme ohne Internetzugang sind .msu-Pakete für OS-Patches und MSI/MSIX für App-Updates der etablierte Weg. Beide können auf einem signierten USB-Stick oder einem schreibgeschützten Netzlaufwerk bereitgestellt werden. Ein definierter Workflow für den Servicetechniker ist dabei wichtig: SHA-256-Hash des Pakets vor Ort prüfen, Installation durchführen, installierten Versionsstand im Asset-Management dokumentieren.

Der Audit-Trail ist auch bei manuellen Updates CRA-relevant: Datum, Gerät, installierte Version und Verantwortlicher müssen festgehalten sein. Systeme wie Mender können den Update-Status lokal halten und ihn beim nächsten Netzwerkkontakt an den zentralen Server melden, was den Gap zwischen Offline-Update und zentraler Dokumentation schließt.

Die CIA-Triade für Update-Mechanismen

Ein Update-Kanal ist nur so sicher wie seine schwächste Stelle. Das klassische CIA-Modell (Confidentiality, Integrity, Availability) hilft dabei, die richtigen Maßnahmen dem richtigen Schutzziel zuzuordnen.

Confidentiality betrifft den Schutz des Firmware-Inhalts vor unbefugtem Auslesen, primär ein IP-Schutzthema. RAUC unterstützt asymmetrische Verschlüsselung pro Empfänger, Mender bietet Encryption at Rest. Transportschutz via TLS/HTTPS ist Grundvoraussetzung; HTTP-Endpunkte für Updates sind keine akzeptable Option.

Integrity ist die wichtigste Eigenschaft: Nur autorisierte, unveränderte Updates dürfen eingespielt werden. Kryptografische Signaturen (X.509, ECDSA, RSA) auf Pakete und Images, Hash-Prüfung (SHA-256) nach dem Download und Secure Boot auf dem Gerät (UEFI Secure Boot, ARM TrustZone oder MCUBoot) sind die Basis. Ebenso wichtig ist Downgrade-Schutz: Sequenznummern in Firmware-Images verhindern, dass ein Angreifer auf eine ältere, bekannt anfällige Version zurückrollen kann.

Signing-Keys gehören nicht auf den Build-Agenten, sondern in ein HSM (Hardware Security Module) oder Azure Key Vault. Für Dev, Staging und Production solltest du dabei getrennte Key-Sets verwenden.

Für Windows-Pakete (MSI, MSIX, EXE) bietet Azure Trusted Signing einen managed Authenticode-Dienst: Der Build-Agent übergibt das Paket an die API, ohne direkten Zugriff auf den Private Key. Das Zertifikat kommt dabei aus Microsofts PKI (Microsoft ID Verified), nicht aus einer eigenen CA — für Authenticode-Signaturen ist das kein Problem, weil Windows dieser Kette systemweit vertraut. Für Szenarien, in denen du eine eigene Root-CA benötigst (z. B. interne Verteilung ohne Microsoft-Kette), ist stattdessen Azure Key Vault mit einem dedizierten Signing-Key der passende Ansatz.

Für Embedded-Linux-Bundles (RAUC, Mender) ist Azure Trusted Signing nicht nutzbar: Diese Systeme verwenden eine eigene X.509-PKI, deren Root-Zertifikat fest im Gerät eingebettet ist. Das Signing lässt sich per PKCS#11 (ein Krypto-API-Standard für HSM-Integration) gegen ein HSM auslagern — entweder ein physisches Gerät oder ein Cloud-HSM wie Azure Dedicated HSM. In beiden Fällen empfiehlt sich ein separater CI-Job für das Signing mit eigenem Service-Principal und minimalem Zugriffsbereich.

Availability bedeutet: Das Update darf das Gerät nicht unbrauchbar machen. A/B-Update-Partitionen mit automatischem Rollback (RAUC, Mender) sorgen dafür, dass bei einem fehlgeschlagenen Update das letzte funktionierende Image wiederhergestellt wird. Phased Rollouts mit hawkBit oder Mender geben dir die Möglichkeit, Probleme frühzeitig zu erkennen, bevor sie die gesamte installierte Basis betreffen.

Ein praktikabler Ausgangspunkt: Starte mit 1–5 % der Geräte, beobachte 24 bis 48 Stunden und definiere als Abbruchbedingung, wenn ein Gerät nach dem Update nicht mehr erreichbar ist oder einen definierten Fehlercode zurückmeldet. Erst wenn die Fehlerquote unter dem Schwellenwert bleibt und die Beobachtungsphase abgeschlossen ist, geht der nächste Ring frei. Watchdog-Integration stellt sicher, dass ein Gerät, das nach dem Update nicht sauber bootet, selbsttätig zurückrollt.

Auswahl des richtigen Mechanismus

Die Wahl des Update-Mechanismus hängt von vier Faktoren ab: Plattform, Konnektivität, Flottengröße und Anforderungen an den Compliance-Nachweis.

Bei Windows-Systemen ist MSI/MSIX für App-Updates die natürliche Wahl, kombiniert mit WUfB oder WSUS für OS-Patches. Bei Embedded Linux kommen RAUC und Mender in Frage, häufig mit hawkBit als Backend für Flottenmanagement. Bei Microcontrollern ohne OS bleiben MCUBoot und DFU als robuste, standardisierte Optionen.

Die Konnektivität entscheidet darüber, ob ein OTA-Kanal überhaupt möglich ist. Air-Gapped-Umgebungen erfordern USB- oder Netzlaufwerk-basierte Updates mit signierten Bundles ohne externen Server. Für gelegentlich vernetzte Geräte bieten hawkBit und Mender Offline-Queuing. Bei dauerhaft vernetzten Geräten sind automatische Updates mit phased Rollout die effizienteste Lösung.

Hybride Szenarien sind in der Industrie weit verbreitet: Ein Edge-Gateway bekommt ein OTA-Update, und der angeschlossene Microcontroller wird über ein proprietäres Protokoll vom Gateway aus aktualisiert. Das muss von Anfang an mitgeplant werden. Wer heute keinen Feld-Update-Kanal für die MCU einplant, rüstet ihn später mit deutlich höherem Aufwand nach.

Für den Compliance-Nachweis brauchst du einen Audit-Trail, der dokumentiert, welche Version auf welchem Gerät zu welchem Zeitpunkt installiert wurde. hawkBit und Mender bieten das out of the box. Für Windows-basierte Systeme lässt sich das mit Intune und Microsoft Endpoint Analytics abdecken.

Ein häufig übersehener Aspekt: Jedes Security-Update verändert den Komponentenbestand deines Produkts. Eine aktualisierte SBOM (Software Bill of Materials) muss bei jedem sicherheitsrelevanten Release mit erstellt werden. Wie du SBOMs automatisiert erzeugst und in den Release-Prozess einbettest, findest du in unserem Artikel Governance: Software Bill of Materials (SBOM).

Updates als First-Class Citizen

Updatefähigkeit ist keine Funktion, die man problemlos nachträglich einbauen kann. Natürlich lässt sie sich nachrüsten, aber der Aufwand ist erheblich höher als eine frühzeitige Architekturentscheidung, und in manchen Embedded-Systemen ohne Bootloader-Support ist ein Retrofit schlicht nicht wirtschaftlich. Wer am Ende eines Projekts feststellt, dass der Installationsprozess nur für Erstinstallationen ausgelegt war, hat ein grundsätzliches Architekturproblem. Die Entscheidung für einen Update-Mechanismus gehört in die frühe Designphase, zusammen mit Fragen zur Plattformwahl, Netzwerkarchitektur und dem Sicherheitskonzept.

Hersteller bestehender Produkte stehen vor einer anderen Frage. Nicht jede ältere Architektur lässt sich ohne erheblichen Aufwand auf einen CRA-konformen Update-Kanal nachrüsten. Bei Microcontrollern ohne Bootloader-Support oder proprietären RTOS-Systemen kann ein Retrofit aufwändig sein. Hier lohnt eine realistische Einschätzung: Wird das Gerät aktiv weiterentwickelt und soll es nach 2027 noch in Verkehr gebracht werden? Wenn nicht, ist ein geplanter Produktauslauf vor dem CRA-Stichtag wirtschaftlich oft der direktere Weg. Die Frage, ob ein Produkt ohne Updatefähigkeit überhaupt zulässig in Verkehr gebracht werden kann, ist dabei weniger eindeutig beantwortet als oft angenommen.

Die Rechtslage ist komplex. Annex I, Teil 1, §2c fordert, dass Schwachstellen durch Sicherheitsaktualisierungen behoben werden können. Die Einleitung dieses Absatzes schränkt jedoch mit soweit zutreffend ein und verweist auf die Risikoanalyse nach Artikel 13 Absatz 2. Das VDMA-FAQ zum CRA bestätigt: Hersteller sind nicht verpflichtet, jede Schwachstelle mit einem Patch zu beheben. Ob und wie eine Schwachstelle behoben wird, richtet sich nach der Risikobewertung. Abhilfe kann je nach Ergebnis auch in Form von Advisories, Konfigurationsempfehlungen oder dem Entfernen ungenutzter Komponenten in der nächsten regulären Release erfolgen. Damit ist es rechtlich denkbar, dass eine fundierte Risikoanalyse ergibt, dass ein bestimmtes Produkt auch ohne Updatefähigkeit CRA-konform betrieben werden kann.

Diese Einschätzung hat eine klare Bedingung: Die Entscheidung gegen einen Update-Kanal muss aktiv begründet und in der Risikoanalyse dokumentiert sein. Wer diese Entscheidung nicht dokumentiert und später eine kritische Schwachstelle nicht schließen kann, riskiert behördliche Maßnahmen nach Artikel 54 des CRA, bis hin zu Rücknahme oder Rückruf. Ob das Risikoprofil eines konkreten Produkts diese Entscheidung trägt, ist eine rechtliche Frage, die juristischen Rat erfordert.

Für alle Produkte mit Update-Kanal gilt daneben: Die Sicherheit des Kanals selbst ist genauso kritisch wie die Sicherheit der Firmware. Signaturen, Transportschutz, Rollback-Mechanismen und Audit-Trails sind keine optionalen Extras, sondern Grundvoraussetzungen.

Als nächsten Schritt solltest du deinen gewählten Mechanismus in der technischen Dokumentation festhalten. Was du dort konkret beschreiben musst, haben wir in unserem Artikel Technische Dokumentation nach CRA zusammengestellt.

Wie gehst du die Updatefähigkeit in deinen Projekten an? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.