CRA: Sicherheits-Updates über 5+ Jahre bereitstellen

Warum Update-Pflichten viele Hersteller kalt erwischen

Wer bisher mit kurzen Support-Fenstern gearbeitet hat — oder stillschweigend darauf gesetzt hat, dass Kunden einfach die neue Version kaufen — hat ein strukturelles Problem. Der Cyber Resilience Act (Verordnung EU 2024/2847) verpflichtet Hersteller vernetzter Produkte dazu, Sicherheitsupdates für mindestens fünf Jahre nach dem Inverkehrbringen bereitzustellen — kostenlos, separat von Funktionsupdates und in angemessener Zeit nach Bekanntwerden einer Schwachstelle.

Das klingt wie eine technische Anforderung. Ist es nicht. Tatsächlich ist es eine wirtschaftliche Entscheidung, die Produktplanung, Lizenzketten, Hardware-Auswahl und Geschäftsmodell direkt berührt.

Was der CRA-Text konkret sagt

Anhang I, Teil II, Nummer 10 des CRA formuliert die Update-Pflicht so:

„Sicherheitsupdates werden den Nutzern automatisch und innerhalb eines angemessenen Zeitraums nach ihrer Bereitstellung zur Verfügung gestellt, es sei denn, der Nutzer hat sich dagegen entschieden.”

Die drei Kernbegriffe sind entscheidend:

„Angemessener Zeitraum”: Der CRA definiert keine feste Stundenzahl. Die Praxis — und die Orientierung an bestehenden Branchenstandards — legt folgende Reaktionszeiten nahe (nicht im CRA-Text, aber als De-facto-Standard etabliert und von ENISA in Leitlinien referenziert):

• CVSS-Score ≥ 9.0 (kritisch): Update innerhalb von 24 Stunden
• CVSS-Score 7.0–8.9 (hoch): Update innerhalb von 72 Stunden
• CVSS-Score unter 7.0: Update innerhalb von 30 Tagen

Was hier viele falsch verstehen: 24 Stunden für ein kritisches Update bedeutet, dass Hersteller industrieller MQTT-Gateways oder embedded Heizungssteuerungen einen fertigen, getesteten Patch innerhalb eines einzigen Werktages ausliefern müssen. Ein IoT-Startup, das dafür keinen eingespielten Prozess hat, wird diese Frist strukturell reißen. Garantiert.

„Automatisch”: Das bedeutet nicht zwingend automatische Installation — aber automatische Verfügbarkeit. Produkte müssen technisch in der Lage sein, Updates anzubieten. Für Embedded-Geräte bedeutet das: OTA-Updatefähigkeit (Over-the-Air) ist keine Option, sondern eine Anforderung.

„Unterstützungszeitraum”: Artikel 13 Absatz 8 CRA legt fest, dass Hersteller den erwarteten Unterstützungszeitraum bei Markteinführung angeben müssen — und dass dieser mindestens fünf Jahre betragen soll, sofern die erwartete Nutzungsdauer nicht kürzer ist. Bei industriellen Steuerungssystemen, die zehn oder fünfzehn Jahre im Einsatz sind, kann der Unterstützungszeitraum entsprechend länger sein.

OTA-Updates als technische Voraussetzung

Ohne Over-the-Air-Updates lassen sich die CRA-Anforderungen in der Praxis nicht erfüllen. Das gilt für:

• IoT-Geräte ohne Updatekanal (klassische „Fire-and-forget”-Geräte)
• Embedded-Systeme mit Read-only-Firmware ohne Bootloader-Update-Mechanismus
• Industriekomponenten, bei denen Servicetechniker Updates bisher nur im Werk oder vor Ort einspielten

Ein Hersteller von industriellen Condition-Monitoring-Sensoren — typisches Industrie-4.0-Szenario, Gerät läuft zehn Jahre an der Maschine — kann seinen Kunden nicht zumuten, für jeden Security-Patch einen Serviceeinsatz zu buchen. OTA ist hier kein Feature. Es ist Compliance-Voraussetzung.

Die technischen Mindestanforderungen für einen CRA-konformen Update-Mechanismus sind:

