Zum Inhalt springen
← Alle Produktkategorien
Wichtiges Produkt - Klasse II

Firewalls und Intrusion-Detection-/-Prevention-Systeme

Firewalls, IDS und IPS. (Anhang III Klasse II Nr. 2)

CRA-Werkzeugkette · Schritt 03 von 07

Scope & KlasseProduktanforderungen (Sie sind hier)CVD-Policyalle 7 Schritte

Konkrete Umsetzung für Firewalls und Intrusion-Detection-/-Prevention-Systeme

Für Firewalls und Intrusion-Detection-/-Prevention-Systeme gelten alle 37 Anforderungen aus Anhang I, Anhang II und den zentralen Herstellerpflichten der Verordnung (EU) 2024/2847 - besonders schwer wiegen dabei Schutz der Verfügbarkeit wesentlicher Funktionen, Begrenzung der Angriffsfläche, Protokollierung sicherheitsrelevanter Aktivität. Jede Anforderung unten zeigt konkrete Umsetzungsschritte, den Nachweis für die technische Dokumentation und passende Werkzeuge - kostenlose CyberKlartext-Tools ebenso wie etablierte Open-Source-Hilfsmittel.

Wichtiges Produkt - Klasse II

Dein Produkt

Scope-Check: Gilt der CRA für dieses Produkt?

Um welche Art von Produkt handelt es sich?

Der CRA gilt für 'Produkte mit digitalen Elementen' - Software oder Hardware, die mit einem Netzwerk verbunden werden kann.

Verbindet sich Ihr Produkt mit einem Netzwerk (Internet, LAN, Bluetooth, Zigbee o. Ä.)?

Netzwerkkonnektivität ist ein zentraler Auslöser für die Anwendbarkeit des CRA.

Wird Ihr Produkt kommerziell auf dem EU-Markt bereitgestellt (verkauft, lizenziert oder verteilt - auch kostenlos)?

Wird Ihr Produkt ausschließlich intern innerhalb einer einzigen juristischen Person genutzt und nie an Dritte weitergegeben, lizenziert oder als Open Source veröffentlicht?

Eine enge Ausnahme: Lizenzierung an verbundene Unternehmen oder eine kostenlose öffentliche Veröffentlichung zählt bereits als Bereitstellung am Markt.

Ist Ihr Produkt bereits durch eine andere EU-Verordnung mit Cybersicherheitsanforderungen abgedeckt?

Sektorregulierung verdrängt den CRA nur so weit, wie sie gleichwertige Anforderungen regelt - bei Überschneidung ist eine rechtliche Einzelprüfung nötig.

Produktkontext

Wer sind die primären Nutzer Ihres Produkts?

Verarbeitet, speichert oder überträgt Ihr Produkt sensible Daten (personenbezogene Daten, Zugangsdaten, Finanzdaten, OT-Daten)?

Verfügt Ihr Produkt über Fernwartungs-, Fernzugriffs- oder Administrationsfunktionen?

Enthält Ihr Produkt Dritt- oder Open-Source-Softwarekomponenten oder ist davon abhängig?

Ist Ihr Produkt für sicherheitskritische Anwendungen oder den Einsatz in Betriebstechnik (OT) ausgelegt?

Organisation & Branding (für PDF-Export)optional

Name und Logo erscheinen in der Kopfzeile aller serverseitig erzeugten PDFs (ISMS-Dokumente, Security-Audit- und CRA-Klartext-Bericht). Die Angaben bleiben nur in diesem Browser gespeichert.

Logo

0%

Anteil erfüllter Anforderungen (37 von 37 bewertet)

Anhang I Teil I: 0/14Anhang I Teil II: 0/8Anhang II: 0/9Zentrale Herstellerpflicht: 0/6

In 30 Tagen (13)

In 90 Tagen (15)

In 180 Tagen (9)

0 von 37 Anforderungen noch offen oder in Arbeit.

Anforderungen

37 Anforderungen aus Anhang I und II sowie zentrale Herstellerpflichten. Status und Nachweis werden automatisch gespeichert. Für firewalls und intrusion-detection-/-prevention-systeme besonders scharf markierte Anforderungen (★) stehen jeweils oben.

Zentrale Herstellerpflicht

Cybersicherheitsrisikobewertung durchführen und dokumentierenGrundlage für nahezu alle produktbezogenen Anforderungen. Die Risikobewertung ist bei Planung, Design, Entwicklung, Produktion, Lieferung und Wartung zu berücksichtigen und zu dokumentieren; sie ist Teil der technischen Dokumentation nach Anhang VII.Art. 13(2)
Status für Cybersicherheitsrisikobewertung durchführen und dokumentieren
Umsetzung & Nachweis

Umsetzung

  • TARA für das Produkt durchführen
  • Ergebnis in Anhang-VII-Dokumentation aufnehmen und bei Änderungen aktualisieren

