FAQ - NIS2, CRA, ISO 27001 & BSI TR-03183

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung mit der Bezeichnung (EU) 2024/2847. Sie legt Sicherheitsanforderungen für Produkte mit digitalen Elementen fest. Das betrifft Hardware und Software, die in der EU verkauft werden. Ziel ist es, Sicherheit bereits in der Entwicklung zu verankern - nicht nachträglich.

Quelle: Verordnung (EU) 2024/2847

Der CRA gilt für Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Das umfasst Hardware-Produkte mit Software-Anteil ebenso wie reine Software-Produkte. Importeure und Händler haben ebenfalls Pflichten, wenn auch in geringerem Umfang als Hersteller.

Quelle: Verordnung (EU) 2024/2847, Art. 2

Der CRA tritt in drei Stufen in Kraft. Am 11. Dezember 2024 ist die Verordnung in Kraft getreten - die Übergangsfristen laufen seitdem. Am 11. September 2026 greift die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen. Am 11. Dezember 2027 gilt der CRA vollständig: CE-Kennzeichnung wird Pflicht, nicht-konforme Produkte dürfen nicht mehr in der EU verkauft werden.

Quelle: Verordnung (EU) 2024/2847; BSI

Security by Design ist eine der drei Kernanforderungen des CRA. Sie bedeutet: Sicherheit muss ab der Planungs- und Entwicklungsphase berücksichtigt werden. Sicherheit darf kein nachträglicher Zusatz sein. Hersteller müssen dokumentieren, wie sie Sicherheit im Entwicklungsprozess verankern.

Quelle: Verordnung (EU) 2024/2847, Anhang I

Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus identifizieren, verfolgen und beheben. Nutzer müssen über bekannte Schwachstellen informiert werden. Der Mindest-Supportzeitraum beträgt 5 Jahre. Ohne SBOM und aktives Monitoring ist die Einhaltung dieser Pflichten in der Praxis kaum möglich.

Quelle: Verordnung (EU) 2024/2847, Anhang I, Teil II

Ab dem 11. September 2026 gelten drei Fristen. Innerhalb von 24 Stunden muss eine Frühwarnung an ENISA und das zuständige nationale CSIRT erfolgen. Innerhalb von 72 Stunden ist eine vollständige Meldung erforderlich. Spätestens nach 14 Tagen ist ein Abschlussbericht einzureichen. Die Fristen beginnen ab dem Zeitpunkt der Kenntniserlangung.

Quelle: Verordnung (EU) 2024/2847, Art. 14

Ja. Der CRA verpflichtet Hersteller, eine Software Bill of Materials (SBOM) zu erstellen und bereitzuhalten. Eine SBOM listet alle Softwarekomponenten eines Produkts maschinenlesbar auf. Ohne SBOM lässt sich nicht feststellen, welche Produkte von einer bekannten Schwachstelle betroffen sind. Das macht eine gezielte Reaktion auf Vorfälle wie Log4Shell unmöglich.

Quelle: Verordnung (EU) 2024/2847, Anhang I, Teil II

NIS2 ist die zweite Fassung der EU-Richtlinie zur Netz- und Informationssicherheit. Sie ersetzt die erste NIS-Richtlinie und erweitert den Anwendungsbereich erheblich. Mitgliedstaaten mussten sie bis Oktober 2024 in nationales Recht umsetzen. In Deutschland erfolgt die Umsetzung durch das NIS2UmsuCG.

Quelle: Richtlinie (EU) 2022/2555

NIS2 gilt für Unternehmen in kritischen und wichtigen Sektoren. Die Einstufung hängt von Sektor, Mitarbeiterzahl und Umsatz ab. Betroffen sind unter anderem Energie, Transport, Gesundheit, digitale Infrastruktur, Finanzwesen und öffentliche Verwaltung. Ob ein Unternehmen betroffen ist, muss anhand des nationalen Umsetzungsgesetzes geprüft werden.

Quelle: Richtlinie (EU) 2022/2555, Art. 2 und Anhang

Erhebliche Sicherheitsvorfälle müssen in drei Stufen gemeldet werden. Innerhalb von 24 Stunden ab Kenntniserlangung ist eine Frühwarnung an die zuständige Behörde oder das CSIRT erforderlich. Innerhalb von 72 Stunden folgt eine vollständige Meldung. Nach spätestens einem Monat ist ein Abschlussbericht einzureichen.

Quelle: Richtlinie (EU) 2022/2555, Art. 23

Die Frist beginnt ab dem Zeitpunkt der Kenntniserlangung. Das bedeutet: Wird ein Vorfall nicht erkannt, beginnt die Frist nicht. Das ist jedoch kein Freifahrtschein. Wer durch fehlendes Monitoring keine Kenntnis erlangt, verstößt damit selbst gegen NIS2 - denn die Pflicht zur Erkennung ist Teil der Sicherheitsanforderungen.

Quelle: Richtlinie (EU) 2022/2555, Art. 23

Fehlende Kenntnis durch fehlendes Monitoring ist kein Schutz vor einer NIS2-Verletzung. NIS2 verlangt, dass betroffene Unternehmen die nötigen Maßnahmen treffen, um Sicherheitsvorfälle erkennen zu können - technisch wie organisatorisch. Wer kein Monitoring betreibt, erfüllt diese Anforderung nicht - unabhängig davon, ob ein Vorfall tatsächlich eintritt.

Quelle: Richtlinie (EU) 2022/2555, Art. 21

NIS2 richtet sich an Betreiber kritischer und wichtiger Dienste. Der CRA richtet sich an Hersteller von Produkten mit digitalen Elementen. Ein Unternehmen kann unter beide Regelwerke fallen - zum Beispiel ein Hersteller von Industriesteuerungen, der selbst Teil kritischer Infrastruktur ist. Die Meldepflichten überschneiden sich, unterscheiden sich aber in Empfänger und Detail.