1. Authentifizierung des Updates: Digitale Signatur, die der Hersteller kontrolliert; kein anonymes Pull-Modell
2. Integrität: Prüfsumme (SHA-256 oder besser) über das Update-Paket, Verifikation vor Installation
3. Rollback-Fähigkeit: Rückfallposition auf die letzte funktionierende Version, falls das Update fehlschlägt
4. Getrennte Kanäle: Sicherheits-Patches müssen unabhängig von Funktionsupdates ausgeliefert werden können — ein Nutzer, der automatische Funktionsupdates ablehnt, muss trotzdem Sicherheits-Patches erhalten

Dieser letzte Punkt hat konkrete Konsequenzen für die Update-Infrastruktur. Wer bisher einen einzigen Release-Kanal betrieben hat, braucht künftig mindestens zwei.

Die Herausforderungen für Embedded-Hersteller

Die 5-Jahres-Updatepflicht ist für viele Embedded-Hersteller das teuerste CRA-Requirement — weil es nicht nur Code betrifft, sondern Geschäftsmodelle.

Problem 1: Alte Prozessoren, keine aktuellen Compiler Viele Embedded-Produkte laufen auf Prozessoren, für die der Chip-Hersteller nach fünf bis sieben Jahren keinen Support mehr liefert. Stoppt der Chip-Hersteller die Security-Fixes für seinen BSP (Board Support Package), kann der Gerätehersteller keine sinnvollen Sicherheitsupdates mehr erstellen — auch wenn er wollte. Lösung: Bei der Hardware-Auswahl heute bereits den Langzeit-Support-Status des Prozessors prüfen und vertraglich sichern.

Problem 2: EOL-Drittkomponenten in der Software Eine Firmware besteht typischerweise aus dem eigenen Code plus Dutzenden Open-Source-Bibliotheken und Drittanbieter-SDKs. Sobald eine dieser Komponenten ihr End-of-Life erreicht, stoppt upstream die Sicherheits-Patches. Der Hersteller hat dann die Wahl: selbst patchen (teuer, riskant), alternative Komponente integrieren (teuer, zeitaufwändig), oder — faktisch — die CRA-Pflicht nicht mehr erfüllen.

Konkret: Ein IoT-Startup, das 2026 ein Smart-Building-Gateway auf den Markt bringt und dabei auf einen OpenSSL-1.x-basierten TLS-Stack setzt, hat spätestens 2028 ein EOL-Problem. OpenSSL 1.x ist seit September 2023 End-of-Life. Wer heute keine Migration auf OpenSSL 3.x plant, plant eine CRA-Verletzung für 2028. Das klingt weit weg. Ist es nicht.

Problem 3: Kein Update-Mechanismus vorhanden Produkte ohne OTA-Updates brauchen eine neue Infrastruktur: Update-Server, Signaturschlüssel-Management, Staging-Umgebung, Rollout-Strategie, Monitoring. Das ist kein Projekt für sechs Wochen.

Problem 4: Vertragliche Kette zu Drittherstellern Viele Gerätehersteller verbauen Firmware-Komponenten von Zulieferern. Der CRA macht den Inverkehrbringer verantwortlich — also Sie. Wenn Ihr Zulieferer in Jahr 4 aufhört, Patches zu liefern, ist das Ihr Problem. Was Hersteller oft übersehen: Genau diese Konstellation ist in Lieferverträgen heute noch nicht geregelt. Vertragliche Absicherung — SLA mit definiertem Patchzeitraum, Escrow-Regelungen für Quellcode — ist ab jetzt notwendig.

Ein Maschinenbauer, der embedded Steuerungsmodule von einem Zulieferer bezieht und diese unter eigenem Label verkauft, ist hier besonders exponiert. Er haftet nach CRA als Inverkehrbringer — und sitzt in der Zwickmühle, wenn der Zulieferer in Jahr 3 kein Budget mehr für Patches hat.

Strategie: LTS-Branches und separater Security-Patch-Kanal

Hersteller, die heute compliant werden wollen, sollten folgende Architekturentscheidungen treffen:

LTS-Branches (Long-Term Support): Pflegen Sie mindestens einen stabilen Produktionszweig, der ausschließlich Sicherheits-Patches erhält. Feature-Entwicklung läuft auf einem separaten Branch. Das reduziert das Regressionsrisiko bei Security-Patches erheblich und macht es leichter, Updates auch für ältere Produktgenerationen bereitzustellen.