Nachweis für die technische Dokumentation

  • Risikobewertungsdokument als Teil der technischen Dokumentation

BSI TR-03183-1 (Kap. 5.8-5.13): Vollständiger Ablauf: Identifikation, Analyse, Bewertung, Behandlung, Dokumentation, Aktualisierung.

CyberRisk Canvas →ISMS-Risikoregister →OWASP Threat Dragon →Glossar: tara →Glossar: stride →
Supportzeitraum festlegen (mindestens 5 Jahre oder erwartete Nutzungsdauer)Der Supportzeitraum muss der erwarteten Nutzungsdauer des Produkts entsprechen, mindestens jedoch fünf Jahre betragen - es sei denn, die erwartete Nutzungsdauer ist kürzer.Art. 13(8)
Status für Supportzeitraum festlegen (mindestens 5 Jahre oder erwartete Nutzungsdauer)
Umsetzung & Nachweis

Umsetzung

  • Erwartete Nutzungsdauer ermitteln und Supportzeitraum entsprechend festlegen
  • Supportzeitraum in Anhang II kommunizieren

Nachweis für die technische Dokumentation

  • Dokumentierte Herleitung des Supportzeitraums

BSI TR-03183-1 (Kap. 3.6): Einordnung des Supportzeitraums im Gesamtzusammenhang der Herstellerpflichten.

CRA-Klartext →
Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende VorfälleAktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind an ENISA und die zuständige CSIRT zu melden: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen (ab 11.09.2026 anwendbar).Art. 14
Status für Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle
Umsetzung & Nachweis

Umsetzung

  • Meldeprozess mit Verantwortlichkeiten und Fristen etablieren
  • Kontaktwege zu ENISA/CSIRT vorab klären

Nachweis für die technische Dokumentation

  • Meldeprozess-Dokumentation
  • Nachweis über Testlauf/Übung

BSI TR-03183-3 (Kap. 3.1.4-3.1.7, Kap. 4.4.2): Meldeprozess und Zusammenarbeit mit dem zuständigen nationalen CSIRT (in Deutschland: CERT-Bund).

CSAF Studio →ISMS-Handbuch →Glossar: csaf →
Technische Dokumentation nach Anhang VII führenDie technische Dokumentation muss Produktbeschreibung, Risikobewertung, Nachweis der Erfüllung der Anhang-I-Anforderungen, angewandte Normen und Testberichte enthalten und vor Markteinführung erstellt sowie über den Supportzeitraum gepflegt werden.Art. 31, Anhang VII
Status für Technische Dokumentation nach Anhang VII führen
Umsetzung & Nachweis

Umsetzung

  • Technische Dokumentation strukturiert aufbauen und laufend aktualisieren

Nachweis für die technische Dokumentation

  • Vollständige technische Dokumentation

BSI TR-03183-1 (Kap. 4.8): Pflichtinhalt des Assessment-Reports: Risikobewertung, Kontrollauswahl, Testnachweise, offene Punkte.

ISMS-Dokumentation →CRA-Klartext →
EU-Konformitätserklärung erstellen und CE-Kennzeichnung anbringenNach erfolgreicher Konformitätsbewertung erstellt der Hersteller die EU-Konformitätserklärung nach Anhang V und bringt die CE-Kennzeichnung auf dem Produkt an.Art. 28, 30; Anhang V
Status für EU-Konformitätserklärung erstellen und CE-Kennzeichnung anbringen
Umsetzung & Nachweis

Umsetzung

  • Konformitätsbewertungsverfahren abschließen
  • EU-Konformitätserklärung nach Anhang V ausfüllen
  • CE-Kennzeichnung anbringen

Nachweis für die technische Dokumentation

  • Unterzeichnete EU-Konformitätserklärung
EU-Konformitätserklärung-Generator →Glossar: ce-kennzeichnung →Glossar: konformitaetsbewertung →
Auslöser für wesentliche Änderungen zur erneuten BewertungEine wesentliche Änderung ist eine Änderung des Produkts nach dessen Inverkehrbringen, die sich auf die Konformität mit den Anforderungen auswirkt oder den vorgesehenen Zweck verändert. Bei einer wesentlichen Änderung sind Risikobewertung und Konformitätsprüfung erneut durchzuführen - ohne einen definierten Auslöser dafür kann ein einmal konformes Produkt unbemerkt aus der Konformität herausdriften.Art. 3(32), 13(2), 31
Status für Auslöser für wesentliche Änderungen zur erneuten Bewertung
Umsetzung & Nachweis

Umsetzung

  • Kriterien für wesentliche Änderungen im Änderungsmanagement dokumentieren
  • Checkliste einrichten, die bei einer wesentlichen Änderung automatisch die erneute Risikobewertung auslöst