Quelle: Richtlinie (EU) 2022/2555; Verordnung (EU) 2024/2847

Die BSI TR-03183 ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik. Sie beschreibt, wie Hersteller die Anforderungen des CRA technisch umsetzen können. Die Richtlinie besteht aus drei Teilen: Teil 1 behandelt allgemeine Anforderungen, Teil 2 beschreibt SBOM-Anforderungen, Teil 3 regelt Schwachstellen-Reports und Notifications. Alle drei Teile sind kostenlos beim BSI verfügbar.

Quelle: BSI TR-03183

Formal ist die TR-03183 eine Technische Richtlinie - kein verbindliches Gesetz. Für CRA-pflichtige Hersteller ist sie in der Praxis jedoch verbindlich: Wer sich an TR-03183 hält, erfüllt die wesentlichen technischen Anforderungen des CRA. Die Richtlinie als "freiwillig" zu beschreiben ist daher irreführend.

Quelle: BSI TR-03183; Verordnung (EU) 2024/2847

TR-03183-3 behandelt Schwachstellen-Reports und Notifications. Sie beschreibt den Prozess der Coordinated Vulnerability Disclosure, legt den Inhalt von Schwachstellen-Meldungen fest und regelt das Vorgehen nach Bekanntwerden einer Schwachstelle. Hersteller, die sich an TR-03183-3 halten, erfüllen die wesentlichen Anforderungen aus CRA Art. 14 - also die 24h-Frühwarnung, die 72h-Vollmeldung und den 14-Tage-Abschlussbericht.

Quelle: BSI TR-03183-3; Verordnung (EU) 2024/2847, Art. 14

Die ENISA Single Reporting Platform wird ab September 2026 Schwachstellen-Meldungen verarbeiten. CSAF ist das vorgesehene Format für maschinenlesbare Meldungen. CSAF deckt die Pflichtfelder aus CRA Art. 14 ab: Hersteller, betroffene Produkte, Schwachstelle, CVSS-Score und Patch-Status. Hersteller, die ab 2026 meldepflichtig sind, sollten das Format frühzeitig kennen.

Quelle: Verordnung (EU) 2024/2847, Art. 14; OASIS CSAF 2.0

Eine CSAF-Datei ist ein JSON-Dokument mit definierten Pflichtfeldern. Dazu gehören Angaben zum Hersteller, zu betroffenen Produkten und Versionen, zur Schwachstelle selbst (inkl. CVE-Nummer und CVSS-Score) sowie zum Status eines verfügbaren Patches. CSAF ist maschinenlesbar und kann direkt in SIEM-Systeme und Schwachstellen-Management-Tools importiert werden.

Quelle: OASIS CSAF 2.0

Ein Risikoregister ist die dokumentierte Übersicht aller identifizierten Informationssicherheitsrisiken einer Organisation - mit Bewertung nach Eintrittswahrscheinlichkeit und Schadenshöhe, gewählter Behandlungsoption und Verantwortlichkeit. ISO/IEC 27001:2022 verlangt es in Kap. 6.1.2 und 6.1.3 als Nachweis, dass Risikobewertung und -behandlung tatsächlich stattgefunden haben - es ist eines der beiden zwingend vorgeschriebenen ISMS-Dokumente.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.2 und 6.1.3

Das Statement of Applicability (SoA) ist das Dokument, in dem eine Organisation für jeden der 93 Referenz-Controls aus ISO/IEC 27001:2022 Anhang A festhält, ob er angewendet wird, warum, und wie weit die Umsetzung fortgeschritten ist. Zusammen mit dem Risikoregister ist es das zweite zwingend vorgeschriebene ISMS-Dokument nach Kap. 6.1.3 d) und faktisch das Inhaltsverzeichnis jedes Zertifizierungsaudits.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.3 d)

Ja - bewerten, aber nicht zwingend umsetzen. Für jeden der 93 Controls muss dokumentiert sein, ob er anwendbar ist. Nicht anwendbare Controls dürfen ausgeschlossen werden, aber nur mit nachvollziehbarer Begründung - typischerweise, weil kein zugehöriges Risiko im Risikoregister vorliegt oder die betroffene Tätigkeit gar nicht stattfindet. Ein unbegründeter Ausschluss ist im Zertifizierungsaudit ein klassischer Findungspunkt.

Quelle: ISO/IEC 27001:2022, Anhang A

Pro Risiko: die betroffenen Werte (Assets), Bedrohung und Schwachstelle, eine Bewertung nach Eintrittswahrscheinlichkeit und Schadenshöhe (meist per Risikomatrix), die gewählte Behandlungsoption - vermindern, vermeiden, verlagern oder akzeptieren -, einen namentlich Verantwortlichen und eine Umsetzungsfrist. Bei kritischen, akzeptierten Risiken verlangt eine saubere Dokumentation zusätzlich eine schriftliche Freigabe durch die Geschäftsführung.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.2 und 6.1.3

Anhang A ist Teil der zertifizierbaren Norm ISO/IEC 27001 und listet zu jedem der 93 Controls nur Nummer und Kurztitel - als feste, prüfbare Referenz für Auditoren. Die vollständige Beschreibung, den Zweck und konkrete Umsetzungsempfehlungen zu jedem Control liefert die eigenständige, informative Norm ISO/IEC 27002:2022. Für die Umsetzung im Alltag ist 27002 die praktische Arbeitsgrundlage, für die Zertifizierung zählt der Bezug auf Anhang A im SoA.

Quelle: ISO/IEC 27001:2022, Anhang A; ISO/IEC 27002:2022