Blog

Cyber Resilience Act

Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) legt erstmals horizontale, für nahezu alle Produktkategorien geltende Cybersicherheitsanforderungen fest. Sie gelten für Hard- und Software mit einer direkten oder indirekten Datenverbindung zu einem Gerät oder Netzwerk – „Produkte mit digitalen Elementen” – über deren gesamten Lebenszyklus.

Anders als frühere IT-Sicherheitsregeln, die meist einzelne Sektoren wie Energie oder Finanzwesen betrafen, adressiert der CRA das Produkt selbst: von der Entwicklung über den Verkauf bis zum Ende des zugesicherten Support-Zeitraums.

Zusammenfassung

Der CRA wurde am 20. November 2024 im Amtsblatt veröffentlicht und trat am 10. Dezember 2024 in Kraft. Er verpflichtet Hersteller zu Security-by-Design, zu einem Schwachstellenmanagement über die gesamte Produktlebensdauer und zur CE-Kennzeichnung als Nachweis der Konformität.

Software-KI-Systeme fallen grundsätzlich unter den weiten CRA-Produktbegriff, sofern sie als eigenständiges Produkt oder als für ein Produkt wesentliche Ferndatenverarbeitung in Verkehr gebracht werden.

Für die KI-Verordnung ist vor allem Artikel 42 Absatz 3 relevant: Er verweist ausdrücklich auf den CRA. Hochrisiko-KI-Systeme, die unter die Verordnung (EU) 2024/2847 fallen und die Voraussetzungen aus Artikel 12 Absatz 1 CRA erfüllen, gelten damit als konform mit den Cybersicherheitsanforderungen aus Artikel 15 KI-VO.

Der CRA ist dabei nicht als Harmonisierungsrechtsvorschrift in Anhang I Abschnitt A der KI-VO gelistet – anders als etwa die Medizinprodukte- oder Maschinenverordnung –, sondern über diesen eigenständigen Verweis in Artikel 42 mit der KI-VO verzahnt.

Der CRA selbst regelt die Kehrseite dieser Verzahnung in seinem Artikel 12. Erfüllt ein Hochrisiko-KI-System, das zugleich CRA-Produkt ist, dessen wesentliche Cybersicherheitsanforderungen und weist es das in der EU-Konformitätserklärung nach, gilt damit zugleich die Cybersicherheitsanforderung aus Artikel 15 der KI-VO als erfüllt.

Abgrenzung

Allgemeine Produktcybersicherheit (CRA) – regelt technische Schutzziele wie sichere Voreinstellungen, Schwachstellenbehebung und Meldung an Behörden für praktisch jedes vernetzte Produkt, unabhängig davon, ob KI im Spiel ist.

Cybersicherheitspflichten der KI-VO (Artikel 15) – verlangen speziell von Hochrisiko-KI-Systemen Widerstandsfähigkeit gegen KI-spezifische Angriffsvektoren wie Data Poisoning, adversariale Beispiele oder Modell-Vergiftung. Beide Pflichten können sich bei ein und demselben System überschneiden; Artikel 42 Absatz 3 KI-VO und Artikel 12 CRA regeln, wie ein einziger Nachweis für beide genügt, statt paralleler Prüfverfahren.

Begriffsgeschichte

Die Kommission legte den ersten Entwurf im September 2022 vor, nachdem wiederholte Sicherheitsvorfälle bei vernetzten Consumer-Geräten – von Baby-Kameras bis Router – gezeigt hatten, dass es für Software und smarte Hardware keine dem Maschinen- oder Medizinprodukterecht vergleichbare horizontale Sicherheitsregulierung gab.

Vorbild war das seit Jahrzehnten etablierte New-Legislative-Framework-Modell der EU-Produktharmonisierung, wie es auch die Konformitätsbewertung anderer Produktkategorien prägt.

Der Gesetzgebungsprozess war vor allem wegen der Auswirkungen auf Open-Source-Software umstritten. Kritiker warnten, dass ehrenamtliche Entwickler:innen ohne kommerzielles Interesse faktisch in die Haftung für kommerzielle Weiterverwertungen ihrer Software gerieten.

Das Europäische Parlament und der Rat einigten sich Ende 2023 auf eine Ausnahme für unentgeltlich bereitgestellte Open-Source-Software sowie eine eigene, abgeschwächte Pflichtenkategorie für „Open-Source-Software-Stewards” – juristische Personen, die ein Open-Source-Projekt systematisch unterstützen, ohne es selbst zu vermarkten. Die endgültige Fassung wurde am 10. Oktober 2024 vom Rat verabschiedet und am 20. November 2024 im Amtsblatt veröffentlicht.

Methodische Grundlagen

Kernpflichten des CRA für Hersteller sind Security-by-Design und -Default bereits in Entwicklung und Konzeption, ein dokumentiertes Schwachstellenmanagement über den gesamten angegebenen Support-Zeitraum und eine Software Bill of Materials (SBOM) zur Nachverfolgbarkeit von Komponenten. Hinzu kommt, nach bestandener Konformitätsbewertung, die CE-Kennzeichnung als sichtbarer Nachweis.

Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen Hersteller der europäischen Cybersicherheitsagentur ENISA und den zuständigen nationalen Behörden binnen 24 Stunden als Frühwarnung und binnen 72 Stunden mit Details melden.

Der Zeitplan staffelt sich in drei Stufen: Seit dem 11. Dezember 2024 gelten bereits die Vorschriften zur Benennung notifizierter Stellen.