Nachweis für die technische Dokumentation

  • Änderungsmanagement-Richtlinie mit Kriterien
  • An Änderungsanträge gekoppelte Checkliste zur Risiko-Neubewertung
CyberRisk Canvas →ISMS-Handbuch →Glossar: tara →

Anhang I Teil I - Produkteigenschaften

★ Schutz der Verfügbarkeit wesentlicher FunktionenWesentliche Funktionen müssen auch bei Sicherheitsvorfällen verfügbar bleiben, einschließlich Widerstandsfähigkeit gegen Denial-of-Service-Angriffe.Anhang I Teil I Nr. 2 Buchst. h
Status für ★ Schutz der Verfügbarkeit wesentlicher Funktionen
Umsetzung & Nachweis

Umsetzung

  • Kritische Funktionen identifizieren und redundant auslegen, soweit angemessen
  • Schutzmaßnahmen gegen DoS-Angriffe implementieren

Nachweis für die technische Dokumentation

  • Verfügbarkeitskonzept
  • Testergebnisse zu Lastszenarien
ISMS Statement of Applicability →IT-Sicherheits-Audit →
★ Begrenzung der AngriffsflächeDas Produkt ist so zu konzipieren, dass Angriffsflächen, einschließlich externer Schnittstellen, minimiert werden.Anhang I Teil I Nr. 2 Buchst. j
Status für ★ Begrenzung der Angriffsfläche

Für Industrieausführungen zusätzlich die OT-Variante (prEN 50770-1) prüfen.

Umsetzung & Nachweis

Umsetzung

  • Nicht benötigte Dienste, Ports und Schnittstellen deaktivieren
  • Angriffsflächenanalyse in die Designphase integrieren

Nachweis für die technische Dokumentation

  • Angriffsflächenanalyse
Domain-Sicherheitscheck →IT-Sicherheits-Audit →
★ Protokollierung sicherheitsrelevanter AktivitätSicherheitsrelevante interne Aktivität, einschließlich Zugriff auf oder Änderung von Daten, Diensten oder Funktionen, ist aufzuzeichnen bzw. zu überwachen - mit Opt-out für Nutzer.Anhang I Teil I Nr. 2 Buchst. l
Status für ★ Protokollierung sicherheitsrelevanter Aktivität
Umsetzung & Nachweis

Umsetzung

  • Protokollierung sicherheitsrelevanter Ereignisse implementieren
  • Abschaltmöglichkeit für Nutzer vorsehen, wo angemessen

Nachweis für die technische Dokumentation

  • Logging-Konzept
ISMS Statement of Applicability →
Angemessenes Cybersicherheitsniveau auf Basis der RisikobewertungDas Produkt muss so konzipiert, entwickelt und hergestellt werden, dass es ein dem jeweiligen Risiko angemessenes Cybersicherheitsniveau bietet. Maßstab ist die Risikobewertung nach Art. 13(2), nicht eine feste Checkliste.Anhang I Teil I Nr. 1
Status für Angemessenes Cybersicherheitsniveau auf Basis der Risikobewertung
Umsetzung & Nachweis

Umsetzung

  • Cybersicherheitsrisikobewertung für das konkrete Produkt durchführen und dokumentieren
  • Ergebnis der Risikobewertung in Design-Entscheidungen und Anforderungen a-m einfließen lassen
  • Risikobewertung bei wesentlichen Änderungen aktualisieren

Nachweis für die technische Dokumentation

  • Dokumentierte Risikobewertung
  • Ableitung der übrigen Anforderungen daraus

BSI TR-03183-1 (Kap. 5, Kap. 5.14): Risikobasierter Ansatz nach ISO 31000 und Entscheidungskriterien für die Kontrollauswahl.

CyberRisk Canvas →ISMS-Risikoregister →OWASP Threat Dragon →Glossar: tara →Glossar: stride →
Keine bekannten ausnutzbaren Schwachstellen bei MarkteinführungDas Produkt darf nicht mit bekannten, ausnutzbaren Schwachstellen auf den Markt gebracht werden.Anhang I Teil I Nr. 2 Buchst. a
Status für Keine bekannten ausnutzbaren Schwachstellen bei Markteinführung
Umsetzung & Nachweis

Umsetzung

  • Schwachstellenscans und Penetrationstests vor Freigabe durchführen
  • Bekannte Schwachstellen in Drittkomponenten vor Release beheben oder kompensieren

Nachweis für die technische Dokumentation

  • Testberichte
  • Freigabeprotokoll mit Schwachstellenstatus

BSI TR-03183-1 (Kap. 4.3, Kap. 4.6): Zeitpunkt der Bewertung: Werkszustand nach Erstkonfiguration, auf der aktuellsten Version.

