CRA für Netzwerk- & Security-Hardware

Wenn das eigene Produkt die Verteidigungslinie ist

Firewalls, VPN-Gateways, IDS/IPS-Sensoren, SIEM-Appliances, PKI-Systeme: Wer solche Produkte baut, verkauft Vertrauen. Kunden schalten sie an die Grenze ihres Netzes, geben ihnen Sichtbarkeit über den gesamten Verkehr und machen sie zum zentralen Kontrollpunkt. Genau deshalb behandelt der Cyber Resilience Act (Verordnung (EU) 2024/2847) diese Gerätekategorie anders als eine gewöhnliche vernetzte Kaffeemaschine. Sicherheitsprodukte sind im CRA gezielt höher eingestuft, weil ihr Versagen die Schutzwirkung ganzer Infrastrukturen aushebeln kann.

Für Hersteller und Importeure dieser Branche ist die Betroffenheit schnell geklärt: Ein Gerät ist grundsätzlich erfasst, wenn es im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird und sein bestimmungsgemäßer Zweck oder seine vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt (Art. 2 Abs. 1) - für Netzwerkgeräte schematisch der Fall (das ist eine allgemeine Einordnung, keine Rechtsberatung zum Einzelfall). Der eigentliche Schmerz liegt woanders: in der Nachweistiefe. Eine Security-Appliance besteht heute zu großen Teilen aus Open-Source-Komponenten, integriert Krypto-Bibliotheken, Signatur-Feeds und einen Linux-Unterbau - und muss über Jahre auf Zero-Days reagieren können, während sie selbst das Ziel motivierter Angreifer ist.

Hinzu kommt: Firewalls, IDS/IPS, VPN-Produkte und Router stehen ausdrücklich in den „wichtigen" Kategorien des Anhang III. Das verschiebt die Frage von „Erfüllen wir die Anforderungen?" zu „Wer bestätigt das - wir selbst oder eine notifizierte Stelle?". Klären Sie diese Weichenstellung früh, weil die Bewertung eines Klasse-II-Produkts eine notifizierte Stelle einbindet und entsprechend Vorlauf braucht.

Typische PDE-Produkte und ihre wahrscheinliche Anhang-III-Klasse

Der CRA benennt zahlreiche Produkte dieser Branche ausdrücklich in Anhang III; die technischen Beschreibungen der wichtigen und kritischen Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392. Für die Einstufung zählt die Kernfunktion des Produkts (Art. 7 Abs. 1). Die folgende Einordnung ist schematisch und ersetzt keine produktindividuelle Bewertung:

Der praktische Unterschied ist erheblich: Bei Klasse I können Sie das Verfahren intern fahren (Modul A) - aber nur, wenn Sie harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) vollständig anwenden. Liegt nichts davon vor oder wenden Sie es nur teilweise an, führt der Weg auch bei Klasse I über eine notifizierte Stelle (Modul B+C oder H). Bei Klasse II führt der Weg über eine notifizierte Stelle (Modul B+C oder H) oder ein europäisches Schema mindestens „mittel“. Anhang-IV-Produkte brauchen ein europäisches Schema, falls ein delegierter Rechtsakt es vorschreibt; sonst gilt dasselbe wie für Klasse II.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Die inhaltliche Substanz für die CRA-Nachweise liefern in dieser Branche etablierte Sektor-Standards. IEC 62443 strukturiert Security für vernetzte Automatisierungs- und Steuerungsumgebungen und ist für Appliances mit OT-Berührung der natürliche Bezugsrahmen; produktnahe Common-Criteria-Evaluierungen und Härtungsnachweise belegen konkrete Sicherheitsfunktionen. Die nationale BSI-Richtlinie TR-03183 (insb. TR-03183-2, v2.1.0) gibt Empfehlungen zu SBOM-Format und Schwachstellenmanagement. Diese Normen ersetzen den CRA nicht, sie füllen ihn aus. Harmonisierte Normen zum CRA sind beauftragt (M/606), am 9. Oktober 2026 aber noch nicht im Amtsblatt veröffentlicht.

Wichtig ist die Abgrenzung zu benachbarten Regimen, damit Sie nicht doppelt oder am falschen Ziel arbeiten:

