Softwarehersteller sitzen zwischen zwei Fronten. Der Cyber Resilience Act trifft Ihr Produkt. NIS2 trifft Ihre Organisation. Wer beides getrennt behandelt, baut einen Compliance-Flickenteppich.
Ihre Entwickler sollen SBOMs pflegen. Schwachstellen monitoren. Updates liefern. Incident-Meldungen vorbereiten. Gleichzeitig fehlen Ressourcen, klare Prozesse und belastbare Verantwortlichkeiten.
Das Risiko ist nicht theoretisch. Ungepflegte Komponenten, unklare Patch-Zusagen und fehlende Secure-by-Design-Nachweise werden zum Haftungsproblem. Für Geschäftsführung, Produktleitung und Entwicklung.
CRA und NIS2: Anforderungen für Softwarehersteller
NIS2 ist kein reines IT-Sicherheitsprojekt. Für Softwarehersteller wird es zur Schnittstelle aus Unternehmenssicherheit, Produktentwicklung und Lieferkettenkontrolle.
Als Orientierungspunkt aus dem regulatorischen Kontext gilt sinngemäß: Für Software-Produkte sind Prinzipien wie Security-by-Design relevant, und die Anforderungen des Cyber Resilience Act (CRA) sind dabei zu berücksichtigen.
Das bedeutet in der Praxis:
- Security-by-Design muss nachweisbar in Ihren Entwicklungsprozess. Nicht als Folie im Management-Deck. Als dokumentierter Standard in Requirements, Architektur, Code, Build, Release und Wartung.
- SBOMs oder belastbare Komponenteninventare werden zur Pflichtübung. Sie müssen wissen, welche Open-Source- und Drittkomponenten in welchem Produkt, welcher Version und welchem Release stecken.
- Vulnerability Handling wird operativ. Schwachstellen müssen bewertet, priorisiert, behoben und kommuniziert werden. Mit Fristen. Mit Zuständigkeiten. Mit Audit-Spur.
- Update-Fähigkeit wird zum Produktversprechen. Wer Sicherheitsupdates nicht liefern kann, verkauft ein Risiko.
- NIS2 verlangt Governance. Verantwortlichkeiten, Risikomanagement, Incident-Prozesse, Lieferkettensicherheit und Management-Aufsicht müssen stehen.
Der Juristen-Jargon heißt übersetzt: Ihre Softwareentwicklung muss beweisfähig werden. Wenn morgen ein Kunde, Prüfer, Versicherer oder Aufsichtsorgan fragt, wie Sie CRA und NIS2 umgesetzt haben, reicht kein Verweis auf „agile Prozesse“.
Sie brauchen belastbare Artefakte. Sonst haben Sie nur einen Papier-Tiger.
Warum getrennte Compliance-Silos das Kernproblem verfehlen
Eine neue Firewall löst kein Produktproblem. Ein ISO-Template löst kein SBOM-Problem. Ein generisches ISMS löst kein Secure-Development-Problem.
Genau hier verschweigen viele Anbieter den kritischen Punkt: Die Schnittstelle zwischen Produktsicherheit nach CRA und Unternehmenssicherheit nach NIS2 ist der eigentliche Risikobereich.
Typische Fehlannahmen:
- „Wir haben ein ISMS, also sind wir NIS2-ready.“ Falsch. Wenn Ihr SDLC keine Security Gates hat, bleibt Ihre Software ein Risiko.
- „Unsere Entwickler patchen schon, wenn etwas passiert.“ Zu spät. CRA und NIS2 erwarten Prozesse vor dem Vorfall.
- „SBOM machen wir später.“ Gefährlich. Ohne Komponentenbasis können Sie CVEs nicht sauber zuordnen.
- „Das betrifft nur kritische Infrastrukturen.“ Zu kurz gedacht. Softwarelieferketten stehen im Fokus. Ihre Kunden werden Nachweise verlangen.
- „Wir kaufen ein Tool.“ Ein Tool ohne Verantwortlichkeiten, Policy, Release-Prozess und Nachweisführung ist nur teurer Overhead.
ISVs brauchen keine Enterprise-Beratungsmaschine. Sie brauchen Secure-by-Design Checklisten, klare Rollen, schlanke Nachweise und einen Entwicklungsprozess, der CRA und NIS2 gleichzeitig bedient.
Sonst entsteht ein Compliance-Flickenteppich: Produktteam macht CRA. IT macht NIS2. Legal prüft Verträge. Niemand besitzt das Gesamtrisiko.
Das ist der Moment, in dem Geschäftsführerhaftung real wird.
Schritte zu Secure-by-Design und nachweisfähiger Produktsicherheit
Produkt- und Komponentenregister sofort aufsetzen: Erfassen Sie jedes aktive Softwareprodukt mit Versionen, Third-Party-Komponenten, Open-Source-Bibliotheken, Build-Abhängigkeiten, Wartungsstatus und verantwortlichem Product Owner. Kein Excel-Friedhof ohne Pflegeverantwortung. Ein lebendes Register. Mit klarer Update-Frequenz.
Secure-by-Design Gates in den SDLC einziehen: Definieren Sie harte Mindestkontrollen vor jedem Release: Threat Modeling für kritische Funktionen, Dependency Scans, Code-Review-Pflichten, Secrets-Prüfung, CVE-Bewertung, Freigabeentscheidung und dokumentierte Restrisiken. Ohne Gate kein Release. Punkt.
CRA- und NIS2-Verantwortung organisatorisch verbinden: Benennen Sie einen Verantwortlichen für Product Security und verknüpfen Sie ihn mit IT-Security, Legal und Geschäftsführung. Legen Sie fest, wer Schwachstellen bewertet, wer Kunden informiert, wer Updates priorisiert und wer Management-Reports liefert. Keine informelle Slack-Verantwortung. Schriftlich. Prüfbar. Durchsetzbar.
Checkliste: CRA und NIS2 für Softwarehersteller und ISVs
Die Checkliste gibt einen strukturierten Überblick, welche Secure-by-Design-Kontrollen, SBOM-Anforderungen und Governance-Maßnahmen für Softwarehersteller im CRA- und NIS2-Kontext relevant sind. Sie dient der internen Orientierung und ersetzt keine rechtliche oder produktspezifische Fachberatung.