IT-Sicherheits-Audit →Advisories & Vendor-Watchlist →OWASP ZAP →Trivy →Glossar: cve →Glossar: kev →
Sichere StandardkonfigurationDas Produkt muss ab Werk mit einer sicheren Standardkonfiguration ausgeliefert werden, sofern nicht mit dem gewerblichen Nutzer anders vereinbart.Anhang I Teil I Nr. 2 Buchst. b
Status für Sichere Standardkonfiguration
Umsetzung & Nachweis

Umsetzung

  • Unsichere Werkseinstellungen (Standardpasswörter, offene Ports, deaktivierte Verschlüsselung) identifizieren und abstellen
  • Härtungsleitfaden für abweichende Konfigurationen bereitstellen

Nachweis für die technische Dokumentation

  • Konfigurationsstandard
  • Härtungsleitfaden
ISMS Statement of Applicability →ISMS Audit-Checkliste →CIS Benchmarks →
Behebbarkeit von Schwachstellen durch SicherheitsupdatesSchwachstellen müssen sich durch Sicherheitsupdates beheben lassen, wo technisch möglich automatisch mit klarer Opt-out-Möglichkeit und Benachrichtigung.Anhang I Teil I Nr. 2 Buchst. c
Status für Behebbarkeit von Schwachstellen durch Sicherheitsupdates
Umsetzung & Nachweis

Umsetzung

  • Update-Mechanismus implementieren, der Sicherheitsupdates von Funktionsupdates trennt
  • Automatische Installation als Standard vorsehen, mit Opt-out und Benachrichtigung

Nachweis für die technische Dokumentation

  • Update-Architektur-Dokumentation
  • Beschreibung des Opt-out-Mechanismus

BSI TR-03183-1 (Anhang B, ER.4 / ER.4a-d): Konkretisiert die Update-Anforderung inkl. Opt-out und Benachrichtigung.

CSAF Studio →Glossar: csaf →
Schutz vor unbefugtem ZugriffAngemessene Kontrollmechanismen wie Authentisierung, Identitäts- oder Zugriffsmanagement müssen unbefugten Zugriff verhindern und diesen melden.Anhang I Teil I Nr. 2 Buchst. d
Status für Schutz vor unbefugtem Zugriff
Umsetzung & Nachweis

Umsetzung

  • Authentisierung und Zugriffskontrolle nach dem Prinzip der geringsten Rechte einführen
  • Meldung von Zugriffsversuchen an berechtigte Stellen vorsehen

Nachweis für die technische Dokumentation

  • Zugriffskonzept
  • Nachweis der Authentisierungsmechanismen
ISMS Statement of Applicability →
Vertraulichkeit gespeicherter und übertragener DatenGespeicherte, übertragene oder anderweitig verarbeitete Daten sind durch Verschlüsselung nach dem Stand der Technik zu schützen, soweit anwendbar.Anhang I Teil I Nr. 2 Buchst. e
Status für Vertraulichkeit gespeicherter und übertragener Daten
Umsetzung & Nachweis

Umsetzung

  • Verschlüsselung sensibler Daten at rest und in transit einführen
  • Kryptografische Verfahren nach anerkanntem Stand der Technik auswählen

Nachweis für die technische Dokumentation

  • Kryptografiekonzept
  • Liste eingesetzter Verfahren und Schlüssellängen
ISMS Statement of Applicability →
Integrität von Daten, Befehlen und KonfigurationGespeicherte, übertragene oder verarbeitete Daten sowie Befehle, Programme und Konfiguration sind vor unbefugter Manipulation zu schützen.Anhang I Teil I Nr. 2 Buchst. f
Status für Integrität von Daten, Befehlen und Konfiguration
Umsetzung & Nachweis

Umsetzung

  • Integritätsprüfungen (Signaturen, Prüfsummen) für Firmware, Updates und Konfiguration einführen
  • Manipulationserkennung bei sicherheitsrelevanten Änderungen vorsehen

Nachweis für die technische Dokumentation

  • Beschreibung der Integritätsmechanismen
ISMS Statement of Applicability →
DatenminimierungEs dürfen nur Daten verarbeitet werden, die für den vorgesehenen Zweck angemessen, relevant und erforderlich sind.Anhang I Teil I Nr. 2 Buchst. g
Status für Datenminimierung
Umsetzung & Nachweis

Umsetzung

  • Datenflüsse des Produkts inventarisieren
  • Nicht erforderliche Datenerhebung und -speicherung abschalten

Nachweis für die technische Dokumentation

  • Datenflussübersicht mit Zweckbindung
ISMS-Handbuch →
Keine negativen Auswirkungen auf andere Geräte und NetzeDas Produkt darf die Verfügbarkeit von Diensten anderer Geräte oder Netze nicht unnötig beeinträchtigen.Anhang I Teil I Nr. 2 Buchst. i
Status für Keine negativen Auswirkungen auf andere Geräte und Netze
Umsetzung & Nachweis