• RED-Delegierte-Verordnung 2022/30 (Funkgeräte): Bei funkfähigen Appliances, die über das Internet kommunizieren können (WLAN-Router, Mobilfunk-Gateways), gibt es Überschneidungen bei den Cybersicherheitsanforderungen; der CRA ist das produktübergreifende Dach, die RED-DA bis zu ihrer Aufhebung zum 11.12.2027 das funkspezifische Detail.
• NIS2 regelt die Cybersicherheit von Einrichtungen, der CRA die von Produkten. Als Hersteller elektronischer Erzeugnisse kann Ihr Unternehmen ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann Ihre Organisation, nicht die Konformität Ihrer Produkte. Getrennte Rechtsakte, nicht gleichsetzen.
• DORA betrifft die Resilienz des Finanzsektors; relevant nur, wenn Ihre Kunden dort sitzen, nicht für die Produktkonformität selbst.
• AI Act gilt zusätzlich, sobald ein KI-System verbaut ist, etwa eine KI-gestützte Anomalieerkennung; der Umfang der Pflichten hängt von der Risikostufe ab.
• Sektorale Ausnahmen: Ausgenommen sind Produkte, auf die MDR, IVDR oder die Typgenehmigungsverordnung (EU) 2019/2144 Anwendung finden, nach der Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte und Schiffsausrüstung (Art. 2 Abs. 2 bis 4). Für klassische Netzwerk-Security-Hardware greift das grundsätzlich nicht.

SBOM- und Lieferketten-Realität dieser Branche

Eine Security-Appliance enthält viel fremden Code. Typisch sind ein Linux-Kernel und -Userland, OpenSSL oder andere TLS-/Krypto-Bibliotheken, Regel- und Signatur-Engines (etwa Snort/Suricata-artige Komponenten), Web-UI-Frameworks, Logging-Stacks und ggf. ein eingebettetes Datenbanksystem. Jede dieser Komponenten hat einen eigenen Lebenszyklus - und genau hier liegt das Risiko: End-of-Life-Bibliotheken, unbeachtete transitive Abhängigkeiten und OSS-Projekte ohne aktiven Maintainer sind die typischen Einfallstore.

Eine maschinenlesbare SBOM ist die Voraussetzung, um beim nächsten Zero-Day in Stunden statt Wochen zu antworten. Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation (keine allgemeine Veröffentlichungspflicht). Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. In der Praxis bewährt sich:

• Ein maschinell auswertbares Format wie CycloneDX oder SPDX; eine PDF-Liste ist nicht maschinenlesbar.
• Mindestens die Top-Level-Abhängigkeiten mit eindeutiger Komponenten-Identität (Name, Version, Lieferant, idealerweise Hashes und Identifikatoren wie CPE/PURL).
• Aktualität über den Unterstützungszeitraum: Die SBOM sollte zum jeweiligen Firmware-/Softwarestand passen, damit ein CVE-Treffer sofort dem betroffenen Release zugeordnet werden kann.

Der Unterstützungszeitraum orientiert sich an der erwarteten Nutzungsdauer: in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer (Art. 13 Abs. 8) - bei Security-Hardware, die lange im Feld bleibt, entsprechend länger. Über diesen gesamten Zeitraum muss das Schwachstellen-Handling belegbar sein, und die SBOM ist dafür das Werkzeug.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt

Seit dem 11.09.2026 gilt die Meldepflicht nach Artikel 14. Für Security-Hardware ist sie besonders scharf, weil aktiv ausgenutzte Schwachstellen in einer Firewall oder einem VPN-Gateway unmittelbar sicherheitskritisch sind. Die Fristenkette lautet - und die Verkürzung auf „24h/72h/14 Tage" ist an dieser Stelle falsch:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat - Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Hersteller sollten ihre internen PSIRT-Abläufe unabhängig vom Tooling aufsetzen und vorhalten. Für diese Branche heißt das konkret: ein benannter PSIRT-Kontakt, eine veröffentlichte Coordinated-Vulnerability-Disclosure-(CVD)-Policy, definierte Eskalations- und Freigabewege und geübte Fristenschienen.

Welche Frist zuerst zählt: 2026 vor 2027

Zwei Daten strukturieren die Vorbereitung, und sie werden leicht verwechselt:

