CRA und NIS2: Wo sich Cybersicherheitsvorschriften für Produktunternehmen überschneiden
Verstehen, wie CRA und NIS2 zusammenwirken. Ein praktischer Leitfaden für Organisationen, die Produkte herstellen und kritische Dienste betreiben.
In diesem Artikel
- Zusammenfassung
- CRA vs. NIS2: Fundamentaler Unterschied
- Wer unterliegt beiden Verordnungen?
- Überlappende Anforderungen
- Meldevergleich
- Ein einheitliches Sicherheitsprogramm für CRA und NIS2
- Unterschiede bei der Durchsetzung von CRA und NIS2
- Compliance-Zeitplan-Zusammenspiel
- Praktische Koordinierungs-Checkliste
- Edge Cases mit doppeltem Geltungsbereich, die genaue Abgrenzung erfordern
- FAQ zu CRA und NIS2 für Produkthersteller
- Nächste Schritte
Sie stellen IoT-Geräte für den Energiesektor her. Sie unterliegen sowohl NIS2 (als Betreiber wesentlicher Dienste) als auch dem CRA (als Produkthersteller). Zwei Verordnungen, überlappende Anforderungen, ein Compliance-Budget.
Dieser Leitfaden erklärt, wie CRA und NIS2 zusammenwirken und wie Sie die Compliance mit beiden managen.
Zusammenfassung
- CRA reguliert Produkte; NIS2 reguliert Organisationen/Dienste
- Viele Unternehmen stehen vor beiden: Hersteller, die auch wesentliche/wichtige Einrichtungen sind
- Wichtige Überschneidungen: Schwachstellenmanagement, Incident-Meldung, Lieferkettensicherheit
- Unterschiedliche Geltungsbereiche: CRA = Produktlebenszyklus; NIS2 = organisatorische Cybersicherheit
- Koordinierungschance: Einheitliche Sicherheitsprozesse, die beiden Verordnungen dienen
CRA vs. NIS2: Fundamentaler Unterschied
CRA: Produktverordnung
Was sie reguliert: Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden
Für wen sie gilt: Hersteller, Importeure, Händler von Produkten mit digitalen Elementen
Fokus: Produktsicherheit über den gesamten Lebenszyklus
- Sicheres Design und sichere Entwicklung
- Schwachstellenbehandlung für Produkte
- Sicherheitsupdates für Produkte
- Produktbezogene Incident-Meldung
NIS2: Organisatorische Verordnung
Was sie reguliert: Cybersicherheit wesentlicher und wichtiger Einrichtungen
Für wen sie gilt: Organisationen in bestimmten Sektoren, die Größenschwellen erreichen
Fokus: Organisatorische Cybersicherheit
- Governance und Risikomanagement
- Incident-Behandlung für Dienste
- Lieferkettensicherheit
- Business Continuity
Die Überschneidungszone
NIS2-BEREICH CRA-BEREICH
+----------------------+ +----------------------+
| - Ihre IT-Systeme | | - Produkte, die Sie |
| - Ihre Dienste | | herstellen |
| - Ihr Betrieb | | - Produkte, die Sie |
| - Ihre Lieferkette | | importieren |
| (als Beschaffer) | | - Produkte, die Sie |
| | | vertreiben |
+----------+-----------+ +-----------+----------+
\ /
\ /
+----------------------------+
| ÜBERSCHNEIDUNG |
| |
| - Schwachstellenmgmt. |
| - Incident-Meldung |
| - Lieferkettensicherheit |
| - Sicherheits-Governance |
+----------------------------+
Wer unterliegt beiden Verordnungen?
Szenario 1: Wesentliche Einrichtung, die Produkte herstellt
Beispiel: Energieunternehmen, das Smart-Grid-Komponenten herstellt
- NIS2 gilt: Energiesektoreinrichtung über Schwellenwert
- CRA gilt: Hersteller von Produkten mit digitalen Elementen
Beide Verordnungen verlangen:
- Cybersicherheits-Risikomanagement
- Schwachstellenbehandlung
- Incident-Meldung (an unterschiedliche Stellen, unterschiedliche Auslöser)
- Lieferkettensicherheit
Szenario 2: Wichtige Einrichtung, die IoT herstellt
Beispiel: Fertigungsunternehmen, das industrielle IoT-Sensoren herstellt
- NIS2 gilt: Fertigungssektoreinrichtung über Schwellenwert
- CRA gilt: Hersteller von Produkten mit digitalen Elementen
Szenario 3: Anbieter digitaler Infrastruktur
Beispiel: Cloud-Anbieter, der auch Hardware-Appliances verkauft
- NIS2 gilt: Anbieter digitaler Infrastruktur
- CRA gilt: Hersteller von Hardware-Produkten
Szenario 4: Gesundheitsprodukt-Hersteller
Beispiel: Medizinprodukt-angrenzendes Unternehmen (nicht MDR-erfasste Geräte)
- NIS2 gilt: Gesundheitssektoreinrichtung
- CRA gilt: Produkte, die nicht von MDR-Ausnahme erfasst sind
Überlappende Anforderungen
Schwachstellenmanagement
| Aspekt | CRA-Anforderung | NIS2-Anforderung |
|---|---|---|
| Geltungsbereich | Produktschwachstellen | Organisatorische Systeme |
| Entdeckung | Produktschwachstellen überwachen | Alle Systeme überwachen |
| Reaktion | Produkte unverzüglich patchen | Schwachstellen beheben |
| Meldung | ENISA (wenn ausgenutzt) | Nationales CSIRT (wenn Incident) |
Koordinierungschance: Einheitliches Schwachstellenmanagement-Programm, das sowohl Produkte als auch organisatorische Systeme abdeckt.
Incident-Meldung
| Aspekt | CRA-Anforderung | NIS2-Anforderung |
|---|---|---|
| Auslöser | Aktiv ausgenutzte Schwachstelle im Produkt | Erheblicher Incident, der Dienste betrifft |
| Zeitrahmen | 24h → 72h → 14/30 Tage | 24h → 72h → 1 Monat |
| Empfänger | ENISA + nationales CSIRT | Nationale zuständige Behörde/CSIRT |
| Umfang | Produktsicherheit | Dienstverfügbarkeit/-integrität |
Wichtige Unterscheidung: Eine Schwachstelle in Ihrem Produkt könnte CRA-Meldung auslösen, auch wenn Ihre Dienste nicht betroffen sind. Ein Dienstausfall könnte NIS2-Meldung auslösen, auch wenn keine Produktschwachstelle existiert.
Lieferkettensicherheit
| Aspekt | CRA-Anforderung | NIS2-Anforderung |
|---|---|---|
| Fokus | Komponenten in Ihren Produkten | Lieferanten für Ihre Organisation |
| Bewertung | Technische Due Diligence | Lieferanten-Sicherheitsbewertung |
| Überwachung | SBOM, Schwachstellenverfolgung | Fortlaufendes Lieferanten-Risikomanagement |
Koordinierungschance: Integriertes Lieferantenmanagement, das sowohl Produktkomponenten als auch organisatorische Lieferanten abdeckt.
Meldevergleich
CRA-Meldepfad
PRODUKTSCHWACHSTELLE (aktiv ausgenutzt)
│
▼
24-STUNDEN-FRÜHWARNUNG
An: ENISA Single Reporting Platform
│
▼
72-STUNDEN-DETAILLIERTE MELDUNG
An: ENISA + relevante CSIRTs
│
▼
14-TAGE-ABSCHLUSSBERICHT (Schwachstelle)
30-TAGE-ABSCHLUSSBERICHT (Incident)
NIS2-Meldepfad
ERHEBLICHER INCIDENT (der Dienste betrifft)
│
▼
24-STUNDEN-FRÜHWARNUNG
An: Nationale zuständige Behörde oder CSIRT
│
▼
72-STUNDEN-INCIDENT-MELDUNG
An: Nationale zuständige Behörde oder CSIRT
│
▼
1-MONAT-ABSCHLUSSBERICHT
An: Nationale zuständige Behörde oder CSIRT
Wenn beide gelten
Ein einzelnes Ereignis könnte beide auslösen:
Beispiel: Zero-Day in Ihrem Produkt wird aktiv ausgenutzt und betrifft Kunden, die wesentliche Einrichtungen sind (wie Energieunternehmen, die Ihre Smart-Grid-Ausrüstung nutzen).
CRA-Meldung: Sie melden die aktiv ausgenutzte Schwachstelle (Sie sind der Hersteller)
NIS2-Meldung: Ihre betroffenen Kunden melden möglicherweise den Incident (sie sind die wesentlichen Einrichtungen)
Ihre interne Meldung: Wenn Sie auch eine wesentliche Einrichtung sind, die Ihre eigenen Produkte nutzt, müssen Sie möglicherweise unter beiden melden
Ein einheitliches Sicherheitsprogramm für CRA und NIS2
Einheitliche Sicherheits-Governance
Anstatt getrennter CRA- und NIS2-Compliance-Programme:
EINHEITLICHE CYBERSICHERHEITS-GOVERNANCE
Vorstandsebene:
- Einheitliche Cybersicherheits-Risikoaufsicht
- Kombinierte Berichterstattung an Management
Operative Ebene:
- Ein Schwachstellenmanagement-Programm
├── Produktschwachstellen (CRA-Fokus)
└── Systemschwachstellen (NIS2-Fokus)
- Eine Incident-Response-Fähigkeit
├── Produkt-Incidents (CRA-Meldung)
└── Dienst-Incidents (NIS2-Meldung)
- Ein Lieferkettensicherheits-Programm
├── Produktkomponenten (SBOM, CRA)
└── Dienstleister (NIS2)
Prozesszuordnung
| Prozess | CRA-Anwendung | NIS2-Anwendung |
|---|---|---|
| Risikobewertung | Produkt-Risikobewertung | Organisatorisches Risikomanagement |
| Schwachstellen-Scanning | Produkt-/Komponenten-Scanning | Infrastruktur-Scanning |
| Patch-Management | Produkt-Updates | System-Patches |
| Incident Response | Produkt-Incident-Behandlung | Dienst-Incident-Behandlung |
| Sicherheitstests | Produkt-Sicherheitstests | Penetrationstests |
| Awareness-Schulung | Sichere-Entwicklung-Schulung | Allgemeine Sicherheitsbewusstseins-Schulung |
Dokumentationseffizienz
Manche Dokumentation kann beiden dienen:
| Dokument | CRA-Nutzung | NIS2-Nutzung |
|---|---|---|
| Sicherheitsrichtlinie | Produkt-Sicherheitsrichtlinien-Abschnitt | Organisatorische Sicherheitsrichtlinie |
| Risikoregister | Produktrisiken | Organisatorische Risiken |
| Incident-Response-Plan | Produkt-Incident-Verfahren | Dienst-Incident-Verfahren |
| Lieferantenbewertung | Komponenten-Lieferanten-Due-Diligence | Dienstleister-Bewertung |
Unterschiede bei der Durchsetzung von CRA und NIS2
CRA-Durchsetzung
- Marktüberwachungsbehörden überwachen Produkte
- Fokus auf Produktkonformität
- Strafen bis zu 15 Mio. € oder 2,5% des weltweiten Umsatzes
- Produktrücknahme/-rückruf möglich
NIS2-Durchsetzung
- Nationale zuständige Behörden beaufsichtigen Einrichtungen
- Fokus auf organisatorische Compliance
- Strafen bis zu 10 Mio. € oder 2% des weltweiten Umsatzes
- Persönliche Haftung für Management möglich
Doppelbestrafung?
Ein einzelnes Versagen könnte theoretisch Durchsetzung unter beiden auslösen:
Beispiel: Schlechtes Schwachstellenmanagement führt zu ungepatchtem Produkt UND ungepatchten internen Systemen.
- CRA: Nicht-Compliance mit Schwachstellenbehandlungsanforderungen
- NIS2: Nicht-Compliance mit Risikomanagementmaßnahmen
In der Praxis: Regulatoren sollten koordinieren. Einheitliche Compliance nachzuweisen hilft.
Compliance-Zeitplan-Zusammenspiel
NIS2-Zeitplan
- Oktober 2024: NIS2-Umsetzungsfrist
- 2024-2025: Mitgliedstaaten-Implementierung
- Fortlaufend: Compliance erforderlich
CRA-Zeitplan
- September 2026: Meldepflichten beginnen
- Dezember 2027: Vollständige Compliance erforderlich
- Fortlaufend: Produktlebenszyklus-Pflichten
Koordinierter Ansatz
2024 2025 2026 2027
│ │ │ │
▼ ▼ ▼ ▼
┌───────────────────────────────────────────────────────────────────────┐
│ NIS2: Organisatorische Compliance durchgehend erforderlich │
└───────────────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌───────────────────────────────┐
│CRA: Meldung │ CRA: Vollst. │
└───────────────────────────────┘
EMPFEHLUNG:
Jetzt einheitliches Cybersicherheitsprogramm aufbauen, das beiden dient.
Keine separaten NIS2- und CRA-Compliance-Programme aufbauen.
Praktische Koordinierungs-Checkliste
Governance-Integration
DUAL-REGULIERUNGS-GOVERNANCE-CHECKLISTE
ORGANISATORISCH:
[ ] Einheitliche Cybersicherheits-Governance-Struktur
[ ] Vorstandsaufsicht deckt Produkt- und Dienstsicherheit ab
[ ] Kombinierte Cybersicherheitsstrategie
[ ] Einheitliche Budgetzuweisung
RISIKOMANAGEMENT:
[ ] Integrierte Risikobewertung (Produkte + Dienste)
[ ] Kombiniertes Risikoregister
[ ] Einheitlicher Risikobehandlungsprozess
[ ] Einzelnes Risikoberichterstattungs-Framework
SCHWACHSTELLENMANAGEMENT:
[ ] Ein Schwachstellen-Eingangskanal
[ ] Kombinierter Triage-Prozess
[ ] Integrierter Behebungs-Workflow
[ ] Einheitliche Metriken und Berichterstattung
INCIDENT RESPONSE:
[ ] Kombinierter Incident-Response-Plan
[ ] Klare Weiterleitung für CRA- vs. NIS2-Meldung
[ ] Integrierte Kommunikationsverfahren
[ ] Einheitliche Post-Incident-Überprüfung
Melde-Integration
DUAL-REGULIERUNGS-MELDEMATRIX
Ereignistyp Melden unter
─────────────────────────────────────────────────────────────
Produktschwachstelle (nicht ausgenutzt) Keiner (nur CVD-Prozess)
Produktschwachstelle (ausgenutzt) CRA → ENISA
Dienst-Incident (kein Produkt) NIS2 → Nationale Behörde
Beides (Produktschwachst. → Dienst) Beide (koordinieren)
─────────────────────────────────────────────────────────────
Interne Eskalation:
1. Sicherheitsteam bewertet Ereignis
2. Bestimmen: Produktauswirkung? Dienstauswirkung?
3. An entsprechenden Meldepfad(e) weiterleiten
4. Koordinieren, wenn beide gelten
Lieferketten-Integration
EINHEITLICHE LIEFERKETTENSICHERHEIT
Für Produktkomponenten (CRA-Fokus):
- SBOM gepflegt
- Komponenten-Schwachstellenüberwachung
- Lieferanten-Sicherheitsfragebogen
- Technische Due Diligence
Für Dienstleister (NIS2-Fokus):
- Lieferanten-Risikobewertung
- Sicherheitsanforderungen in Verträgen
- Fortlaufende Überwachung
- Incident-Benachrichtigungsklauseln
INTEGRIERTER ANSATZ:
- Einzelnes Lieferantenmanagementsystem
- Kombiniertes Risikobewertungs-Framework
- Einheitliche Vertragssicherheitsanforderungen
- Koordiniertes Überwachungsprogramm
Edge Cases mit doppeltem Geltungsbereich, die genaue Abgrenzung erfordern
Industrielle Steuerungssysteme
IACS (Industrial Automation and Control Systems) stehen vor besonderer Komplexität:
- CRA: Wenn Sie IACS für wesentliche Einrichtungen (NIS2) herstellen, ist es Important Klasse II
- NIS2: Wenn Sie IACS als wesentliche Einrichtung betreiben, sind sie im Geltungsbereich
Doppelte Anforderung: Produkt muss CRA erfüllen; Betrieb muss NIS2 erfüllen.
Cloud-Dienste + Produkte
Cloud-Anbieter, die Hardware-Appliances verkaufen:
- NIS2: Cloud-Service-Betrieb
- CRA: Verkaufte Hardware-Appliances
Beispiel: Die Firewall-Appliance eines Cloud-Anbieters muss CRA erfüllen; sein Cloud-Service-Betrieb muss NIS2 erfüllen.
Gesundheits-angrenzend
Medizinprodukt-Hersteller könnten haben:
- Einige Produkte unter MDR (vom CRA ausgenommen)
- Einige Produkte unter CRA (nicht MDR-erfasst)
- Organisation unter NIS2 (Gesundheitssektoreinrichtung)
Sorgfältige Abgrenzung erforderlich: Jedes Produkt der anwendbaren Regulierung zuordnen.
FAQ zu CRA und NIS2 für Produkthersteller
Wann löst ein Ereignis sowohl CRA- als auch NIS2-Meldepflichten aus?
Wenn eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt gleichzeitig einen erheblichen Incident verursacht, der Ihre Dienste beeinträchtigt. Die CRA-Meldepflicht wird durch die ausgenutzte Produktschwachstelle ausgelöst: Sie erstatten innerhalb von 24 Stunden eine Frühwarnung an ENISA, gefolgt von einer 72-Stunden-Meldung. Die NIS2-Meldepflicht wird separat ausgelöst, wenn Ihre Dienste beeinträchtigt sind: Sie erstatten Bericht an Ihre nationale zuständige Behörde oder Ihr CSIRT nach demselben 24/72-Stunden-Schema. Die beiden Berichte betreffen unterschiedliche Sachverhalte. Der CRA-Bericht konzentriert sich auf das Produkt und die Schwachstelle. Der NIS2-Bericht konzentriert sich auf die Auswirkungen auf den Dienst und Ihre Reaktion. Beide können für dasselbe Ausgangsereignis erforderlich sein.
Wer erstattet den Bericht, wenn der Hersteller auch eine wesentliche Einrichtung ist?
Sie erstatten beide Berichte, und zwar getrennt voneinander. Als Produkthersteller melden Sie die ausgenutzte Schwachstelle gemäß CRA an ENISA. Als wesentliche Einrichtung melden Sie den Dienstvorfall gemäß NIS2 an Ihre nationale zuständige Behörde oder Ihr CSIRT. Die beiden Meldungen sind voneinander unabhängig: unterschiedliche Formulare, unterschiedliche Empfänger, in manchen Fällen unterschiedliche Fristen. Legen Sie vor einem Vorfall für jeden Meldepfad einen namentlich benannten Verantwortlichen fest. Gehen Sie nicht davon aus, dass eine Meldung die andere ersetzt.
Kann ein einziges Risikoregister sowohl für CRA als auch für NIS2 dienen?
Ja, wenn es Produktrisiken von organisatorischen Risiken trennt. Strukturieren Sie das Register so, dass Risiken auf Produktebene (Komponentenschwachstellen, Update-Fehler, Konformitätslücken) klar von organisatorischen Risiken (Dienstkontinuität, Governance-Versagen, Lieferkettenstörungen) unterschieden werden. Beide Risikoarten können im selben Dokument stehen und eine gemeinsame Bewertungsmethodik teilen. Was nicht zusammengeführt werden kann, ist die Behandlung: Die CRA-Risikobehandlung führt zu Produktkontrollen und Aktualisierungen der technischen Dokumentation; die NIS2-Risikobehandlung führt zu organisatorischen Maßnahmen und Richtlinienänderungen. Halten Sie die Einträge getrennt, damit jede Prüfung das Benötigte findet.
Wie sollte die Sorgfaltsprüfung bei Lieferanten für Komponenten und Dienstleister unterschiedlich sein?
Bei Produktkomponenten gemäß CRA ist die Sorgfaltsprüfung technischer Natur: Sie benötigen ein SBOM, das die Komponente abdeckt, Nachweise zur Schwachstellenüberwachung durch den Lieferanten sowie eine vertragliche Verpflichtung, Sie innerhalb eines definierten Zeitfensters über ausnutzbare Schwachstellen zu informieren. Bei Dienstleistern gemäß NIS2 ist die Sorgfaltsprüfung organisatorischer Natur: Sie bewerten deren Sicherheits-Governance, Incident-Response-Fähigkeit, Geschäftskontinuität und ob sie die NIS2-Sicherheitsmaßnahmen erfüllen, die für Ihren Sektor gelten. Beide Typen können eine gemeinsame Fragebogenvorlage verwenden, aber die Bewertungskriterien und die Vertragsklauseln sind unterschiedlich.
Welche Nachweise sollten aufbewahrt werden, um koordinierte Compliance über beide Regime zu belegen?
Bewahren Sie drei Dinge auf. Erstens ein Zuordnungsdokument, das zeigt, welche internen Prozesse welcher regulatorischen Verpflichtung dienen, damit ein Prüfer jede CRA- oder NIS2-Anforderung einer bestimmten Maßnahme zuordnen kann. Zweitens Vorfallsprotokolle, die belegen, dass beide Meldepfade korrekt ausgelöst wurden, wenn Ereignisse die Voraussetzungen erfüllten, mit Zeitstempeln und Empfangsbestätigungen. Drittens Vorstands- oder Managementberichte, die sowohl Produktsicherheit als auch organisatorische Sicherheit unter einer einheitlichen Governance-Struktur abdecken und zeigen, dass die Aufsicht vereint ist. Wenn Sie im selben Jahr unter CRA und NIS2 geprüft werden, belegen diese Nachweise, dass Sie ein Programm betreiben, nicht zwei voneinander getrennte.
Wie wirken sich nationale NIS2-Umsetzungsunterschiede auf einen grenzüberschreitenden Hersteller aus?
NIS2 ist eine Richtlinie und keine Verordnung, was bedeutet, dass jeder EU-Mitgliedstaat sie in nationales Recht umsetzt. Die Kernpflichten (Risikomanagement, Meldung von Vorfällen, Lieferkettensicherheit) sind einheitlich, aber die zuständige Behörde, die Sektorschwellenwerte und manchmal die Strafstruktur unterscheiden sich je nach Land. Ein Hersteller, der in Deutschland, Frankreich und Polen tätig ist, muss ermitteln, welche nationale Behörde jede Einrichtung beaufsichtigt, sich bei der richtigen Stelle in jedem Land registrieren und NIS2-Vorfallmeldungen an das richtige nationale CSIRT weiterleiten. Der CRA hingegen ist eine Verordnung und gilt einheitlich in der gesamten EU. Wenn Sie ein Produkt in einem EU-Land verkaufen, gelten dieselben CRA-Pflichten.
Nächste Schritte
Beginnen Sie damit, zu prüfen, ob Ihr Unternehmen sowohl Produkthersteller als auch wesentliche oder wichtige Einrichtung gemäß NIS2 ist. Verwenden Sie den Leitfaden zur Produktklassifizierung, um jedes Produkt seiner CRA-Klasse zuzuordnen. Erfassen Sie dann Produktrisiken und Dienstrisiken getrennt in einem einzigen Register, das sie klar unterscheidet. Legen Sie die internen Meldeauslöser für CRA und NIS2 fest und bestimmen Sie einen namentlich benannten Verantwortlichen für jeden Pfad. Harmonisieren Sie Ihre Lieferanten- und Schwachstellen-Eingangsworkflows, damit beide Lieferantentypen über einen einzigen Prozess laufen. Einen vollständigen Überblick über CRA-Fristen finden Sie im CRA-Umsetzungszeitplan. Führen Sie dann eine gemeinsame Tabletop-Übung durch, die einen Produktvorfall simuliert, der auch Ihre Dienste betrifft: So decken Sie Lücken in Ihrer Reaktion auf doppelten Geltungsbereich auf, bevor ein echtes Ereignis dies tut.
Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an qualifizierte Rechtsberater.
Verwandte Artikel
Gilt der CRA für Ihr Produkt?
Beantworten Sie 6 einfache Fragen, um herauszufinden, ob Ihr Produkt unter den EU Cyber Resilience Act fällt. Erhalten Sie Ihr Ergebnis in unter 2 Minuten.
Bereit für CRA-Konformität?
Beginnen Sie mit der Verwaltung Ihrer SBOMs und Compliance-Dokumentation mit CRA Evidence.