Umsetzung

  • Netzwerkverhalten des Produkts (Traffic, Ressourcenverbrauch) begrenzen und testen

Nachweis für die technische Dokumentation

  • Testbericht zum Netzwerkverhalten
Domain-Sicherheitscheck →
Minderung der Auswirkungen eines VorfallsGeeignete Mechanismen zur Ausnutzungsminderung (z. B. Exploit-Mitigation-Techniken) sollen die Auswirkungen eines Sicherheitsvorfalls begrenzen.Anhang I Teil I Nr. 2 Buchst. k
Status für Minderung der Auswirkungen eines Vorfalls
Umsetzung & Nachweis

Umsetzung

  • Exploit-Mitigation-Techniken (z. B. Speicherschutz, Sandboxing) einsetzen, soweit für die Plattform verfügbar

Nachweis für die technische Dokumentation

  • Beschreibung eingesetzter Mitigation-Techniken
ISMS Statement of Applicability →
Sicheres, dauerhaftes Entfernen von DatenNutzer müssen alle Daten und Einstellungen sicher und einfach dauerhaft löschen können; bei Übertragung an andere Produkte oder Systeme muss dies sicher erfolgen.Anhang I Teil I Nr. 2 Buchst. m
Status für Sicheres, dauerhaftes Entfernen von Daten
Umsetzung & Nachweis

Umsetzung

  • Funktion zum vollständigen, sicheren Zurücksetzen/Löschen implementieren
  • Sichere Datenübertragung bei Produktwechsel vorsehen, falls angeboten

Nachweis für die technische Dokumentation

  • Beschreibung der Löschfunktion
ISMS Statement of Applicability →

Anhang I Teil II - Schwachstellenbehandlung

Komponenten identifizieren und dokumentieren (SBOM)Hersteller müssen die im Produkt enthaltenen Komponenten identifizieren und dokumentieren, unter anderem durch eine Software Bill of Materials in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.Anhang I Teil II Nr. 1
Status für Komponenten identifizieren und dokumentieren (SBOM)
Umsetzung & Nachweis

Umsetzung

  • SBOM in CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 generieren, als JSON oder XML
  • Elf Pflichtfelder je Komponente abdecken, u. a. SHA-512-Prüfsumme und Lizenzangabe
  • SBOM über den gesamten Supportzeitraum aktuell halten

Nachweis für die technische Dokumentation

  • SBOM-Datei
  • Prozessbeschreibung zur SBOM-Pflege

BSI TR-03183-2 (Kap. 4, Kap. 5.1, Kap. 5.2): Zulässige Formate, Detailtiefe und die elf Pflichtfelder je Komponente.

BSI TR-03183 Glossareintrag →Syft →cdxgen →Glossar: sbom →Glossar: bsi-tr-03183 →
Schwachstellen unverzüglich behebenIdentifizierte Schwachstellen, auch in Drittkomponenten, sind unverzüglich zu beheben oder zu mindern; Fixes sind nach Möglichkeit an vorgelagerte Maintainer weiterzugeben.Anhang I Teil II Nr. 2
Status für Schwachstellen unverzüglich beheben
Umsetzung & Nachweis

Umsetzung

  • Priorisierten Behebungsprozess mit Fristen je Schweregrad etablieren
  • Fixes für Open-Source-Abhängigkeiten upstream beitragen, wo möglich

Nachweis für die technische Dokumentation

  • Behebungsprozess
  • Historie behobener Schwachstellen

BSI TR-03183-3 (Kap. 3.1.3): Unterscheidet valid / validated / verified als Reifegrade einer Schwachstellenmeldung.

Advisories & Vendor-Watchlist →CSAF Studio →OSV-Scanner →Dependabot →Glossar: psirt →
Regelmäßige Sicherheitstests und ÜberprüfungenEs sind wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit durchzuführen - fortlaufend über den Supportzeitraum, nicht nur vor Markteinführung.Anhang I Teil II Nr. 3
Status für Regelmäßige Sicherheitstests und Überprüfungen
Umsetzung & Nachweis

Umsetzung

  • Wiederkehrende Sicherheitstests (SAST/DAST, Penetrationstests) in den Entwicklungszyklus integrieren

Nachweis für die technische Dokumentation

  • Testplan
  • Testberichte über die Zeit
IT-Sicherheits-Audit →OWASP ZAP →Semgrep →
Behobene Schwachstellen öffentlich offenlegenSobald ein Sicherheitsupdate verfügbar ist, sind Informationen zur behobenen Schwachstelle offenzulegen: Beschreibung, betroffene Produkte, Auswirkungen, Schweregrad und Hinweise zur Behebung.Anhang I Teil II Nr. 4
Status für Behobene Schwachstellen öffentlich offenlegen
Umsetzung & Nachweis

