Die Verantwortung endet nicht mit dem Release
Im Dezember 2021 erschütterte die Log4Shell-Schwachstelle die IT-Welt. Eine kritische Lücke in der weit verbreiteten Java-Logging-Bibliothek Log4j ermöglichte Remote Code Execution auf Millionen von Systemen. Die Hersteller betroffener Produkte standen vor einer gewaltigen Herausforderung: Welche ihrer Produkte waren betroffen? Wie schnell konnten sie Patches bereitstellen? Wie erreichten sie alle Kunden? Unternehmen mit funktionierendem Schwachstellenmanagement und aktueller SBOM konnten innerhalb von Stunden reagieren. Andere brauchten Wochen, um überhaupt den Umfang des Problems zu erfassen.
Zur Einordnung: Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die horizontale Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen festlegt. Vom Smart-Home-Gerät über industrielle Steuerungen bis zur Unternehmenssoftware muss künftig jedes Produkt Mindeststandards für Cybersicherheit erfüllen. Die vorherigen Teile dieser Serie behandelten den rechtlichen Rahmen und die Security-by-Design-Anforderungen in der Entwicklung. Dieser Teil konzentriert sich auf die Betriebsphase.
Der CRA macht genau diese Fähigkeit zur Pflicht. Hersteller müssen während des gesamten Produktlebenszyklus in der Lage sein, Schwachstellen zu erkennen, zu bewerten und zeitnah zu beheben. Die Verantwortung endet nicht mit dem Release. Sie beginnt dort erst richtig. Dieser Teil behandelt die betrieblichen Pflichten nach Inverkehrbringen: den Support-Zeitraum, das Schwachstellenmanagement, die Meldepflichten und die praktische Umsetzung eines Vulnerability-Response-Prozesses.
Der Support-Zeitraum
Der CRA verpflichtet Hersteller in Artikel 13, während eines definierten Zeitraums Sicherheitsupdates bereitzustellen. Dieser Support-Zeitraum muss sich an der erwarteten Nutzungsdauer des Produkts orientieren und mindestens fünf Jahre betragen. Nur wenn eine kürzere Nutzungsdauer nachvollziehbar begründet werden kann, ist eine kürzere Supportdauer zulässig. Diese Regelung ist eine der weitreichendsten des CRA: Sie bindet Ressourcen über Jahre und erfordert langfristige Planung.
Wie wird die Supportdauer bestimmt?
Die erwartete Nutzungsdauer hängt von der Produktkategorie und dem Einsatzkontext ab. Ein Smartphone wird typischerweise drei bis fünf Jahre genutzt, bevor es ersetzt wird. Eine Industriesteuerung in einer Produktionsanlage kann zwanzig Jahre oder länger im Einsatz sein. Ein Smart-Home-Gerät liegt irgendwo dazwischen. Der CRA verlangt eine realistische Einschätzung dieser Nutzungsdauer und eine entsprechende Festlegung des Support-Zeitraums.
Die Begründung für die gewählte Supportdauer muss dokumentiert werden und ist Teil der technischen Dokumentation. Marktüberwachungsbehörden können diese Begründung prüfen. Eine pauschale Festlegung auf fünf Jahre ohne Berücksichtigung der tatsächlichen Produkterwartungen ist nicht zulässig. Für Produkte mit langer Lebensdauer wie industrielle Steuerungen, medizinische Geräte oder Infrastrukturkomponenten können zehn Jahre oder mehr angemessen sein.
Branchenspezifische Erwartungen
Die Erwartungen unterscheiden sich erheblich zwischen Branchen. Im Consumer-Bereich haben sich die Smartphone-Hersteller inzwischen auf fünf bis sieben Jahre Support eingependelt, getrieben durch regulatorischen Druck und Kundenwünsche. Apple unterstützt iPhones typischerweise sechs bis sieben Jahre mit iOS-Updates. Google bietet für die Pixel-8-Serie und neuere Modelle sieben Jahre OS- und Sicherheitsupdates. Diese Benchmarks werden zur Erwartungshaltung für andere Consumer-Elektronik.
Im Industriebereich sind die Erwartungen traditionell länger. Siemens unterstützt SIMATIC-Steuerungen über zehn Jahre und mehr. Maschinenbauer erwarten, dass Komponenten während der gesamten Maschinenlebensdauer gepflegt werden. Für kritische Infrastruktur wie Energieversorgung oder Verkehrssteuerung können noch längere Zeiträume relevant sein. Der CRA zwingt Hersteller, diese Erwartungen explizit zu adressieren.
Pflichten während des Support-Zeitraums
Während des Support-Zeitraums treffen den Hersteller umfangreiche Pflichten. Er muss Schwachstellen systematisch überwachen und identifizieren. Dies erfordert kontinuierliches Monitoring von Schwachstellendatenbanken, Sicherheitsadvisories und Meldungen. Die SBOM ist dabei essentiell: Sie ermöglicht den automatisierten Abgleich mit neuen CVEs. Ohne aktuelle SBOM ist ein effektives Schwachstellenmonitoring kaum möglich.
Erkannte Sicherheitslücken müssen zeitnah behoben werden. Der CRA spezifiziert keine festen Fristen für Patches, fordert aber angemessene Reaktionszeiten. Bei kritischen Schwachstellen mit aktiver Ausnutzung sind Tage, nicht Wochen der Maßstab. Sicherheitsupdates müssen kostenlos bereitgestellt werden, zumindest für die Behebung von Schwachstellen. Nutzer müssen über verfügbare Updates informiert werden. Ein Kontaktkanal für Schwachstellenmeldungen muss existieren und publiziert werden.
Kommunikation der Supportdauer
Die gewählte Supportdauer muss bei Inverkehrbringen kommuniziert werden. Anhang II des CRA fordert, dass der Support-Zeitraum auf dem Produkt selbst oder auf der Verpackung angegeben wird. Zusätzlich muss er in der Benutzerinformation genannt werden. Diese Transparenz ermöglicht Käufern, die Supportdauer in ihre Kaufentscheidung einzubeziehen. Produkte mit längerer Supportzusage können zum Differenzierungsmerkmal werden.
Sicherheitsupdates
Der CRA stellt konkrete Anforderungen an Sicherheitsupdates. Sie müssen bereitgestellt werden und dabei sicher, zuverlässig und für Nutzer praktikabel sein. Ein Update, das selbst Schwachstellen enthält oder Systeme destabilisiert, verfehlt seinen Zweck. Die Anforderungen betreffen sowohl den Inhalt der Updates als auch die Mechanismen ihrer Verteilung.
Anforderungen an Updates
Updates müssen zeitnah erfolgen. Bei kritischen Schwachstellen bedeutet das so schnell wie technisch möglich. Die Praxis zeigt, dass führende Unternehmen kritische Patches innerhalb von Tagen bereitstellen können. Microsoft veröffentlicht bei Zero-Day-Exploits Out-of-Band-Patches außerhalb des regulären Patch-Tuesday-Zyklus. Apple reagiert bei aktiv ausgenutzten Schwachstellen mit Rapid Security Responses. Diese Reaktionszeiten werden zum Maßstab.
Sicherheitsupdates müssen kostenlos sein. Der CRA lässt hier keinen Spielraum: Für die Behebung von Schwachstellen dürfen keine Gebühren erhoben werden. Dies gilt unabhängig davon, ob das Produkt selbst kostenlos oder kostenpflichtig war. Funktionale Updates können kostenpflichtig sein, Sicherheitspatches nicht. Updates müssen digital signiert sein, um Manipulation auszuschließen. Die Signatur muss vor Installation verifiziert werden können.
Sichere Update-Mechanismen
Der CRA fordert sichere Update-Mechanismen in Anhang I. Die Verteilung muss über sichere Kanäle erfolgen: HTTPS mit TLS 1.2 oder höher, signierte Pakete, verifizierbare Quellen. Der Update-Client im Gerät muss die Authentizität des Updates prüfen, bevor er es installiert. Certificate Pinning kann zusätzlichen Schutz gegen Man-in-the-Middle-Angriffe bieten.
Updates dürfen keine neuen Schwachstellen einführen. Das klingt selbstverständlich, ist aber in der Praxis eine Herausforderung. Updates sollten vor Auslieferung denselben Sicherheitstests unterzogen werden wie das ursprüngliche Produkt. Regressionstests müssen sicherstellen, dass bestehende Sicherheitsfunktionen nicht beeinträchtigt werden. Ein Rollback-Mechanismus sollte vorhanden sein, falls Updates unerwartete Probleme verursachen.
Automatische versus manuelle Updates
Automatische Sicherheitsupdates sind aus Sicherheitsperspektive ideal: Sie werden ohne Nutzerinteraktion installiert und schließen Schwachstellen zeitnah. Der CRA empfiehlt automatische Updates als Standardeinstellung. Die Realität ist komplexer. In Industrieumgebungen können unkontrollierte Updates Produktionsprozesse stören. Ein Update, das zur falschen Zeit eine SPS neu startet, kann erhebliche Schäden verursachen.
Der CRA berücksichtigt diese Realität. Nutzer müssen die Möglichkeit haben, automatische Updates zu deaktivieren. In diesem Fall ist ein Benachrichtigungsmechanismus Pflicht: Nutzer müssen über verfügbare Updates informiert werden und diese manuell installieren können. Für industrielle Umgebungen empfehlen sich gestufte Update-Strategien: automatisch für Test- und Entwicklungssysteme, kontrolliert für Produktionssysteme, mit Möglichkeit zur Verzögerung für Validierung und Freigabe.
Updates für Offline-Geräte
Nicht alle Produkte haben Internetverbindung. Industriesteuerungen in Air-Gapped-Netzwerken, Embedded-Systeme in geschlossenen Umgebungen, Geräte in Mobilfunk-Schattenzonen: Für diese Produkte müssen alternative Update-Wege vorgesehen werden. USB-basierte Updates, lokale Update-Server oder manuelle Firmware-Installation über Service-Interfaces sind gängige Lösungen. Der Update-Prozess muss dokumentiert und für den Nutzer durchführbar sein.
Schwachstellenmanagement
Schwachstellenmanagement ist ein kontinuierlicher Prozess, der weit über das gelegentliche Patchen hinausgeht. Er umfasst die systematische Identifikation, Bewertung, Behandlung und Kommunikation von Schwachstellen. Der CRA macht dies in Artikel 13 zur verbindlichen Pflicht für alle Hersteller. Ein effektives Vulnerability-Management-Programm ist die Grundlage für CRA-Compliance im Betrieb.
Schwachstellen identifizieren
Schwachstellen können aus verschiedenen Quellen bekannt werden. Interne Sicherheitstests und Code Reviews finden Probleme vor der Auslieferung. Nach dem Release kommen weitere Quellen hinzu: externe Sicherheitsforscher, die Schwachstellen melden, Berichte von Nutzern, öffentliche Schwachstellendatenbanken wie die National Vulnerability Database (NVD) oder die GitHub Advisory Database, Sicherheitsadvisories von Komponentenherstellern.
Ein systematischer Prozess muss diese Quellen überwachen. Automatisierte Tools können die NVD und andere Datenbanken kontinuierlich scannen und Alerts bei neuen CVEs generieren. Die SBOM ist dabei essentiell: Sie ermöglicht den schnellen Abgleich zwischen den im Produkt verwendeten Komponenten und neu veröffentlichten Schwachstellen. Ohne aktuelle SBOM ist ein effektives Schwachstellenmonitoring kaum möglich. Tools wie OWASP Dependency-Track oder Snyk automatisieren diesen Abgleich.
Schwachstellen bewerten
Nicht jede Schwachstelle ist gleich kritisch. Eine differenzierte Bewertung ist erforderlich, um Ressourcen sinnvoll einzusetzen. Der CVSS-Score (Common Vulnerability Scoring System) ist ein Ausgangspunkt: Er bewertet Schwachstellen auf einer Skala von 0 bis 10 basierend auf technischen Eigenschaften wie Angriffskomplexität, erforderliche Privilegien und Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.
Der CVSS-Score allein reicht aber nicht. Er muss in den Kontext des spezifischen Produkts gestellt werden. Eine kritische Schwachstelle (CVSS 9+) in einer Bibliothek, die im Produkt nur in einer nicht erreichbaren Funktion verwendet wird, hat geringere praktische Relevanz als eine mittlere Schwachstelle (CVSS 5-6) in einer internetexponierten API. Die CISA KEV (Known Exploited Vulnerabilities) Liste zeigt, welche Schwachstellen aktiv ausgenutzt werden und daher höchste Priorität haben.
Schwachstellen behandeln
Die Behandlung kann verschiedene Formen annehmen, abhängig von Schweregrad, Ausnutzbarkeit und verfügbaren Ressourcen. Die bevorzugte Behandlung ist ein Patch: Die Schwachstelle wird im Code behoben und ein Update bereitgestellt. Bei kritischen Schwachstellen sollte dies innerhalb von Tagen erfolgen. Für weniger kritische Probleme kann die Behebung im nächsten regulären Release erfolgen.
Wenn ein Patch nicht sofort möglich ist, können temporäre Maßnahmen helfen. Workarounds dokumentieren, wie Nutzer sich schützen können, bis ein Fix verfügbar ist: Deaktivierung betroffener Funktionen, Netzwerksegmentierung, zusätzliche Firewall-Regeln. In extremen Fällen kann die Deaktivierung der betroffenen Funktion oder sogar die Rücknahme des Produkts vom Markt erforderlich sein. Alle Maßnahmen müssen dokumentiert und ihre Wirksamkeit verifiziert werden.
Kontakt für Schwachstellenmeldungen
Der CRA fordert einen öffentlich zugänglichen Kontaktkanal für Schwachstellenmeldungen. Nutzer und Sicherheitsforscher müssen die Möglichkeit haben, potenzielle Sicherheitsprobleme zu melden. Die Kontaktinformationen müssen auf dem Produkt oder in der Dokumentation angegeben sein. Der RFC 9116 Standard security.txt bietet einen etablierten Mechanismus: Eine Textdatei unter /.well-known/security.txt enthält Kontaktinformationen, PGP-Schlüssel und Disclosure-Policy.
Meldungen müssen zeitnah bearbeitet werden. Ein Acknowledgement innerhalb von 24-48 Stunden zeigt dem Melder, dass seine Meldung angekommen ist. Regelmäßige Statusupdates halten den Melder informiert. Die Einrichtung eines dedizierten Product Security Incident Response Teams (PSIRT) ist für größere Hersteller empfehlenswert. Kleinere Unternehmen können mit definierten Prozessen und klaren Verantwortlichkeiten arbeiten.
Meldepflichten
Eine der schärfsten Neuerungen des CRA sind die Meldepflichten bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen. Diese Pflichten treten bereits am 11. September 2026 in Kraft, also vor der vollständigen Anwendung der anderen CRA-Anforderungen am 11. Dezember 2027. Hersteller müssen ihre Meldeprozesse entsprechend früh etablieren.
Was muss gemeldet werden?
Meldepflichtig sind zwei Kategorien von Ereignissen. Erstens: aktiv ausgenutzte Schwachstellen. Das bedeutet, dass Exploits bekannt sind und in der Praxis verwendet werden, um Systeme anzugreifen. Es reicht nicht, dass eine Schwachstelle theoretisch ausnutzbar ist. Es muss konkrete Hinweise auf tatsächliche Ausnutzung geben. Die Einträge in der CISA KEV-Liste sind ein Indikator für aktive Ausnutzung.
Zweitens: schwerwiegende Sicherheitsvorfälle, die die Cybersicherheit des Produkts beeinträchtigen. Das umfasst erfolgreiche Angriffe auf die Produktinfrastruktur (Update-Server, Signing-Keys), Kompromittierung der Lieferkette, oder Vorfälle, die große Nutzerzahlen betreffen. Nicht meldepflichtig sind theoretische Schwachstellen ohne bekannte Ausnutzung, geringfügige Vorfälle ohne Auswirkung auf Nutzer, oder Schwachstellen, die vor Ausnutzung behoben wurden.
Welche Fristen gelten für Meldungen?
Die Meldepflichten sind zeitlich gestaffelt und strikt. Innerhalb von 24 Stunden nach Kenntnisnahme muss eine Frühwarnung erfolgen. Diese enthält grundlegende Informationen: Angaben zum Hersteller, Produktidentifikation und betroffene Versionen, allgemeine Beschreibung der Schwachstelle oder des Vorfalls, erste Einschätzung der Schwere und der potenziellen Auswirkungen.
Innerhalb von 72 Stunden müssen detailliertere Informationen folgen. Diese umfassen: technische Details zur Art der Schwachstelle, bekannte Angriffsvektoren und Ausnutzungsmethoden, betroffene Komponenten und Funktionen, vorläufige Empfehlungen für Schutzmaßnahmen. Nach Verfügbarkeit eines Patches oder einer finalen Lösung ist innerhalb von 14 Tagen ein Abschlussbericht fällig, der die Ursache, die ergriffenen Maßnahmen und Empfehlungen zur Vermeidung ähnlicher Vorfälle dokumentiert.
Die ENISA-Meldeplattform
Die Meldung erfolgt über eine zentrale Plattform, die von ENISA (der EU-Agentur für Cybersicherheit) betrieben wird. Diese Plattform soll bis September 2026 einsatzbereit sein. ENISA arbeitet an der technischen Umsetzung und an Schnittstellen zu nationalen Strukturen. Von der zentralen Plattform werden die Informationen an die zuständigen nationalen CSIRTs (Computer Security Incident Response Teams) weitergeleitet.
In Deutschland ist das BSI über CERT-Bund zuständig für die Entgegennahme und Verarbeitung von Meldungen. Die Plattform soll maschinenlesbare Schnittstellen (APIs) bieten, um die Integration in bestehende Vulnerability-Management-Systeme zu ermöglichen. Größere Hersteller werden ihre internen Systeme anbinden können, statt manuelle Webformulare auszufüllen. Die genauen technischen Spezifikationen werden durch Durchführungsverordnungen der EU-Kommission festgelegt.
Wie unterscheiden sich die Ansätze international?
Der CRA ist nicht das einzige Regelwerk für Vulnerability Management. In den USA hat Executive Order 14028 (Mai 2021) ähnliche Anforderungen für Bundesbehörden und deren Lieferanten etabliert. CISA (Cybersecurity and Infrastructure Security Agency) betreibt mit dem Known Exploited Vulnerabilities Catalog eine öffentliche Liste aktiv ausgenutzter Schwachstellen, die Bundesbehörden innerhalb definierter Fristen patchen müssen. Die CISA Vulnerability Disclosure Policy fordert von Bundesbehörden einen dokumentierten CVD-Prozess.
Der wesentliche Unterschied: Die US-Anforderungen gelten primär für den öffentlichen Sektor und dessen Lieferanten. Der CRA hingegen erfasst alle Produkte mit digitalen Elementen auf dem EU-Markt, unabhängig vom Käufer. Hersteller, die beide Märkte bedienen, sollten ihre Prozesse so gestalten, dass sie sowohl CRA als auch US-Anforderungen erfüllen. Die strengeren CRA-Meldepflichten (24 Stunden) setzen dabei den Maßstab.
Was droht bei Verstößen?
Die Meldepflichten sind sanktionsbewehrt. Verstöße gegen die Meldepflichten nach Artikel 14 können mit Geldbußen von bis zu 15 Millionen Euro oder 2,5% des weltweiten Jahresumsatzes geahndet werden, je nachdem welcher Betrag höher ist. Dies entspricht der höchsten Sanktionsstufe des CRA. Die 24-Stunden-Frist ist bewusst kurz gewählt, um schnelle Reaktionen zu erzwingen. Hersteller, die keine funktionierenden Prozesse haben, werden Schwierigkeiten haben, diese Frist einzuhalten.
Koordinierte Offenlegung
Der CRA fördert Coordinated Vulnerability Disclosure (CVD) als Best Practice für den Umgang mit extern gemeldeten Schwachstellen. CVD ist ein Prozess, bei dem Sicherheitsforscher Schwachstellen zunächst vertraulich an den Hersteller melden, bevor sie öffentlich werden. Der Hersteller erhält Zeit, einen Patch zu entwickeln. Die Öffentlichkeit erfährt von der Schwachstelle idealerweise erst, wenn ein Fix verfügbar ist.
Der CVD-Prozess
Ein typischer CVD-Prozess läuft in mehreren Phasen ab. Der Sicherheitsforscher entdeckt eine Schwachstelle und meldet sie über den publizierten Kontaktkanal an den Hersteller. Der Hersteller bestätigt den Empfang und beginnt mit der Analyse. Nach Verifikation der Schwachstelle wird ein Zeitplan für die Behebung vereinbart. Typischerweise werden 90 Tage als angemessene Frist für die Entwicklung eines Patches betrachtet.
Während der Behebungsphase bleibt die Schwachstelle vertraulich. Der Forscher veröffentlicht keine Details. Der Hersteller entwickelt und testet den Patch. Nach Bereitstellung des Patches erfolgt eine koordinierte Veröffentlichung: Der Hersteller publiziert ein Security Advisory, der Forscher kann seine Analyse veröffentlichen, Nutzer können patchen. Dieses Vorgehen minimiert das Fenster, in dem Angreifer eine bekannte, aber ungepatchte Schwachstelle ausnutzen können.
Praktisches Beispiel: Ein Smart-Lock-Hersteller
Ein Sicherheitsforscher findet eine Schwachstelle in der Cloud-API eines Smart-Lock-Herstellers: Durch Manipulation von API-Parametern kann er Schlösser anderer Nutzer entsperren. Er kontaktiert den Hersteller über die auf der Website publizierte security.txt-Adresse. Der Hersteller bestätigt innerhalb von 24 Stunden den Empfang und beginnt mit der Analyse. Nach Verifikation wird ein 60-Tage-Zeitplan vereinbart.
Der Hersteller behebt die Schwachstelle serverseitig. Kein Firmware-Update für die Schlösser ist erforderlich, da das Problem in der Cloud-API lag. Nach 45 Tagen ist der Fix deployed und getestet. Der Hersteller veröffentlicht ein Security Advisory. Der Forscher erhält eine Danksagung und darf seine Analyse publizieren. Das Ergebnis: Die Schwachstelle wurde behoben, ohne dass Angreifer sie ausnutzen konnten. Der Hersteller zeigt Reife im Umgang mit Sicherheitsproblemen.
Bug-Bounty-Programme
Viele Unternehmen gehen über passives Warten auf Meldungen hinaus und incentivieren die aktive Suche nach Schwachstellen durch Bug-Bounty-Programme. Sicherheitsforscher erhalten finanzielle Belohnungen für gemeldete Schwachstellen, gestaffelt nach Schweregrad. Programme wie HackerOne oder Bugcrowd bieten Plattformen für die Verwaltung solcher Programme. Auch selbst gehostete Programme sind möglich.
Bug-Bounty-Programme sind kein Ersatz für interne Sicherheitstests, aber eine wertvolle Ergänzung. Sie bringen die Perspektive externer Angreifer ein und motivieren talentierte Sicherheitsforscher, Zeit in die Analyse zu investieren. Die Kosten sind in der Regel überschaubar im Vergleich zu den potenziellen Schäden durch nicht entdeckte Schwachstellen. Für Produkte mit hohem Sicherheitsbedarf ist ein Bug-Bounty-Programm empfehlenswert.
Nach dem Support-Zeitraum
Was passiert, wenn der Support-Zeitraum endet? Der CRA gibt Empfehlungen und einige Pflichten für diese Phase, aber weniger strikt als während des aktiven Supports. Hersteller sollten das Ende des Supports sorgfältig planen und kommunizieren. Für Nutzer ist es wichtig zu verstehen, welche Risiken die weitere Nutzung eines nicht mehr unterstützten Produkts birgt.
Rechtzeitige Kommunikation
Nutzer müssen rechtzeitig über das bevorstehende Ende des Supports informiert werden. Mindestens sechs Monate vor Ablauf sollte eine Benachrichtigung erfolgen. Diese Information sollte klar kommunizieren, ab welchem Datum keine Sicherheitsupdates mehr bereitgestellt werden, welche Risiken die weitere Nutzung birgt, welche Alternativen existieren (Nachfolgeprodukt, Konkurrenzprodukte), und welche Maßnahmen Nutzer ergreifen können, um Risiken zu minimieren.
Open-Source-Option
Der CRA empfiehlt in Erwägungsgrund 76, nach Ende des Supports den Quellcode zu veröffentlichen. Das ermöglicht der Community, das Produkt weiter zu pflegen. Sicherheitsforscher können Schwachstellen finden und Patches entwickeln. Engagierte Nutzer können das Produkt am Leben halten. Es ist keine Pflicht, aber ein Zeichen guter Praxis und kann positive Öffentlichkeitswirkung haben.
Vor einer Quellcode-Veröffentlichung müssen Hersteller allerdings sorgfältig prüfen: Sind alle Lizenzen der verwendeten Komponenten kompatibel? Enthält der Code proprietäre Algorithmen oder Geschäftsgeheimnisse? Sind alle hartkodierten Credentials und API-Keys entfernt? Eine schlecht vorbereitete Veröffentlichung kann mehr Schaden als Nutzen anrichten. Die Vorbereitung der Open-Source-Veröffentlichung sollte Teil des End-of-Life-Prozesses sein.
Wie lange müssen Dokumente aufbewahrt werden?
Sicherheitsupdates und technische Dokumentation müssen mindestens zehn Jahre nach Inverkehrbringen archiviert werden. Diese Pflicht gilt auch über den Support-Zeitraum hinaus. Nutzer, die ältere Versionen benötigen, sollen Zugriff behalten. Die Dokumentation muss Marktüberwachungsbehörden auf Anfrage zur Verfügung gestellt werden können. Ein strukturiertes Archivierungssystem ist erforderlich.
Herausforderungen in der Praxis
Die betrieblichen Pflichten des CRA stellen Hersteller vor erhebliche Herausforderungen. Fünf Jahre Supportpflicht, 24-Stunden-Meldepflicht, kontinuierliches Schwachstellenmonitoring: Das erfordert Ressourcen, Prozesse und Expertise, die nicht in jedem Unternehmen vorhanden sind. Die Herausforderungen unterscheiden sich nach Unternehmensgröße und Produktart.
Ressourcenbedarf für KMU
Für kleine und mittlere Unternehmen ist der Ressourcenbedarf eine besondere Herausforderung. Ein dediziertes PSIRT mit 24/7-Bereitschaft für die Meldepflichten ist für ein Unternehmen mit 20 Mitarbeitern nicht realistisch. Die Kosten für kontinuierliches Schwachstellenmonitoring, Patch-Entwicklung und Update-Infrastruktur können erheblich sein. KMU müssen pragmatische Lösungen finden.
Mögliche Ansätze umfassen: Outsourcing von PSIRT-Funktionen an spezialisierte Dienstleister, Nutzung von SaaS-Tools für automatisiertes Schwachstellenmonitoring, Fokussierung auf wenige Produkte statt breites Portfolio, Kooperation mit anderen Herstellern für gemeinsame Sicherheitsressourcen. Die EU hat angekündigt, KMU-spezifische Guidance und möglicherweise Förderprogramme bereitzustellen.
Legacy-Produkte und technische Schulden
Viele Hersteller haben Produkte im Markt, die vor dem CRA entwickelt wurden. Diese Legacy-Produkte erfüllen oft nicht die Anforderungen an sichere Update-Mechanismen. Fehlende SBOM, proprietäre Update-Protokolle, veraltete Kryptografie: Die Nachrüstung dieser Produkte kann aufwändig bis unmöglich sein. Hersteller müssen entscheiden, welche Produkte modernisiert werden und welche auslaufen.
Koordination mit Zulieferern
Komplexe Produkte enthalten Komponenten von Zulieferern. Ein Smart-Home-Gateway könnte ein Betriebssystem von Anbieter A, einen Bluetooth-Stack von Anbieter B und eine Cloud-Plattform von Anbieter C verwenden. Eine Schwachstelle in einer dieser Komponenten erfordert die Koordination mit dem Zulieferer. Der Hersteller bleibt verantwortlich, aber die Reaktionszeit hängt vom Zulieferer ab.
Vertragliche Regelungen mit Zulieferern werden wichtiger: SLAs für Patch-Bereitstellung, Meldepflichten bei Schwachstellen, Bereitstellung von SBOMs. Hersteller sollten ihre Lieferantenbeziehungen im Licht der CRA-Anforderungen überprüfen und gegebenenfalls nachverhandeln. Die Wahl zuverlässiger Zulieferer wird zum Wettbewerbsfaktor.
Fazit und Ausblick
Das Schwachstellenmanagement ist keine lästige Pflicht, sondern essentiell für die Sicherheit der Nutzer und den Ruf des Herstellers. Der CRA formalisiert Praktiken, die verantwortungsvolle Hersteller bereits anwenden: systematisches Monitoring, schnelle Reaktion, transparente Kommunikation. Die Meldepflichten sind strikt, aber machbar. Wer ein funktionierendes Vulnerability-Management hat, kann die 24-Stunden-Frist einhalten. Die betrieblichen Pflichten sind dabei kein isolierter Bereich, sondern Teil eines durchgängigen Operating Models: Was in der Entwicklung an Security-by-Design angelegt wurde, muss im Betrieb gepflegt und für die Nachweisführung dokumentiert werden.
Ich halte die Meldepflichten für den wirkungsvollsten Hebel des CRA. Sie zwingen Hersteller, die Reaktionsfähigkeit auf Schwachstellen ernst zu nehmen. Ein Unternehmen, das 24 Stunden braucht, um überhaupt zu erkennen, dass ein Problem existiert, hat ein grundlegendes Problem in seinen Prozessen. Die Vorbereitung auf diese Anforderungen sollte Priorität haben, auch weil die Meldepflichten früher greifen als die anderen CRA-Anforderungen.
Der Support-Zeitraum von mindestens fünf Jahren ist eine signifikante Verpflichtung. Sie erfordert langfristige Planung und Ressourcen. Aber sie schafft auch Vertrauen bei Kunden und Differenzierung im Markt. Wer heute mit der CRA-Vorbereitung beginnt, sollte drei Prioritäten setzen: Erstens die Etablierung eines Vulnerability-Management-Prozesses mit klaren Verantwortlichkeiten. Zweitens die Einrichtung eines Kontaktkanals für Schwachstellenmeldungen. Drittens die Vorbereitung auf die ENISA-Meldepflichten ab September 2026. Im letzten Teil der Serie betrachten wir die Nachweisführung: Wie weist man Konformität nach, welche Dokumentation ist erforderlich, und wie läuft das Konformitätsbewertungsverfahren ab?
Quellenverzeichnis
[1] Europäische Union: Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act). Amtsblatt der Europäischen Union L 2024/2847. Insbesondere Artikel 13 (Pflichten der Hersteller), Artikel 14 (Meldepflichten), Anhang I (Wesentliche Anforderungen) und Anhang II (Informationen und Anleitungen für Nutzer).
[2] ENISA: Good Practices for Security of Internet of Things in the context of Smart Manufacturing. November 2018. https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot Leitfaden für IoT-Sicherheit und Vulnerability Management in industriellen Umgebungen.
[3] FIRST: Common Vulnerability Scoring System (CVSS) Version 4.0. https://www.first.org/cvss/ Standard für die Bewertung von Schwachstellen.
[4] NIST: National Vulnerability Database (NVD). https://nvd.nist.gov/ Zentrale Datenbank für CVE-Einträge und CVSS-Scores.
[5] CISA: Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog Liste aktiv ausgenutzter Schwachstellen.
[6] IETF RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. https://www.rfc-editor.org/rfc/rfc9116 Standard für security.txt.
[7] ISO/IEC 29147:2018: Information technology — Security techniques — Vulnerability disclosure. Internationaler Standard für Coordinated Vulnerability Disclosure.
[8] BSI: Technische Richtlinie TR-03183 Cyber-Resilienz-Anforderungen. https://www.bsi.bund.de/ Deutsche Umsetzungsempfehlungen zum CRA, insbesondere zu SBOM und Vulnerability Management.
[9] The White House: Executive Order 14028 on Improving the Nation's Cybersecurity. Mai 2021. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ US-amerikanische Anforderungen an Software-Lieferketten und Vulnerability Disclosure für Bundesbehörden.