Der am Montag veröffentlichte Leitfaden der EU-Kommission erläutert auf gut 80 Seiten, wie der Cyber Resilience Act auszulegen ist. Er beantwortet nach Angaben der Kommission zentrale Fragen aus der Industrie und soll Betroffenen helfen, die Vorgaben rechtssicher umzusetzen. Behandelt werden unter anderem die Abgrenzung betroffener Produkte, wesentliche Software-Updates, Support-Zeiträume sowie Risikoanalysen und Meldepflichten. Der Text richtet sich ausdrücklich auch an Startups sowie kleine und mittlere Unternehmen.
Für Errichter und andere Hersteller digitaler Produkte ist damit vor allem wichtig, dass die Verordnung nicht nur abstrakte Pflichten formuliert, sondern praktische Einordnungshilfen liefert. Der Leitfaden enthält dazu zahlreiche Praxisbeispiele und Anwendungsszenarien. Nach unserem Verständnis von The Circle geht es genau um solche Klarheit in technischen und organisatorischen Fragen.
Der CRA ist bereits seit Dezember 2024 in Kraft. Er schreibt EU-weit einheitliche Mindestanforderungen an die Cybersicherheit digitaler Produkte über deren gesamten Lebenszyklus vor. Die ersten Meldepflichten werden am 11. September 2026 wirksam. Die vollständige Umsetzung durch Hersteller ist ab 11. Dezember 2027 erforderlich.
Die Kommission sieht den Leitfaden als Teil einer Entlastungsagenda. EU-Kommissionsvizepräsidentin Henna Virkkunen sagte, Unternehmen sollten ihre neuen Pflichten fristgerecht und rechtssicher umsetzen können. Zugleich verweist die Kommission darauf, dass der CRA durch leistungsfähigere KI-Modelle mit Cyberfähigkeiten an Bedeutung gewinnt. Für die Praxis heißt das: Die Zeit bis zu den ersten Pflichten ist begrenzt, aber die Auslegung soll vorab klarer werden.
Ein zentraler Punkt ist die Frage, welche Produkte überhaupt unter den CRA fallen. Der Leitfaden erläutert außerdem, wann eine Änderung an einem Produkt als „wesentlich“ gilt. Updates, die nur Schwachstellen schließen oder das bestehende Sicherheitsniveau erhalten oder verbessern, lösen in der Regel kein neues Konformitätsbewertungsverfahren aus.
Anders sieht es aus, wenn neue Funktionen das Risikoprofil eines Produkts verändern oder zusätzliche Angriffsflächen schaffen. Bei Reparaturen schafft der Text ebenfalls Klarheit: Werden nur identische Ersatzteile geliefert, gilt dies nicht als erneutes Inverkehrbringen des Produkts. Für Open Source unterscheidet die Kommission zudem zwischen frei verfügbarer Software und Software, die im Rahmen einer kommerziellen Tätigkeit auf den Markt gebracht wird.
Der Text ordnet mehrere Themenbereiche ein, die für die Umsetzung relevant sind:
Besonders betont die Kommission dabei die Lage kleiner und mittlerer Unternehmen. Die Orientierungshilfe soll Unklarheiten beseitigen und unnötigen Verwaltungsaufwand vermeiden. Damit richtet sie sich nicht nur an Hersteller, sondern auch an nationale Marktaufsichtsbehörden, für die der Leitfaden in der Praxis vermutlich maßgeblich sein dürfte.
Großen Raum nimmt freie und quelloffene Software ein. Frei verfügbare Open-Source-Software fällt demnach grundsätzlich nicht unter den CRA, solange sie nicht im Rahmen einer kommerziellen Tätigkeit auf den Markt gebracht wird. Wer Open-Source-Software verkauft, kostenpflichtige Enterprise-Versionen anbietet oder über ein Programm andere Dienste monetarisiert, gilt hingegen als Hersteller im CRA-Sinne.
Die Kommission nennt weitere Fälle: Wenn Nutzer personenbezogene Daten zu anderen Zwecken als für Sicherheit oder Interoperabilität bereitstellen müssen oder Spenden faktisch Voraussetzung für den Zugang zur Software oder zu essenziellen Updates sind, kann ebenfalls eine kommerzielle Tätigkeit vorliegen. Dagegen begründen freiwillige Zuwendungen sowie öffentliche Förder- oder Sponsorengelder allein noch keine solche Tätigkeit. Auch kostenpflichtige Beratungs-, Schulungs- oder Supportangebote führen nicht automatisch zum CRA, solange die Software selbst frei verfügbar bleibt.
Der Leitfaden unterscheidet ausdrücklich zwischen Projektzuständigen und Zulieferern. Wer lediglich Fehler behebt oder neue Funktionen einreicht, trägt demnach grundsätzlich keine Verantwortung nach dem CRA. Anders ist es bei Personen oder Organisationen, die ein Projekt veröffentlichen und die Kontrolle über Releases, Fahrpläne und die Steuerung ausüben.
Auch die Rolle der sogenannten Stewards wird präzisiert. Dazu können Stiftungen oder andere Organisationen gehören, die Open-Source-Projekte dauerhaft organisatorisch oder technisch unterstützen, ohne sie selbst zu vermarkten. Je nach Intensität der Einbindung können für Stewards auch Meldepflichten für Sicherheitsvorfälle oder ausgenutzte Schwachstellen gelten. Wer nur Community-Arbeit übernimmt, hat deutlich geringere Verpflichtungen als Organisationen, die Infrastruktur betreiben oder aktiv an Entwicklung und Sicherheitsmanagement mitwirken.
Der Leitfaden ist rechtlich nicht bindend. Er dürfte aber für Hersteller und nationale Behörden wichtig werden, wenn der CRA in der Praxis ausgelegt wird. Für Unternehmen soll er helfen, Pflichten rechtssicher und mit weniger Verwaltungsaufwand umzusetzen.
Für die Zielgruppe der Errichter und Hersteller technischer Lösungen ist vor allem die Trennung zwischen reinen Sicherheitsupdates, wesentlichen Änderungen und kommerzieller Nutzung von Open Source relevant. Wer diese Punkte sauber einordnet, kann die kommenden Pflichten gezielter vorbereiten. Wenn Sie den Austausch mit anderen Betrieben suchen, finden Sie bei The Circle Veranstaltungen einen passenden Rahmen.
Der Leitfaden schafft vor den ersten Meldepflichten mehr Orientierung, ersetzt aber keine verbindliche Rechtsauslegung. Entscheidend bleibt, wie Hersteller, Entwickler und Aufsichtsbehörden die Regeln in der Praxis anwenden. Offen ist damit vor allem, wie stark sich die nun beschriebene Linie in der laufenden Umsetzung durchsetzen wird.
Wenn Sie sich mit anderen inhabergeführten Errichterbetrieben über solche Fragen austauschen wollen, kann The Circle of Security Professionals der richtige Rahmen sein. Das Netzwerk ist auf einen kleinen Kreis von maximal 60 passenden Unternehmen ausgelegt und richtet sich an Betriebe, die Kooperation, technische Tiefe und Austausch auf Augenhöhe suchen.
Quelle: Heise