„NIS-2 haben wir schon umgesetzt, der CRA ist doch im Prinzip dasselbe." Zwei Wochen vor dem 11. September 2026 ist das der Mythos mit dem größten Schadenspotenzial, den ich in Gesprächen höre. Er ist deshalb so tückisch, weil er sich nach geleisteter Arbeit anfühlt. Das Unternehmen hat tatsächlich investiert, Prozesse gebaut, Meldewege definiert. Nur eben für ein anderes Regelwerk.
Was regeln NIS-2 und CRA jeweils?
NIS-2 ist die EU-Richtlinie zur Netzwerk- und Informationssicherheit, in Deutschland umgesetzt über das NIS-2-Umsetzungsgesetz. Sie richtet sich an Betreiber: an Unternehmen, die als wichtige oder besonders wichtige Einrichtungen eingestuft sind, etwa im verarbeitenden Gewerbe ab bestimmten Größenschwellen. Reguliert wird die Organisation selbst, also Risikomanagement für die eigene IT, Sicherheit der Lieferkette, Governance-Pflichten der Geschäftsleitung und die Meldung erheblicher Sicherheitsvorfälle, die das eigene Unternehmen treffen, an das BSI.
Der Cyber Resilience Act richtet sich an Hersteller (sowie Importeure und Händler) und reguliert das Produkt mit digitalen Elementen: Security by Design, also von Beginn an im Entwicklungsprozess verankerte Sicherheit, eine SBOM (Software Bill of Materials, das Verzeichnis aller Softwarekomponenten), Sicherheitsupdates über den Support-Zeitraum, Konformitätsbewertung mit CE-Kennzeichnung und die Meldung aktiv ausgenutzter Schwachstellen im Produkt. Einen Gesamtüberblick gibt die CRA-Zusammenfassung.
Kurz gefasst: NIS-2 fragt, ob Ihre Organisation sicher betrieben wird. Der CRA fragt, ob das, was Sie verkaufen, sicher ist und bleibt.
Warum die Gleichsetzung gefährlich ist
Ein produzierendes Unternehmen ab mittlerer Größe ist häufig beides zugleich: NIS-2-Einrichtung und CRA-Hersteller. Dann gelten zwei Pflichtenkataloge parallel, und die Unterschiede sitzen genau dort, wo es operativ wehtut:
- Andere Meldeauslöser: NIS-2 meldet erhebliche Vorfälle in der eigenen Organisation. Der CRA meldet aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Bezug auf das Produkt.
- Andere Meldewege: Die NIS-2-Meldung geht an das BSI als Aufsicht über Einrichtungen. Die CRA-Meldung läuft über die Single Reporting Platform der ENISA an das zuständige CSIRT (in Deutschland ebenfalls beim BSI angesiedelt, aber ein eigener Kanal mit eigenen Formaten und Fristen).
- Andere Fristenlogik: Beide Regelwerke kennen 24-Stunden-Frühwarnungen, aber für unterschiedliche Ereignisse. Wie das CRA-Stufenmodell funktioniert, steht im Beitrag zur 24-Stunden-Frist.
- Andere Gegenstände: Ein Ransomware-Befall Ihrer Verwaltung ist ein NIS-2-Fall. Eine ausgenutzte Lücke in Ihrer verkauften Steuerung ist ein CRA-Fall. Kompromittiert ein Angreifer Ihre Update-Infrastruktur, kann es beides zugleich sein, mit zwei parallelen Meldesträngen.
Das Praxisbeispiel, das ich derzeit öfter erlebe: Ein Mittelständler mit 400 Mitarbeitern hat NIS-2 sauber umgesetzt. Registrierung, Risikomanagement, Meldeprozess an das BSI, Schulung der Geschäftsleitung, alles vorhanden. Im Haus gilt „Meldepflichten: erledigt". Dass am 11. September für die Produktseite ein eigener Meldeweg scharf wird, mit anderem Auslöser und anderer Plattform, hat niemand auf dem Zettel. Die NIS-2-Umsetzung wirkt wie ein erledigter Haken und verdeckt die offene Flanke.
Mythos vs. Fakt
Mythos: Wer NIS-2 umgesetzt hat, hat damit auch die CRA-Anforderungen abgedeckt.
Fakt: NIS-2 reguliert die Organisation als Betreiber, der CRA das Produkt und seinen Hersteller. Wer beide Rollen hat, muss beide Pflichtenkataloge erfüllen, inklusive zweier getrennter Meldewege mit unterschiedlichen Auslösern, Objekten und Plattformen.
Konkrete Konsequenzen für Doppelrollen-Unternehmen
1. Klären Sie Ihre Rollen formal. Prüfen Sie zwei Fragen getrennt: Ist Ihr Unternehmen wichtige oder besonders wichtige Einrichtung unter NIS-2? Und bringen Sie Produkte mit digitalen Elementen auf den EU-Markt, sind also Hersteller im Sinne des CRA? Die Antworten bestimmen, welche Kataloge gelten. Verlassen Sie sich dabei nicht auf Bauchgefühl, die Herstellerrolle greift auch bei Whitelabel-Konstellationen und wesentlich veränderten Produkten.
2. Bauen Sie eine Krisenorganisation mit zwei Meldesträngen. Die Synergien sind real: Eskalationswege, Erreichbarkeiten, Entscheidungsbefugnisse und Dokumentationsroutinen aus der NIS-2-Umsetzung lassen sich direkt wiederverwenden. Ergänzen Sie sie um den CRA-Strang: Wer stellt fest, dass ein Produkt betroffen ist? Wer bedient die Single Reporting Platform? Ein gemeinsames Playbook mit zwei klar getrennten Ausgängen schlägt zwei getrennte Parallelorganisationen.
3. Testen Sie den CRA-Meldeweg vor dem Stichtag. Der NIS-2-Prozess ist bei Ihnen geübt, der CRA-Prozess vermutlich nicht. Nutzen Sie die verbleibenden zwei Wochen für einen Probelauf: von der Feststellung einer aktiv ausgenutzten Schwachstelle in einem Produkt über die Frühwarnungs-Vorlage bis zur fiktiven Einreichung. Voraussetzung ist, dass Sie überhaupt wissen, welche Komponenten in welchen Produkten stecken, also eine gepflegte SBOM und ein laufendes Schwachstellenmanagement.
Was bedeutet das für Ihre CRA-Roadmap?
Am 11. September 2026, in zwei Wochen, treten die CRA-Meldepflichten in Kraft. Für Doppelrollen-Unternehmen heißt das: Der zweite Meldestrang muss jetzt stehen. Es ist der letzte Freitag mit realistischem Vorlauf, um ihn noch zu testen.
Am 11. Dezember 2027 folgt die volle CRA-Anwendbarkeit für neu in Verkehr gebrachte Produkte, von der Konformitätsbewertung bis zur CE-Kennzeichnung.
Wie Sie beide Stichtage in eine Gesamtplanung übersetzen, zeigt die CRA Compliance-Roadmap 2026/2027. Was auf dem Spiel steht, beziffert der Artikel zu CRA-Bußgeldern und Sanktionen.
Häufig gestellte Fragen
Wir sind keine NIS-2-Einrichtung. Betrifft uns der CRA trotzdem? Ja, die Regelwerke sind unabhängig. Der CRA knüpft allein daran an, ob Sie Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen, unabhängig von Unternehmensgröße oder Sektor.
Wir sind NIS-2-Einrichtung, stellen aber nichts her. Was gilt? Dann bleibt es bei NIS-2. Prüfen Sie aber genau: Wer Software oder Geräte unter eigenem Namen an Dritte abgibt, auch als Whitelabel, kann Hersteller im CRA-Sinn sein.
Können wir dieselbe Meldung für beide Regelwerke verwenden? Nein. Auslöser, Inhalte, Empfänger und Plattformen unterscheiden sich. Bei überlappenden Ereignissen, etwa einem Angriff auf die Update-Infrastruktur, müssen Sie beide Stränge parallel bedienen. Ein gemeinsames Playbook hilft, die Doppelmeldung nicht zu übersehen.
Zählt die Geschäftsleitungs-Schulung aus NIS-2 auch für den CRA? Inhaltlich hilft sie, formal ersetzt sie nichts. Der CRA kennt keine explizite Schulungspflicht der Geschäftsleitung, dafür haftet das Unternehmen für Produktpflichten, die nur mit Rückhalt der Führung funktionieren, etwa Support-Zeiträume und Meldefreigaben.
Unser CRA-Aufwand wirkt nach der NIS-2-Umsetzung überschaubar. Täuscht das? Teilweise. Prozessual haben Sie Vorarbeit geleistet. Die produktbezogenen Pflichten, SBOM je Produktlinie, Konformitätsbewertung, Update-Prozesse, sind dagegen neu und liegen typischerweise in Entwicklung und Produktmanagement, nicht in der IT-Sicherheit.
Fazit
NIS-2 und CRA sind Nachbarn, keine Zwillinge. Das eine Regelwerk schützt Ihre Organisation, das andere Ihre Produkte und deren Nutzer. Wer beide Rollen hat, braucht beide Kataloge, und vor allem zwei funktionierende Meldewege. Die NIS-2-Vorarbeit ist dabei ein echter Vorsprung, solange sie nicht als Vorwand dient, die Produktseite abzuhaken.
Eine strukturierte CRA-Roadmap, unterstützt von einer Plattform wie Kunnus, hilft dabei, die Produktpflichten neben der bestehenden NIS-2-Organisation systematisch aufzubauen, bevor der Stichtag aus der Theorie in die Praxis kippt. Den Einstieg bietet unser kostenloser CRA-Compliance-Check.
Jeden Freitag räume ich hier mit einem CRA-Mythos auf.