CRA und NIS2: Wo sich Cybersicherheitsvorschriften für Produktunternehmen überschneiden

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.

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

┌─────────────────────────────────────────────────────────────┐
│                    IHRE ORGANISATION                         │
│                                                              │
│  ┌──────────────────────┐    ┌──────────────────────┐       │
│  │  NIS2-GELTUNGSBEREICH│    │  CRA-GELTUNGSBEREICH │       │
│  │                      │    │                      │       │
│  │ - Ihre IT-Systeme    │    │ - Produkte, die Sie  │       │
│  │ - Ihre Dienste       │    │   herstellen         │       │
│  │ - Ihr Betrieb        │    │ - Produkte, die Sie  │       │
│  │ - Ihre Lieferkette   │    │   importieren        │       │
│  │   (als Beschaffer)   │    │ - Produkte, die Sie  │       │
│  │                      │    │   vertreiben         │       │
│  │        ┌─────────────┴────┴───────────┐         │       │
│  │        │     ÜBERSCHNEIDUNG           │         │       │
│  │        │                              │         │       │
│  │        │ - Schwachstellenmanagement   │         │       │
│  │        │ - 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

Koordinierungschance: Einheitliches Schwachstellenmanagement-Programm, das sowohl Produkte als auch organisatorische Systeme abdeckt.

Incident-Meldung

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

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

Harmonisierungsmöglichkeiten

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

Dokumentationseffizienz

Manche Dokumentation kann beiden dienen:

Unterschiedliche Durchsetzung

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

Besondere Erwägungen

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.

Häufige Fragen

Melde ich denselben Incident zweimal?

Normalerweise nicht. CRA und NIS2 haben unterschiedliche Auslöser:

• CRA: Aktiv ausgenutzte Schwachstelle in Ihrem Produkt
• NIS2: Erheblicher Incident, der Ihre Dienste betrifft

Wenn eine ausgenutzte Produktschwachstelle einen Dienst-Incident verursacht, müssen Sie möglicherweise unter beiden melden. Die Berichte gehen jedoch an unterschiedliche Empfänger und konzentrieren sich auf unterschiedliche Aspekte.

Kann NIS2-Compliance CRA-Anforderungen abdecken?

Teilweise. Starke NIS2-Compliance demonstriert:

• Sicherheits-Governance-Fähigkeit
• Schwachstellenmanagement-Reife
• Incident-Response-Fähigkeit

Aber CRA hat produktspezifische Anforderungen (SBOM, Konformitätsbewertung, CE-Kennzeichnung), die NIS2 nicht abdeckt.

Kann CRA-Compliance NIS2-Anforderungen abdecken?

Nein. CRA ist produktfokussiert. NIS2 verlangt:

• Organisatorisches Risikomanagement
• Business Continuity
• Lieferkettensicherheit (breiter als Produktkomponenten)
• Governance-Maßnahmen

Welche ist anspruchsvoller?

Unterschiedlicher Geltungsbereich, unterschiedliche Anforderungen:

Keine ist strikt "anspruchsvoller", da sie unterschiedliche Dinge fordern.

Verwandte Leitfäden:

• EU Cyber Resilience Act: Vollständiger Umsetzungszeitplan 2025-2027
• CRA-Strafen in der Praxis: Wie Marktüberwachung tatsächlich aussieht

Wie CRA Evidence hilft

CRA Evidence unterstützt Organisationen, die beiden Verordnungen unterliegen:

• Produktfokus: Vollständige CRA-Compliance-Fähigkeiten
• Integrationsfähig: Schwachstellenmanagement-Daten exportierbar
• SBOM-Management: Dient CRA direkt, unterstützt NIS2-Lieferkette
• Incident-Tracking: Kann an entsprechende Meldepfade weiterleiten
• Dokumentation: Zentralisiert für regulatorische Anfragen

Verwalten Sie Ihre Produkt-Compliance bei app.craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an qualifizierte Rechtsberater.