Umsetzung

  • Sicherheitshinweise strukturiert und maschinenlesbar veröffentlichen

Nachweis für die technische Dokumentation

  • Veröffentlichte Advisories

BSI TR-03183-3 (Kap. 4.4.10): Offenlegung binnen 90 Tagen, einmalig um weitere 90 Tage verlängerbar; Meldung mindestens über die EUVD.

CSAF Studio →Secvisogram →Glossar: csaf →Glossar: cvss →
Koordinierte Offenlegungspolitik (CVD)Hersteller müssen eine Politik zur koordinierten Offenlegung von Schwachstellen einführen und durchsetzen.Anhang I Teil II Nr. 5
Status für Koordinierte Offenlegungspolitik (CVD)
Umsetzung & Nachweis

Umsetzung

  • CVD-Policy dokumentieren und veröffentlichen
  • Prozess für eingehende Meldungen definieren: Erstreaktion binnen 5, Rückmeldung binnen 10 Arbeitstagen

Nachweis für die technische Dokumentation

  • CVD-Policy-Dokument

BSI TR-03183-3 (Kap. 4.4): Pflichtinhalte einer CVD-Policy und die Reaktionszeiten von 5 / 10 Arbeitstagen.

CVD-Policy-Generator →ISMS-Handbuch →Glossar: psirt →Glossar: cvd →
Informationsaustausch über potenzielle Schwachstellen erleichternHersteller müssen den Austausch von Informationen über potenzielle Schwachstellen im eigenen Produkt und in Drittkomponenten erleichtern, unter anderem durch eine öffentliche Kontaktadresse.Anhang I Teil II Nr. 6
Status für Informationsaustausch über potenzielle Schwachstellen erleichtern
Umsetzung & Nachweis

Umsetzung

  • Öffentliche, überwachte Sicherheitskontaktadresse einrichten: security.txt nach RFC 9116 unter /.well-known/

Nachweis für die technische Dokumentation

  • Veröffentlichte Kontaktadresse
  • security.txt

BSI TR-03183-3 (Kap. 4.2, Kap. 4.3.1): Pflichtfelder der security.txt und getrennte PSIRT-/CSIRT-Rollen.

Domain-Sicherheitscheck →security.txt Generator →Glossar: security-txt →
Sichere Verteilmechanismen für UpdatesEs sind Mechanismen zur sicheren Verteilung von Updates bereitzustellen, die eine zeitnahe Installation ermöglichen.Anhang I Teil II Nr. 7
Status für Sichere Verteilmechanismen für Updates
Umsetzung & Nachweis

Umsetzung

  • Signierte, manipulationssichere Update-Kanäle bereitstellen

Nachweis für die technische Dokumentation

  • Beschreibung des Update-Verteilmechanismus

BSI TR-03183-1 (Anhang B, VH.7 / VH.7a): Anforderungen an sichere, automatisierte Update-Verteilung.

ISMS Statement of Applicability →
Unverzügliche, kostenlose Verteilung von SicherheitsupdatesSicherheitsupdates sind unverzüglich und kostenlos zu verteilen, begleitet von Hinweisen mit den zur Behebung erforderlichen Informationen.Anhang I Teil II Nr. 8
Status für Unverzügliche, kostenlose Verteilung von Sicherheitsupdates
Umsetzung & Nachweis

Umsetzung

  • Kostenlose Bereitstellung von Sicherheitsupdates während des gesamten Supportzeitraums sicherstellen

Nachweis für die technische Dokumentation

  • Update-Historie mit Veröffentlichungsdatum
CSAF Studio →

Anhang II - Informationen für Nutzer

HerstellerangabenName, eingetragener Handelsname und Kontaktdaten (Anschrift, E-Mail, Website) des Herstellers.Anhang II Nr. 1
Status für Herstellerangaben
Umsetzung & Nachweis

Umsetzung

  • Herstellerangaben in Produktdokumentation und auf Verpackung/Website aufnehmen

Nachweis für die technische Dokumentation

  • Produktdatenblatt mit Herstellerangaben
Kontaktstelle für SchwachstellenmeldungenEine einzige Kontaktstelle, über die Nutzer Schwachstellen melden können, samt Zugang zur Offenlegungspolitik.Anhang II Nr. 2
Status für Kontaktstelle für Schwachstellenmeldungen
Umsetzung & Nachweis

Umsetzung

  • Kontaktstelle veröffentlichen und mit der CVD-Policy verlinken

Nachweis für die technische Dokumentation

  • Veröffentlichte Kontaktstelle

BSI TR-03183-3 (Kap. 4.5): Meldeseite muss ohne Login und ohne JavaScript erreichbar sein.

