NIS-2 und Cyber Resilience Act: Wenn Organisationssicherheit auf Produktsicherheit trifft
Sebastian SchlieVeröffentlichungAktualisierung
Alles Wichtige auf einen Blick
- Zwei Perspektiven, ein Ziel: NIS-2 regelt die organisatorische Widerstandsfähigkeit (§ 30 BSIG), der CRA die Produktsicherheit über den gesamten Lebenszyklus.
- Dringender Stichtag: Seit dem 11. September 2026 gelten bereits Meldepflichten für aktiv ausgenutzte Schwachstellen – auch für vor dem 11.12.2027 in Verkehr gebrachte Produkte.
- Lebenszyklus-Gedanke: Hersteller müssen Sicherheitsupdates und Schwachstellenbehandlung mindestens 5 Jahre (oft länger in der Industrie) nach Inverkehrbringen gewährleisten.
- SBOM-Pflicht: Eine maschinenlesbare Software Bill of Materials ist keine Option, sondern zwingende Voraussetzung für effektives Vulnerability Management nach CRA.
- Keine Silos bauen: Erfolgreiche Umsetzung bedeutet, bestehende NIS-2-Prozesse (Incident Management, Lieferantenprüfung) um die Produktperspektive des CRA zu erweitern, statt Doppelsysteme zu erstellen.
Wann gelten die CRA-Meldepflichten?
Seit dem 11. September 2026 hat der Cyber Resilience Act (CRA) eine neue praktische Relevanz. Seit diesem Datum gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die die Sicherheit von Produkten mit digitalen Elementen betreffen. Die übrigen wesentlichen Anforderungen des CRA werden ab dem 11. Dezember 2027 vollständig anwendbar.
Damit trifft der CRA auf eine regulatorische Landschaft, die sich für deutsche Unternehmen bereits deutlich verändert hat. Mit dem Inkrafttreten des deutschen NIS-2-Umsetzungsgesetzes am 6. Dezember 2025 gelten für besonders wichtige und wichtige Einrichtungen unter anderem Anforderungen an Risikomanagement, Meldeprozesse und Registrierung.
NIS-2 und CRA verfolgen dabei dasselbe übergeordnete Ziel: ein höheres Cybersicherheitsniveau in Europa. Sie tun dies jedoch aus zwei unterschiedlichen Perspektiven.
Worauf schaut NIS-2?
NIS-2 schaut auf die Organisation. Vereinfacht gesagt fragt NIS-2: Kann ein Unternehmen seine Leistungen auch unter Cyberbedrohungen sicher und widerstandsfähig erbringen?
Für betroffene Unternehmen geht es deshalb nicht lediglich um Firewall, Virenschutz oder Backup. §30 BSIG verlangt geeignete, verhältnismäßige sowie wirksame technische und organisatorische Risikomanagementmaßnahmen. Dazu gehören unter anderem Risikoanalysen, Incident Management, Business Continuity und Krisenmanagement, Lieferkettensicherheit, Schwachstellenmanagement, Schulungen, Kryptografie, Zugriffskontrolle und Multi-Faktor-Authentifizierung.
Cybersicherheit wird damit zur Organisationsaufgabe
Das zeigt sich besonders deutlich bei der Verantwortung der Geschäftsleitung. Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen müssen die erforderlichen Risikomanagementmaßnahmen umsetzen sowie deren Umsetzung überwachen. Daneben bestehen Schulungspflichten.
NIS-2 betrachtet folglich nicht ein einzelnes Produkt isoliert. Im Mittelpunkt stehen die Organisation, ihre Prozesse, ihre Informationssysteme, ihre Dienstleistungserbringung sowie die damit verbundenen Risiken.
Wichtig ist allerdings eine Einschränkung: Nicht jedes Industrieunternehmen fällt automatisch unter NIS-2. In Deutschland richtet sich die Betroffenheit unter anderem nach der konkreten Einrichtungsart, der Branche sowie den Größenmerkmalen. Das BSIG erfasst im verarbeitenden Gewerbe beispielsweise bestimmte Unternehmen aus der Herstellung von Datenverarbeitungsgeräten, elektronischen und optischen Erzeugnissen, elektrischen Ausrüstungen, dem Maschinenbau sowie dem Kraftwagen- und sonstigen Fahrzeugbau.
Die pauschale Aussage „Industrie gleich NIS-2“ wäre daher falsch.
Welche Rolle nimmt Ihr Unternehmen am europäischen Markt tatsächlich ein?
An einer anderen Stelle setzt der Cyber Resilience Act an. Ein „Produkt mit digitalen Elementen“ ist nach dem CRA grundsätzlich ein Software- oder Hardwareprodukt einschließlich bestimmter Datenfernverarbeitungslösungen sowie separat in Verkehr gebrachter Software- oder Hardwarekomponenten. Damit können beispielsweise vernetzte Maschinen, Steuerungen, Netzwerkkomponenten, Embedded Software oder eigenständige Software in den Anwendungsbereich fallen.
| Nicht zuerst fragen | Stattdessen klären |
Wie groß ist das Unternehmen? | Welches Produkt wird auf dem EU-Markt bereitgestellt? |
Zu welchem NIS-2-Sektor gehört es? | Welche Rolle nimmt das Unternehmen dabei ein? |
Der CRA unterscheidet unter anderem Hersteller, Einführer und Händler. Hersteller ist beispielsweise auch ein Unternehmen, das ein Produkt entwickeln oder herstellen lässt und anschließend unter seinem eigenen Namen oder seiner eigenen Marke vermarktet.
Das gilt besonders für Unternehmen im industriellen Mittelstand, die in folgenden Fällen handeln :
- Hardware zukaufen
- eigene Firmware integrieren
- Software eigenständig entwickeln
- verschiedene Komponenten kombinieren
- Kundenspezifische Systeme unter dem eigenen Namen vermarkten
Gilt Produktsicherheit wirklich nur bis zur Auslieferung?
Einer der wesentlichen Unterschiede zu früheren Vorstellungen von Produktsicherheit liegt im Lebenszyklusgedanken des CRA.
Hersteller müssen Cybersicherheitsrisiken bewerten und relevante Cybersicherheitsaspekte dokumentieren. Schwachstellen sind nicht nur vor dem Inverkehrbringen zu betrachten. Hersteller müssen während des festgelegten Unterstützungszeitraums dafür sorgen, dass Schwachstellen des Produkts und seiner Komponenten wirksam behandelt werden. Der Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzungsdauer des Produkts nicht kürzer ist. Bei langlebigen Produkten kann entsprechend ein längerer Zeitraum erforderlich sein.
Gerade für industrielle Produkte ist das relevant
Maschinen, Steuerungssysteme und andere technische Komponenten werden häufig wesentlich länger betrieben als klassische Consumer-IT. Der europäische Gesetzgeber weist ausdrücklich darauf hin, dass Produkte in industriellen Umgebungen oftmals deutlich längere Nutzungszeiten aufweisen.
Die neue Kernfrage
Damit wird aus der Frage „Ist unser Produkt bei Auslieferung sicher?“ zunehmend die Frage: Wie stellen wir die Sicherheit über Jahre hinweg sicher? Das betrifft Patch- und Updateprozesse ebenso wie Vulnerability Management, die Pflege von Drittkomponenten und die Kommunikation mit Kunden.
Warum wird die Software-Stückliste zum Kern des Schwachstellenmanagements?
Ein weiterer Punkt zeigt, wie weit der CRA in die Produktentwicklung hineinreicht: Hersteller müssen Schwachstellen und die in ihren Produkten enthaltenen Komponenten identifizieren und dokumentieren. Dazu gehört eine Software Bill of Materials, kurz SBOM, in einem gängigen maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten des Produktes erfasst. Das ist mehr als eine zusätzliche Dokumentationspflicht.
Wer nicht weiß, welche Bibliotheken, Open-Source-Komponenten und Abhängigkeiten im eigenen Produkt stecken, kann bei einer neu veröffentlichten Schwachstelle kaum schnell beurteilen, welche Produktversionen tatsächlich betroffen sind.
Der CRA verbindet deshalb Produktentwicklung, Komponentenmanagement und Vulnerability Management miteinander. Auch bei von Dritten bezogenen Komponenten verlangt er Sorgfalt. Entdeckt ein Hersteller eine Schwachstelle in einer integrierten Komponente, bestehen zudem Anforderungen an deren Behandlung und gegebenenfalls an die Information des Herstellers oder Maintainers dieser Komponente. Die SBOM sollte dabei nicht mit einer generell öffentlich bereitzustellenden Zutatenliste verwechselt werden. Der CRA verlangt ihre Erstellung; für Marktüberwachungsbehörden kann sie insbesondere im Rahmen der Konformitätsprüfung relevant werden.
Wo treffen NIS-2 und CRA aufeinander?
Genau hier wird die Trennung zwischen Organisations- und Produktsicherheit in der Praxis wieder unscharf. Ein NIS-2-betroffenes Unternehmen muss beispielsweise ein funktionierendes Schwachstellenmanagement besitzen. Ein Hersteller nach dem CRA benötigt ebenfalls Prozesse, mit denen Schwachstellen identifiziert, bewertet, behoben, dokumentiert und gegebenenfalls gemeldet werden. Ähnliches gilt für Incident Management, Verantwortlichkeiten, Dokumentation und Lieferketten.
§ 30 BSIG
Besonders deutlich wird die Verbindung bei der Beschaffung. § 30 BSIG fordert ausdrücklich die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern. Auch Sicherheitsmaßnahmen beim Erwerb von IT-Systemen, Komponenten und Prozessen sowie das Management und die Offenlegung von Schwachstellen gehören zum geforderten Risikomanagement.
Was Hersteller beifügen müssen
Der CRA schafft auf der anderen Seite konkrete produktbezogene Anforderungen. Informationen über den Unterstützungszeitraum, Sicherheitsupdates, Schwachstellenprozesse oder die sichere Verwendung eines Produktes können deshalb zunehmend auch für die Lieferantenbewertung und Beschaffung interessant werden. Hersteller müssen ihren Produkten unter anderem Informationen über den technischen Sicherheitssupport und das Ende des Unterstützungszeitraums beifügen. Dadurch entsteht eine Verbindung zwischen beiden Regelwerken: Der CRA erhöht die Anforderungen an das Produkt, während NIS-2 Unternehmen dazu zwingt, Cyberrisken ihrer Lieferkette systematisch zu berücksichtigen.
Das bedeutet allerdings nicht, dass eine CRA-Konformität automatisch alle Anforderungen einer NIS-2-Lieferantenbewertung erfüllt. Ebenso wenig ist eine CE-Kennzeichnung allein ein Ersatz für ein eigenes Risikomanagement.
Weshalb kann ein Industrieunternehmen mehrere Rollen gleichzeitig haben ?
Nehmen wir einen Maschinenbauer, der eine vernetzte Anlage unter eigenem Namen auf den europäischen Markt bringt. Enthält die Maschine digitale Elemente und fällt sie in den sachlichen Anwendungsbereich des CRA, muss das Unternehmen seine Herstellerpflichten betrachten.
CRA-Herstellerpflichten im Überblick
Dazu gehören perspektivisch beispielsweise:
- Cybersicherheitsrisikobewertung
- Technische Dokumentation
- Vulnerability Handling
- SBOM (Software Bill of Materials)
- Sicherheitsupdates
- Konformitätsbewertung
Vor dem Inverkehrbringen: Technische Dokumentation erstellen
Nach erfolgreicher Konformitätsbewertung: EU-Konformitätserklärung und CE-Kennzeichnung relevant
Doppelte Betroffenheit: CRA + NIS-2
Gleichzeitig könnte dieses Unternehmen aufgrund seiner Tätigkeit und Größe als wichtige oder besonders wichtige Einrichtung unter das BSIG fallen. Dann muss es nicht nur über die Sicherheit seiner eigenen Produkte nachdenken. Auch die eigenen IT-Systeme, Produktionsumgebungen, Dienstleister, Fernwartungszugänge, Lieferanten, Backupstrukturen und Reaktionsprozesse werden Teil des organisatorischen Cyberrisikomanagements.
Genau an diesem Punkt sollten NIS-2 und CRA nicht als zwei voneinander getrennte Complianceprojekte behandelt werden.
Müssen wir für den CRA wirklich zwei komplett getrennte Compliance-Projekte aufbauen?
Unternehmen, die bereits an einem Informationssicherheitsmanagementsystem oder an ihrer NIS-2-Umsetzung arbeiten, beginnen beim CRA häufig nicht bei null. Prozesse für Incident Management, Risikomanagement, Lieferantenmanagement, Rollen und Verantwortlichkeiten, Schwachstellenmanagement oder Dokumentenlenkung können eine organisatorische Grundlage bilden. Der CRA erweitert diese Grundlage jedoch um eine entscheidende Dimension: den konkreten Produktbezug.
Was bestehende Prozesse NICHT leisten:
- Eine unternehmensweite Schwachstellenrichtlinie allein beantwortet noch nicht, welche Version eines Produktes von einer bestimmten Schwachstelle betroffen ist
- Ein allgemeines Incident-Management-Verfahren legt noch nicht automatisch fest, wer einen CRA-meldepflichtigen Produktvorfall erkennt, bewertet und innerhalb der vorgegebenen Fristen meldet
- Ein klassisches Asset-Verzeichnis ersetzt keine produktbezogene Komponentenübersicht oder SBOM
Die bestehenden Prozesse sollten deshalb nicht ersetzt, sondern um die Produktperspektive erweitert werden.
Seit September 2026 ist der CRA bereits operative Realität
Seit 11. September 2026
Hersteller müssen aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit ihrer Produkte melden. Vorgesehen sind grundsätzlich eine Frühwarnung innerhalb von 24 Stunden und eine ausführlichere Meldung innerhalb von 72 Stunden. Weitere Abschlussmeldungen folgen abhängig davon, ob es sich um eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall handelt. Die Meldung erfolgt über die zentrale CRA-Meldeplattform.
Besonders wichtig ist dabei eine Übergangsregelung: Diese Meldepflichten können auch Produkte betreffen, die bereits vor dem 11. Dezember 2027 auf den Markt gebracht wurden. Für die übrigen CRA-Anforderungen gilt für bereits zuvor in Verkehr gebrachte Produkte grundsätzlich eine andere Übergangsregelung, sofern sie nach diesem Zeitpunkt nicht wesentlich verändert werden.
Ab Dezember 2027
Die wesentlichen Anforderungen werden vollständig anwendbar.
Es ergibt sich also: CRA ist kein Zukunftsthema. Unternehmen sollten deshalb heute bereits wissen, welche ihrer Produkte unter den CRA fallen könnten und wie sie Kenntnis von Schwachstellen oder Sicherheitsvorfällen erhalten.
Was sollten Unternehmen jetzt zusammenführen?
Für die Praxis ergeben sich aus meiner Sicht fünf zentrale Arbeitsfelder:
1. Betroffenheit getrennt prüfen: Zunächst muss festgestellt werden, ob das Unternehmen als Organisation unter NIS-2 beziehungsweise das BSIG fällt und welche eigenen Produkte unter den CRA fallen.
2. Rollen und Produkte erfassen: Unternehmen sollten transparent dokumentieren, welche Produkte sie selbst herstellen, unter eigenem Namen vermarkten, importieren oder vertreiben und welche digitalen Komponenten darin enthalten sind.
3. Incident- und Vulnerability-Prozesse verbinden: Produktbezogene Schwachstellen müssen in bestehende Sicherheitsprozesse integriert werden. Verantwortlichkeiten, Eskalationswege und Meldefristen sollten eindeutig festgelegt sein.
4. Lieferanten- und Komponentenmanagement verzahnen: NIS-2-Lieferkettensicherheit und CRA-Komponentenmanagement sollten nicht in getrennten Silos aufgebaut werden. Informationen über Supportzeiträume, Sicherheitsupdates, Schwachstellen und Drittkomponenten werden für beide Perspektiven relevant.
5. Nachweise von Anfang an mitdenken: Sowohl NIS-2 als auch CRA verlangen nicht nur Maßnahmen, sondern zunehmend deren nachvollziehbare Dokumentation. Prozesse sollten deshalb so aufgebaut werden, dass Entscheidungen, Bewertungen und Maßnahmen später belegbar sind.
Zwei Regelwerke, ein gemeinsames Ziel
NIS-2 und der Cyber Resilience Act sind keine konkurrierenden Regelwerke. Sie schließen vielmehr unterschiedliche Lücken.
| NIS-2 | Cyber-Resilience-Act |
| stärkt die Widerstandsfähigkeit von Organisationen und verpflichtet betroffene Einrichtungen zu einem systematischen Cyberrisikomanagement | verschiebt den Fokus auf Produkte mit digitalen Elementen und fordert, Cybersicherheit über deren gesamten relevanten Lebenszyklus hinweg zu berücksichtigen |
Für Unternehmen, die von beiden Regelwerken berührt werden, liegt darin auch eine Chance: Wer Incident Management, Vulnerability Management, Lieferantensteuerung und Verantwortlichkeiten von Anfang an gemeinsam denkt, kann Doppelstrukturen vermeiden.
Die entscheidende Frage verändert sich
Die entscheidende Frage lautet deshalb künftig nicht nur: Sind wir NIS-2 betroffen oder CRA-betroffen?
Sondern vielmehr: Wo treffen in unserem Unternehmen Organisationssicherheit und Produktsicherheit aufeinander – und sind unsere Prozesse darauf vorbereitet?
Sebastian Schlie
Geschäftsleitung
Sebastian Schlie (B.Sc. Informationstechnologie) blickt auf 18 Berufsjahre in der IT-Branche zurück. Er war seit 2008 bei der SIGMA Gesellschaft für Systementwicklung und Datenverarbeitung mbH zunächst als IT-Systemingenieur und später als Teamleiter im Bereich IT-Infrastruktur tätig. 2023 trat er den Posten des Geschäftsführers der SIGMA IT-Security und Infrastruktur GmbH an.
Lösungen für Ihre Branche und Ihre Prozesse stellen wir Ihnen gerne vor.
Sprechen Sie mit den Spezialisten für den Mittelstand.