Separater Security-Patch-Kanal: Trennen Sie Update-Kategorien technisch: Security-Patches (CVSS ≥ 4.0) rollen Sie über einen dedizierten, schnellen Kanal aus. Feature-Updates laufen über den regulären Release-Prozess. Nutzer, die Feature-Updates deaktiviert haben, empfangen trotzdem Security-Patches.

SBOM als lebendiges Dokument: Anhang I CRA fordert eine Software Bill of Materials. Behandeln Sie die SBOM nicht als einmaligen Snapshot, sondern als gepflegtes Artefakt: Jede neue Release aktualisiert die SBOM, jede SBOM wird auf bekannte CVEs geprüft. Tools wie Syft, Grype oder OWASP Dependency-Check lassen sich in CI-Pipelines integrieren.

Was viele CRA-Berater nicht sagen: Die SBOM ist kein Dokument, das Sie einmal erstellen und abheften. Sie ist der Frühwarnmechanismus, der Ihnen in Jahr 3 oder 4 zeigt, welche Komponente gerade EOL-kritisch wird — bevor Ihre Kunden davon lesen.

Schwachstellen-Monitoring als dauerhafter Prozess: Abonnieren Sie NVD (National Vulnerability Database), CERT-Bund, und die CVE-Feeds der Upstream-Projekte, die Sie nutzen. Richten Sie automatisierte Benachrichtigungen ein, wenn eine neue CVE eine Ihrer Abhängigkeiten betrifft. Nicht reaktiv auf öffentliche Berichte warten — proaktiv monitoren.

Was ENISA und die Marktüberwachung prüfen werden

Geprüft wird nicht nur, ob Sie Updates anbieten, sondern ob Ihr Update-Prozess dokumentiert und reproduzierbar ist. Konkret müssen Sie folgendes belegen können:

• Wie viele Tage zwischen Bekanntwerden einer CVE und Veröffentlichung des Patches lagen (Nachweis über Ticketsystem oder CVE-Advisory-Zeitstempel)
• Wie viele Nutzer das Update innerhalb welchen Zeitraums installiert haben (Update-Statistiken)
• Dass kritische Updates nicht zusammen mit optionalen Feature-Updates gebündelt wurden
• Dass der Signaturschlüssel für Updates sicher verwahrt wird (HSM oder vergleichbarer Schutz)

Konkret bedeutet das: Ein Maschinenbauer, der ein CPS-fähiges Steuerungsmodul (Produkt der Klasse I nach CRA-Anhang III) auf den Markt bringt, muss diese Nachweise strukturiert führen — nicht irgendwann, sondern ab dem ersten Tag nach Inverkehrbringen. Wer erst dann anfängt, Prozesse aufzubauen, wenn die Marktaufsicht klopft, hat ein Problem. Kein kleines.

Fazit

Fünf Jahre Sicherheitsupdates klingen nach einer kleinen technischen Pflicht. Ist es auch eine. Aber eine, die eine grundlegend andere Produktstrategie verlangt: längere Hardware-Support-Horizonte, OTA-Infrastruktur, getrennte Update-Kanäle, LTS-Branches und eine vertragliche Absicherung der gesamten Lieferkette.

Bis Dezember 2027 — dem Ende der CRA-Übergangsfrist — müssen diese Strukturen stehen. Wer heute ein Embedded-Produkt plant, das dann auf den Markt kommen soll, muss diese Anforderungen in die Systemarchitektur integrieren. Nachträgliches Einbauen eines Update-Mechanismus in ein laufendes Produkt kostet ein Vielfaches. Das ist keine Prognose — das ist die Erfahrung aus jedem größeren Retrofit-Projekt der letzten Jahre.

Quellen: EU-Verordnung 2024/2847 (CRA), Anhang I Teil II Nr. 10, Artikel 13 Abs. 8; ENISA Threat Landscape 2024; CVSS v3.1 Specification (FIRST.org); NVD National Vulnerability Database (NIST).

Keine Rechtsberatung. Indikative Einschätzung auf Basis öffentlich verfügbarer Informationen.