NIS2 und Cyber Resilience Act: Was die neuen Sicherheitsgesetze für selbstgebaute Software bedeuten
Kurz gesagt: Zwei EU-Regelwerke verändern gerade, wie ernst Cybersicherheit rechtlich genommen wird. NIS2 gilt in Deutschland seit Dezember 2025 und verpflichtet rund 29.500 Unternehmen zu Risikomanagement und Meldepflichten, mit persönlicher Haftung der Geschäftsleitung. Der Cyber Resilience Act greift ab September 2026 und stellt erstmals Sicherheitsanforderungen an Produkte mit digitalen Elementen, also auch an reine Software. Das Entscheidende für Sie: Selbst wenn Sie nicht direkt betroffen sind, zieht Sie die Lieferkette hinein, sobald Sie Software an ein reguliertes Unternehmen liefern. Dieser Text ordnet ein, ohne Rechtsberatung zu sein.
Angaben mit Stand Mitte 2026. Prüfen Sie den aktuellen Stand, bevor Sie Entscheidungen treffen.
Warum diese beiden Gesetze zusammengehören
Man verwechselt NIS2 und den Cyber Resilience Act leicht, weil beide Cybersicherheit regeln. Sie setzen aber an verschiedenen Stellen an. Ein einfacher Merksatz hilft: Der Cyber Resilience Act regelt das Produkt, NIS2 regelt den Betreiber. NIS2 fragt, ob Ihr Unternehmen seine IT sicher betreibt. Der Cyber Resilience Act fragt, ob die Software, die Sie herstellen und in Verkehr bringen, sicher gebaut ist. Für jemanden, der eigene Software baut und betreibt, sind das zwei Baustellen zugleich.
NIS2: der Betreiber in der Pflicht
NIS2 ist in Deutschland durch das NIS2-Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft, und zwar ohne Übergangsfrist. Betroffene Einrichtungen waren vom ersten Tag an verpflichtet. Der Kreis der Betroffenen ist stark gewachsen, von rund 4.500 auf etwa 29.500 Unternehmen, verteilt auf 18 Sektoren. Als Schwelle gilt in diesen Sektoren meist ein Betrieb ab 50 Beschäftigten oder mehr als 10 Millionen Euro Jahresumsatz. Zuständige Aufsicht ist das Bundesamt für Sicherheit in der Informationstechnik.
Die Pflichten sind konkret. Betroffene müssen ein Risikomanagement für ihre IT-Sicherheit betreiben, Sicherheitsvorfälle innerhalb kurzer Fristen melden, wobei die erste Meldung binnen 24 Stunden zu erfolgen hat, und die Sicherheit ihrer Lieferkette im Blick behalten. Verstöße können teuer werden, mit Bußgeldern bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. Und ein Punkt, der Geschäftsführer besonders betrifft: Die Verantwortung liegt ausdrücklich bei der Geschäftsleitung, die persönlich in die Pflicht genommen wird. Cybersicherheit ist damit keine Sache mehr, die man an die IT delegiert und vergisst.
Der Lieferketten-Effekt, den viele übersehen
Jetzt kommt der Teil, der auch kleinere Betriebe betrifft, die sich bei den Schwellenwerten sicher fühlen. NIS2 verlangt von den betroffenen Unternehmen, die Sicherheit ihrer Lieferkette zu kontrollieren. Das bedeutet: Wenn Sie Software, ein Tool oder einen Dienst an ein Unternehmen liefern, das unter NIS2 fällt, dann wird dieses Unternehmen von Ihnen verlangen, dass auch Ihre Software den Anforderungen genügt. Nicht weil das Gesetz Sie direkt adressiert, sondern weil Ihr Kunde seine eigene Pflicht an Sie weitergibt. Ein selbstgebautes Tool, das ein größerer Kunde in seinem regulierten Betrieb einsetzt, wird so faktisch zum Prüfgegenstand, ganz ohne dass Sie selbst in den 29.500 stecken.
Cyber Resilience Act: das Produkt in der Pflicht
Der Cyber Resilience Act ergänzt das von der Produktseite. Er ist als EU-Verordnung seit Dezember 2024 in Kraft und gilt unmittelbar, ohne dass Deutschland ihn erst in nationales Recht gießen müsste. Sein Anwendungsbereich ist breiter, als die meisten vermuten. Er erfasst Produkte mit digitalen Elementen, und das schließt ausdrücklich reine Software ein, von Buchhaltungssoftware über Apps bis zu Software mit lokaler Client-Komponente. Eine Ausnahme für kleine Unternehmen gibt es nicht. Ausgenommen sind bestimmte, anderweitig regulierte Bereiche wie Medizinprodukte oder Fahrzeuge sowie kostenlose Open-Source-Software ohne Gewinnerzielungsabsicht.
Die Fristen sind gestaffelt. Ab dem 11. September 2026 greift zuerst die Meldepflicht: Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb kurzer Fristen melden. Ab dem 11. Dezember 2027 gelten dann die vollen Anforderungen für neu in Verkehr gebrachte Produkte, darunter Security by Design, kostenlose Sicherheitsupdates über den Produktlebenszyklus, eine technische Dokumentation mit einer Auflistung der verwendeten Softwarebestandteile und eine Konformitätsbewertung mit CE-Kennzeichnung für Cybersicherheit.
Was das für selbstgebaute und vibecodete Software heißt
Wenn Sie Software nur intern nutzen, sind Sie beim Cyber Resilience Act meist außen vor, denn er setzt am Inverkehrbringen an. Sobald Sie Ihre Software aber verkaufen, als Produkt anbieten oder einem Kunden bereitstellen, werden die Anforderungen relevant. Und hier trifft die Regulierung genau die Schwachstellen, die schnell gebaute KI-Prototypen typischerweise haben. Security by Design bedeutet, dass Sicherheit von Anfang an eingebaut ist, nicht nachträglich draufgesetzt. Ein Schwachstellenmanagement bedeutet, dass Sie Sicherheitslücken erkennen, beheben und melden können, statt erst davon zu erfahren, wenn Daten abfließen. Eine Auflistung der Softwarebestandteile bedeutet, dass Sie wissen, aus welchen Bausteinen Ihre Software besteht, was bei zusammenkopiertem KI-Code oft niemand mehr genau weiß.
Anders gesagt: Was der Cyber Resilience Act verlangt, deckt sich weitgehend mit dem, was ohnehin den Unterschied zwischen einem Prototyp und einem produktionsreifen Produkt ausmacht. Die Regulierung macht das, was gute Ingenieure sowieso empfehlen, zur Pflicht.
Der ruhige nächste Schritt
Der vernünftige Einstieg ist nicht, sich in Paragraphen zu vergraben, sondern den eigenen Stand ehrlich zu kennen. Zwei Fragen führen weit. Erstens: Liefere ich Software oder Dienste an Unternehmen, die selbst reguliert sein könnten? Dann kommt der Lieferketten-Druck auf mich zu. Zweitens: Bringe ich eigene Software als Produkt auf den Markt? Dann betrifft mich der Cyber Resilience Act. Zwei Mal Ja bedeutet nicht Panik, sondern dass die saubere Absicherung Ihrer Software von einer guten Idee zu einer geschäftlichen Notwendigkeit geworden ist. Genau dort setzen wir an, mit einem strukturierten Blick darauf, wo Ihre Software den Anforderungen heute nicht genügt und was sich mit vertretbarem Aufwand schließen lässt.
Sie liefern Software an regulierte Kunden oder bringen ein Produkt auf den Markt? Wir prüfen im Vibecode-Audit, wo Ihre Software die Sicherheitsanforderungen heute nicht erfüllt, und bringen sie so auf Stand, dass Security by Design und Schwachstellenmanagement keine Baustelle mehr sind.