| Cyber Resilience für Software-Produkte | • Aidex • IT • Impressum • Datenschutz |
Cyber Resilience Act (CRA)Die EU hat verbindliche Sicherheitsanforderungen für „Produkte mit digitalen Elementen“ definiert. Die ↗Cyber-Resilienz-Verordnung (CRV, CRA) verpflichtet Hersteller von vernetzter Hardware und Software zu Mindeststandards. Diese Seite enthält eine grobe Übersicht zu den Auswirkungen des CRA auf Software und Softwarehersteller. Hardware wird hier nicht berücksichtigt. Alle Angaben ohne Gewähr. Zudem ersetzt diese Seite keine Rechtsberatung. Seit dem 11. September 2026 gilt die erste Pflicht aus der Verordnung, nämlich die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle. Die Meldefristen sind kurz. Ab dem 11. Dezember 2027 gilt die vollständige Anwendung des CRA, d.h. mit Konformitätsbewertung, technischer Dokumentation und CE-Kennzeichnung. Betroffen ist damit praktisch jeder Hersteller, der Software oder vernetzte Hardware auf dem EU-Markt anbietet - unabhängig von der Unternehmensgröße. Es gibt jedoch Erleichterungen für Kleinunternehmen. Als "vernetzte" Software kann ein Programm möglicherweise bereits dann gelten, wenn es auf Dateien im lokalen Netzwerk zugreift, z.B. \\Server\Freigabe\Daten.xlsx Anders als frühere Regelwerke, die vor allem auf den sicheren Betrieb von IT-Systemen abzielen, verlagert CRA den Fokus auf die Sicherheit des Produkts selbst. Die Cyber-Sicherheit eines Produkts bedeutet z.B. eine sichere Standardkonfiguration, dokumentiertes Schwachstellen-Management und kostenlose Sicherheitsupdates während eines festgelegten Support-Zeitraums. Damit entsteht eine durchgehende Herstellerverantwortung von der Entwicklung bis zum Support-Ende. Betrachtet man CRA zusammen mit der NIS2-Richtlinie und dem KRITIS-Dachgesetz, erkennt man ein übergeordnetes Ziel, nämlich die Resilienz gegenüber Cyberbedrohungen und physischen Störungen. Die drei Gesetze setzen an unterschiedlichen Stellen an. Während der CRA die Sicherheit des Produkts selbst regelt und damit den Hersteller in die Pflicht nimmt, adressiert ↗NIS2 die Organisation im Unternehmen: Risikomanagement, Meldepflichten bei Sicherheitsvorfällen und die Verantwortung der Geschäftsleitung. Das ↗KRITIS-Dachgesetz wiederum, seit dem 17. März 2026 in Kraft, ergänzt diese Regelungen um die physische Resilienz kritischer Anlagen - also den Schutz vor Sabotage, Naturkatastrophen und Infrastrukturausfällen. |
AusnahmenBevor wir auf die Pflichten aus dem CRA eingehen, hier vorab die Ausnahmen und Erleichterungen ... CRA-Ausnahme: Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird, ist nicht CRA-pflichtig. Das betrifft vor allem private, nicht-kommerzielle Entwicklung sowie echte Community-/Non-Profit Projekte ohne Gewinnerzielungsabsicht – unabhängig davon, ob Closed Source oder Open Source. Wenn jemand eine Freeware jedoch auf seiner Geschäfts-Website anbietet, gilt diese Ausnahme nicht. Denn dann wird die (kostenlose) Software im Rahmen einer Geschäftstätigkeit bereitgestellt. Eine betriebsinterne Software, die gar nicht auf dem EU-Markt angeboten wird, kann CRA-pflichtig werden, wenn das Programm in einer Unternehmensgruppe an Tochtergesellschaften weitergegeben wird - auch dann, wenn dies unentgeltlich geschieht. Die Meldepflichten gelten unabhängig davon, wann das Produkt in Verkehr gebracht wurde. Die Meldepflichten seit 09/2026 gelten auch für Software, die schon vorher angeboten wurde, egal seit wann. Aber die vollständigen Anforderungen (Security by Design, Konformitätsbewertung, technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung) gelten nur für Produkte, die ab dem 11. Dezember 2027 neu in Verkehr gebracht werden. Software, die vorher schon auf dem Markt war, muss diese Anforderungen nicht rückwirkend erfüllen. Die Pflichten müssen von allen Herstellern befolgt werden, auch von Kleinunternehmen.
Jedoch sind Kleinunternehmen von Bußgelder bei einer versäumten 24-Stunden-Frühwarnung ausgenommen.
|
Vier RisikoklassenDie CRA-Verordnung klassifiziert Produkte anhand ihres Risikoprofils in vier Stufen. Für jedes Risiko gibt es ein anderes Modul (Verfahren) zur Konformitätsbewertung. Die Default-Kategorie (Standardprodukte)
Aber Achtung, siehe auch unten: Externe Komponenten! Die nachfolgend genannte „Important Class I / II“ wurde im deutschen Rechtstext übersetzt als „wichtige Produkte mit digitalen Elementen der Klasse I bzw. II“. Important Class I
Important Class II
Kritische Produkte
|
Ablauf (erforderlich ab Dezember 2027)Da vielleicht 90% aller Softwareprodukte in die Default-Kategorie fallen, sieht der Ablauf hierbei für die meisten Hersteller so aus:
In der Default-Kategorie ist kein Antrag bei einer Behörde nötig, keine externe Prüfung, keine Wartezeit auf eine benannte Stelle - aber die Selbstbewertung ist trotzdem kein Freifahrtschein: Es muss inhaltlich belastbar sein und im Streitfall nachweisbar sein. Sonderfall: externe Komponenten Wer prüft das eigentlich - und ab wann? Für die Produkte, die eine externe Prüfung brauchen, kommen sogenannte "benannte Stellen" (notified bodies) ins Spiel - privatrechtlich organisierte, staatlich akkreditierte Prüfstellen. Seit Juni 2026 können EU-Mitgliedstaaten solche Konformitätsbewertungsstellen benennen und notifizieren. Für Hersteller wichtiger oder kritischer Produkte bedeutet es die Notwendigkeit zur Kapazitäts- und Terminplanung, denn die Prüfstellen-Infrastruktur ist EU-weit noch im Aufbau. |
CYBER RESILIENCE ACT · VERORDNUNG (EU) 2024/2847
Pflichten, Fristen und Fundstellen im Überblick - für Anbieter von Software auf dem EU-Markt
Amtlicher, rechtsverbindlicher deutscher Gesetzestext auf EUR-Lex: ↗Verordnung (EU) 2024/2847. Die Artikel-Links in dieser Checkliste verweisen zusätzlich auf einen frei navigierbaren, inhaltlich identischen Spiegel: ↗cyberresilienceact.eu/de. Verbindlich ist im Zweifel immer die EUR-Lex-Fassung.
Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder herstellt und unter eigenem Namen oder eigener Marke vermarktet – auch unentgeltlich oder zur Monetarisierung.
Art. 3 Nr. 13 · ↗BegriffsbestimmungenErfasst sind Software- und Hardwareprodukte mit einer direkten oder indirekten Datenverbindung zu einem Gerät oder Netz – praktisch jede vernetzte Business-Software. Ausnahmen bestehen nur für bereits anderweitig regulierte Bereiche wie Medizinprodukte, Kraftfahrzeuge oder Luftfahrt.
Art. 2 · ↗AnwendungsbereichAktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen zeitgestuft gemeldet werden: 24 Std. Frühwarnung, 72 Std. Detailmeldung, 14 Tage bzw. 1 Monat für den Abschlussbericht.
Art. 14 · ↗Meldepflichten der HerstellerÜber die zentrale Meldeplattform der ENISA, die die Meldung automatisch an das zuständige nationale CSIRT weiterleitet.
Art. 16 · ↗Einrichtung einer einheitlichen MeldeplattformAuch Schwachstellen ohne aktive Ausnutzung oder Beinahe-Vorfälle können freiwillig gemeldet werden - das begründet keine höhere Haftung.
Art. 15 · ↗Freiwillige MeldungenFür Kleinst- und Kleinunternehmen entfallen Bußgelder ausdrücklich nur bei einer versäumten 24-Stunden-Frist – nicht bei den übrigen Fristen oder der Meldepflicht als solcher.
Art. 64 Abs. 10 · ↗SanktionenDer wichtigste Artikel für Hersteller: Risikobewertung, Einhaltung der Anforderungen aus Anhang I, Festlegung eines Unterstützungszeitraums, kostenlose Sicherheitsupdates, veröffentlichte Kontaktstelle für Schwachstellenmeldungen.
Art. 13 · ↗Pflichten der HerstellerDiese stehen nicht in den Artikeln, sondern im Anhang I, dem Herzstück der materiellen Pflichten:
Zentrale Begriffe wie „Software-Stückliste“, „aktiv ausgenutzte Schwachstelle“ und „Unterstützungszeitraum“ sind formal definiert in Art. 3 Nr. 39, 42, 20.
Enthält alle Angaben dazu, wie die Anforderungen aus Anhang I erfüllt werden.
Art. 31 i. V. m. Anhang VII · ↗Technische DokumentationWird ausgestellt, sobald das Konformitätsbewertungsverfahren die Erfüllung von Anhang I nachweist.
Art. 28 i. V. m. Anhang V/VI · ↗EU-KonformitätserklärungBei reiner Software genügt die Kennzeichnung auf der Konformitätserklärung oder der begleitenden Website.
Art. 29, 30 · ↗Anbringung der CE-KennzeichnungFür die meisten Standard-Softwareprodukte reicht das interne Kontrollverfahren (Modul A, Selbstbewertung).
Art. 32 i. V. m. Anhang VIII · ↗KonformitätsbewertungsverfahrenFällt das Produkt in eine der gelisteten Kategorien (z.B. Firewalls, Passwortmanager, VPN-Software, Betriebssysteme), gelten strengere Konformitätsverfahren statt reiner Selbstbewertung.
Art. 7 (wichtige Produkte, Anhang III) · ↗Wichtige ProdukteErleichterungen für Kleinst- und Kleinunternehmen: Sensibilisierungsmaßnahmen, eigener Beratungskanal, reduzierte Konformitätsbewertungsgebühren, vereinfachtes Formular für die technische Dokumentation.
Art. 33 · ↗Unterstützungsmaßnahmen für KMUErgänzend regelt Art. 69 Übergangsfragen – u. a., dass Art. 13 nur für Produkte gilt, die ab Dezember 2027 neu in den Verkehr gebracht oder wesentlich geändert werden, während die Meldepflicht aus Art. 14 auch für Bestandsprodukte greift.
Art. 69 · ↗ÜbergangsbestimmungenBußgeldrahmen bis 15 Mio. € oder 2,5% des weltweiten Jahresumsatzes bei Verstößen gegen die Kernpflichten aus Anhang I, Art. 13 und Art. 14; bis 10 Mio. € bzw. 2% bei anderen Pflichtverstößen.
Art. 64 · ↗Sanktionen