Domain-Sicherheitscheck →CVD-Policy-Generator →Glossar: psirt →
ProduktidentifikationName, Typ und weitere Angaben, die eine eindeutige Identifikation des Produkts ermöglichen.Anhang II Nr. 3
Status für Produktidentifikation
Umsetzung & Nachweis

Umsetzung

  • Eindeutige Produktkennzeichnung (Typ, Version, Seriennummer) einführen

Nachweis für die technische Dokumentation

  • Produktkennzeichnung auf Gerät/Verpackung/Dokumentation
Verwendungszweck, Sicherheitsumgebung und SicherheitseigenschaftenBeschreibung des Verwendungszwecks, der vorgesehenen Sicherheitsumgebung sowie der wesentlichen Funktionen und Sicherheitseigenschaften.Anhang II Nr. 4
Status für Verwendungszweck, Sicherheitsumgebung und Sicherheitseigenschaften
Umsetzung & Nachweis

Umsetzung

  • Verwendungszweck und Sicherheitseigenschaften in der Nutzerdokumentation beschreiben

Nachweis für die technische Dokumentation

  • Nutzerdokumentation
ISMS-Handbuch →
Bekannte oder vorhersehbare RisikenBekannte oder vorhersehbare Umstände im Zusammenhang mit der Nutzung, die zu erheblichen Cybersicherheitsrisiken führen könnten.Anhang II Nr. 5
Status für Bekannte oder vorhersehbare Risiken
Umsetzung & Nachweis

Umsetzung

  • Restrisiken aus der Risikobewertung nutzerverständlich zusammenfassen

Nachweis für die technische Dokumentation

  • Abschnitt zu Restrisiken in der Nutzerdokumentation
CyberRisk Canvas →Glossar: tara →
Fundstelle der EU-KonformitätserklärungInternetadresse, unter der die EU-Konformitätserklärung abrufbar ist, soweit anwendbar.Anhang II Nr. 6
Status für Fundstelle der EU-Konformitätserklärung
Umsetzung & Nachweis

Umsetzung

  • EU-Konformitätserklärung online veröffentlichen und Adresse in der Dokumentation nennen

Nachweis für die technische Dokumentation

  • Veröffentlichte EU-Konformitätserklärung
EU-Konformitätserklärung-Generator →Glossar: ce-kennzeichnung →
Art des technischen Supports und SupportzeitraumArt des angebotenen technischen Sicherheitssupports sowie Enddatum des Supportzeitraums, mindestens jedoch die Angaben nach Art. 13(8).Anhang II Nr. 7
Status für Art des technischen Supports und Supportzeitraum
Umsetzung & Nachweis

Umsetzung

  • Supportzeitraum festlegen und in Produktdokumentation kommunizieren

Nachweis für die technische Dokumentation

  • Angabe des Supportzeitraums in der Dokumentation
Anweisungen zu Inbetriebnahme, Updates und sicherer AußerbetriebnahmeDetaillierte Anweisungen zu sicherer Erstinbetriebnahme, Auswirkungen von Änderungen auf die Datensicherheit, Installation von Sicherheitsupdates, sicherer Außerbetriebnahme/Datenlöschung, Deaktivierung automatischer Updates und Integration mit anderen Produkten.Anhang II Nr. 8
Status für Anweisungen zu Inbetriebnahme, Updates und sicherer Außerbetriebnahme
Umsetzung & Nachweis

Umsetzung

  • Betriebsanleitung um sicherheitsrelevante Abschnitte für den gesamten Lebenszyklus ergänzen

Nachweis für die technische Dokumentation

  • Betriebsanleitung mit Sicherheitsabschnitten
ISMS-Handbuch →
Fundstelle der Software Bill of MaterialsOrt, an dem die SBOM abrufbar ist, sofern der Hersteller eine bereitstellt.Anhang II Nr. 9
Status für Fundstelle der Software Bill of Materials
Umsetzung & Nachweis

Umsetzung

  • SBOM-Zugang für Nutzer/Kunden dokumentieren, falls bereitgestellt

Nachweis für die technische Dokumentation

  • Angabe der SBOM-Fundstelle

BSI TR-03183-2 (Kap. 5.2.3): SBOM-URI als eigenes Datenfeld der SBOM.

SBOM-Glossareintrag →Glossar: sbom →

EU-Konformitätserklärung (Entwurf, Anhang V)

Weitere Produkte in dieser Kategorie

Einstufung

Kernfunktion ist die aktive Kontrolle oder Überwachung des Netzverkehrs zu Sicherheitszwecken.

Beispiele: Next-Generation-Firewalls, Netzwerk-IDS/IPS

Konformitätsweg nach Art. 32
Modul B+CModul H
Benannte Stelle:
Zwingend erforderlich
Selbsterklärung (Modul A):
Derzeit nicht verfügbar

Die interne Konformitätskontrolle (Modul A) steht für Klasse-II-Produkte nicht offen. Es ist zwingend eine benannte Stelle über Modul B+C oder Modul H einzubinden.