• 11.09.2026 - Meldepflichten (Art. 14). Die erste harte Herstellerpflicht. Seitdem müssen Sie aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle fristgerecht melden können. Das trifft auch bereits im Markt befindliche Produkte.
• 11.12.2027 - volle Produktanforderungen. Ab hier gelten sämtliche Anforderungen des Anhang I, die abgeschlossene Konformitätsbewertung, CE-Kennzeichnung und EU-Konformitätserklärung.

Für einen Hersteller von Netzwerk-Security-Hardware bedeutet das: Der PSIRT-/CVD-Prozess ist die erste Baustelle, weil er bereits scharfgeschaltet sein muss. Parallel läuft der längere Aufbau von Threat-Modeling, technischer Dokumentation und - bei Klasse II - der Terminierung mit einer notifizierten Stelle; planen Sie die notifizierte Stelle früh ein. Technische Dokumentation ist im Übrigen mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum aufzubewahren (Art. 13 Abs. 13).

Ein durchgespieltes Beispiel

Ein mittelständischer Hersteller bringt eine Next-Generation-Firewall mit integriertem IDS/IPS und einem optionalen VPN-Modul in Verkehr. Schematisch fällt die Firewall in Anhang III, Klasse II - damit führt der Weg über Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“; ohne verfügbares Schema ist die notifizierte Stelle der Regelweg. Das VPN-Modul wäre für sich genommen Klasse I, ändert als eingebaute Komponente aber nichts an der Einstufung der Firewall.

Die Firmware basiert auf einem gehärteten Linux, OpenSSL, einer Suricata-artigen Detection-Engine und einer Web-Management-UI. Der Hersteller erstellt eine CycloneDX-1.6-SBOM im Build und verknüpft sie mit jedem Release. Als in einer TLS-Bibliothek eine aktiv ausgenutzte Schwachstelle bekannt wird, erkennt der PSIRT über die SBOM in Minuten, welche Firmware-Stände betroffen sind, gibt unverzüglich, spätestens binnen 24 Stunden, die Frühwarnung über die einheitliche Meldeplattform ab, meldet spätestens binnen 72 Stunden mit den verfügbaren Angaben samt Workaround und liefert - sobald der Patch verfügbar ist - innerhalb von 14 Tagen den Abschlussbericht. Für das Marktzugangsverfahren stützt er sich auf IEC 62443 und Common-Criteria-Nachweise, führt das Threat-Modeling als dokumentierte Risikobewertung nach Anhang I und terminiert die notifizierte Stelle früh genug vor dem 11.12.2027. SBOM-Erzeugung im Build und den Abgleich der Stücklisten mit Schwachstellendaten setzen wir auch in unseren eigenen Build-Pipelines ein.

Was Blackfort für Sie tut

Blackfort Technology begleitet Hersteller und Importeure von Netzwerk- und Security-Hardware entlang genau dieser Punkte - pragmatisch, technisch fundiert und ohne generische Checklisten:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, welche Ihrer Produkte PDE sind, welche schematisch in Klasse I, II oder Anhang IV fallen und welcher Konformitätspfad daraus folgt (Modul A vs. notifizierte Stelle).
• SBOM-Setup: Erzeugung maschinenlesbarer SBOMs, etwa in CycloneDX oder SPDX, im Build, Verknüpfung mit Releases und kontinuierliche Pflege über den Unterstützungszeitraum.
• PSIRT und CVD: Aufbau des Meldeprozesses mit den korrekten Art.-14-Fristen, CVD-Policy, Eskalationswegen und Anbindung an die einheitliche Meldeplattform.
• Risikobewertung und Threat-Modeling: dokumentierte Risikobewertung nach Anhang I als methodische Grundlage der technischen Dokumentation.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13), und Vorbereitung der Konformitätsbewertung mit der notifizierten Stelle.

Ein guter Startpunkt ist der Betroffenheits-Check, der Ihre Produkte schematisch einordnet (keine Rechtsberatung). Vertiefen können Sie mit unserem Überblick zum Cyber Resilience Act und den Hinweisen für kleine und mittlere Hersteller. Wenn Sie konkret durchsprechen wollen, wo Ihr Produkt steht, melden Sie sich über Kontakt.

Hinweis: Diese Darstellung dient der fachlichen Orientierung und ersetzt keine Rechtsberatung im Einzelfall.