Ab dem 11. September 2026 – also nur wenige Tage nach Erstellung dieses Artikels – greifen die Melde­pflichten für aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle nach Artikel 14. Die übrigen Kernpflichten, insbesondere CE-Kennzeichnung und vollständige Konformitätsbewertung, werden erst ab dem 11. Dezember 2027 verbindlich – Hersteller haben damit eine gestaffelte Übergangsfrist von insgesamt drei Jahren nach Inkrafttreten.

Anwendungsfelder

Der praktisch wichtigste KI-Berührungspunkt des CRA liegt in der beschriebenen Schnittstelle zu Artikel 42 Absatz 3 der KI-VO.

Ein Hochrisiko-KI-System, das als eigenständiges Produkt mit digitalen Elementen in Verkehr gebracht wird – etwa eine KI-gestützte Zugangskontroll-Software oder ein KI-Modul in medizinischer Diagnosesoftware –, muss grundsätzlich beide Regelwerke gleichzeitig erfüllen. Das sind die KI-spezifischen Anforderungen aus KI-Verordnung Titel III Abschnitt 2 und die produktweiten Cybersicherheitsanforderungen des CRA.

Artikel 42 Absatz 3 KI-VO erlaubt hier ausdrücklich, den CRA-Konformitätsnachweis als Cybersicherheitsnachweis der KI-VO zu übernehmen, statt ihn ein zweites Mal eigenständig zu erbringen.

Der CRA verstärkt diese Vereinfachung durch die Konformitätsvermutung in seinem Artikel 12. Erfüllt und dokumentiert ein Hochrisiko-KI-System die wesentlichen CRA-Cybersicherheitsanforderungen aus Anhang I und legt es eine entsprechende EU-Konformitätserklärung vor, gilt die Cybersicherheitsanforderung aus Artikel 15 KI-VO – soweit von der Erklärung abgedeckt – automatisch als erfüllt.

Für Anbieter bedeutet das: keine zwei getrennten Cybersicherheitsnachweise für dasselbe System, sondern ein gemeinsames Prüfverfahren, das in der Regel die für Hochrisiko-KI ohnehin zuständige Marktüberwachungsbehörde überwacht.

Eine zentrale Abgrenzungsfrage bleibt jedoch offen, welche KI-Komponenten überhaupt als CRA-„Produkt” zählen. Der CRA erfasst Software, die als eigenständiges Produkt vertrieben wird, sowie Fernddatenverarbeitung („remote data processing”), sofern sie für die Kernfunktion eines Produkts wesentlich ist und vom Hersteller selbst oder unter dessen Aufsicht entwickelt wurde – etwa das Cloud-Backend einer smarten Kamera.

Reine Software-as-a-Service-Angebote ohne ein zugehöriges physisches oder installierbares Produkt fallen dagegen grundsätzlich nicht unter den CRA. Ob ein als API bereitgestelltes KI-Modell diese Schwelle überschreitet, hängt von der konkreten technischen und vertraglichen Ausgestaltung ab und ist bislang nicht abschließend geklärt.

Generative KI-Modelle mit allgemeinem Verwendungszweck (General Purpose AI, GPAI) als solche – losgelöst von einem konkreten Produkt – werden vom CRA nicht eigenständig erfasst; ihre spezifische Regulierung bleibt Sache der KI-VO selbst.

Kontroversen und Kritik

Die heftigste Debatte im Gesetzgebungsprozess drehte sich um Open-Source-Software. Verbände wie die Open Source Business Alliance und die Linux Foundation warnten, der ursprüngliche Entwurf könnte einen „Chilling Effect” auf freiwillige Open-Source-Entwicklung auslösen, weil die Abgrenzung zwischen kommerzieller und nichtkommerzieller Bereitstellung unscharf blieb.

Die finale Fassung nahm unentgeltlich bereitgestellte Open-Source-Software von den Kernpflichten aus und schuf mit dem „Open-Source-Software-Steward” eine eigene, abgeschwächte Pflichtenkategorie für Organisationen, die Projekte systematisch unterstützen, ohne sie selbst zu vermarkten – Kritiker:innen halten die Definition weiterhin für zu unbestimmt.

Für den KI-Bereich ist die zentrale Streitfrage, wie klar sich CRA-„Produkt” und KI-VO-„System” tatsächlich trennen lassen. Weder Artikel 42 Absatz 3 KI-VO noch Artikel 12 CRA definieren abschließend, wann ein cloudbasiertes KI-Modell als für ein Produkt „wesentliche Fernddatenverarbeitung” gilt und wann es als reiner, CRA-freier Dienst zu behandeln ist.

Diese Unschärfe betrifft praktisch jeden Anbieter, der KI-Funktionen sowohl als eingebettetes Produktmerkmal als auch als eigenständigen API-Zugang vermarktet, und dürfte erst mit den delegierten Rechtsakten und der ersten Verwaltungspraxis der Marktüberwachungsbehörden greifbarer werden.

Verwandte Begriffe

Quellenangaben

  1. Europäisches Parlament und Rat, 2024. Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act), Artikel 12, Artikel 14, Artikel 71, Anhang I. Amtsblatt der Europäischen Union, 20. November 2024.
  2. Europäisches Parlament und Rat, 2024. Verordnung (EU) 2024/1689 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz, Artikel 15, Artikel 42 Absatz 3. Amtsblatt der Europäischen Union, 12. Juli 2024.
  3. Europäische Kommission, 2026. Cyber Resilience Act. Digital Strategy, digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act.
  4. Europäische Kommission, 2026. Cyber Resilience Act – Open Source. Digital Strategy, digital-strategy.ec.europa.eu/en/policies/cra-open-source.

← Zurück zur Lexikon-Übersicht