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.

CRA Evidence-Team Veröffentlicht 15. Januar 2026 Aktualisiert 11. April 2026
CRA und NIS2: Wo sich Cybersicherheitsvorschriften für Produktunternehmen überschneiden
In diesem Artikel

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 Venn-Diagramm zum Geltungsbereichsvergleich

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.

CRA Compliance
Share

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.