Modul H über ein bestehendes ISMS

Statt je Produkt eine benannte Stelle einzeln zu durchlaufen, lässt sich Modul H über ein zertifiziertes ISO/IEC-27001-ISMS abdecken (BSI TR-03183-H). Sechs Annex-A-Controls werden dafür CRA-spezifisch erweitert:

  • A.5.7: Threat Intelligence muss auch das Produkt mit digitalen Elementen selbst abdecken, nicht nur die eigene IT-Umgebung.
  • A.5.8: Informationssicherheit im Projektmanagement gilt mindestens für den gesamten Produktlebenszyklus des Produkts.
  • A.8.8: Technisches Schwachstellenmanagement erstreckt sich auf das ausgelieferte Produkt und dessen Komponenten (Anhang I Teil II).
  • A.8.25: Sicherer Entwicklungslebenszyklus einschließlich Hardware; definierte Sicherheitsgates vor Markteinführung.
  • A.8.29: Sicherheitstests auch vor Auslieferung an den Nutzer bzw. vor Markteinführung, nicht nur vor internem Deployment.
  • A.8.32: Änderungsmanagement gilt für jede Änderung am Produkt mit digitalen Elementen, nicht nur für interne Systeme.
Zum ISMS Statement of Applicability →
Anwendbare Normen

Normenstand: 2026-08-07. Bisher ist keine CRA-Norm im EU-Amtsblatt zitiert - eine Konformitätsvermutung nach Art. 27 besteht derzeit für kein Produkt.

Horizontal (für jedes CRA-Produkt)

  • prEN 40000-1-1Begriffe und TerminologieCEN-CLC/JTC 13 WG 9Öffentliche Umfrage abgeschlossen
  • prEN 40000-1-2Grundsätze der Cyberresilienz (Risikomanagement, Lebenszyklus)CEN-CLC/JTC 13 WG 9Öffentliche Umfrage abgeschlossen
  • prEN 40000-1-3SchwachstellenbehandlungCEN-CLC/JTC 13 WG 9Öffentliche Umfrage abgeschlossen
  • prEN 40000-1-4Generische SicherheitsanforderungenCEN-CLC/JTC 13 WG 9In Bearbeitung

Vertikal (produktspezifisch)

  • ETSI EN 304 636Firewalls und Intrusion-Detection-/-Prevention-SystemeETSI TC CYBER (EUSR)Entwurf verfügbar
  • prEN 50770-1OT-Firewalls und Intrusion-Detection-/-Prevention-SystemeCLC/TC 65X WG 3In Bearbeitung

Weiterführend

Verwandte Werkzeuge und Informationen

Für den Reifegrad über alle CRA-Domänen hinweg hilft der CRA-Klartext-Selbstcheck. Für die formale Einordnung von NIS2, CRA und ISO 42001 insgesamt hilft der Compliance-Kompass.

Häufige Fragen

Was muss ich für Firewalls und Intrusion-Detection-/-Prevention-Systeme nach dem Cyber Resilience Act konkret umsetzen?

Für Firewalls und Intrusion-Detection-/-Prevention-Systeme gelten alle 37 Anforderungen aus Anhang I, Anhang II und den zentralen Herstellerpflichten der Verordnung (EU) 2024/2847. Besonders schwer wiegen dabei: Schutz der Verfügbarkeit wesentlicher Funktionen, Begrenzung der Angriffsfläche, Protokollierung sicherheitsrelevanter Aktivität. Die vollständige Liste mit konkreten Umsetzungsschritten und Nachweisen für die technische Dokumentation steht oben auf dieser Seite.

Welcher Konformitätsweg gilt für Firewalls und Intrusion-Detection-/-Prevention-Systeme?

Wichtiges Produkt - Klasse II: Die interne Konformitätskontrolle (Modul A) steht für Klasse-II-Produkte nicht offen. Es ist zwingend eine benannte Stelle über Modul B+C oder Modul H einzubinden.

Gilt für Firewalls und Intrusion-Detection-/-Prevention-Systeme schon eine Konformitätsvermutung nach Art. 27 CRA?

Nein. Bislang ist keine CRA-Norm im EU-Amtsblatt zitiert, sodass für Firewalls und Intrusion-Detection-/-Prevention-Systeme keine Konformitätsvermutung nach Art. 27 besteht. Die Erfüllung der Anforderungen muss anderweitig nachgewiesen werden, etwa durch die technische Dokumentation.

Mehr dazu: CRA-Klartext-Selbstcheck · Compliance-Kompass · CRA im Glossar

Weitere Kategorien in Wichtiges Produkt - Klasse II

Hypervisoren und Container-Runtime-SystemeManipulationssichere MikroprozessorenManipulationssichere Mikrocontroller