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 nicht ein Gerät kompromittiert, sondern die Schutzwirkung ganzer Infrastrukturen aushebelt.

Für Hersteller und Importeure dieser Branche ist die Betroffenheit selten die eigentliche Frage — ein Produkt mit digitalen Elementen, das eine Netzwerkschnittstelle hat und in der EU in Verkehr gebracht wird, fiele schematisch in den Anwendungsbereich (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: Ein großer Teil dieser Produkte landet nicht in der Selbstbewertungs-Mehrheit, sondern 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?". Wer diese Weichenstellung erst spät klärt, unterschätzt regelmäßig den Vorlauf, den die Konformitätsbewertung eines Klasse-II-Produkts über eine notifizierte Stelle braucht.

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

Der CRA benennt viele Produkte dieser Branche ausdrücklich in Anhang III; die technischen Beschreibungen der wichtigen und kritischen Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392. 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 die einschlägigen harmonisierten Normen vollständig anwenden. Sind diese noch nicht verfügbar oder wenden Sie sie nur teilweise an, führt der Weg auch bei Klasse I über eine notifizierte Stelle. Bei Klasse II ist die notifizierte Stelle der Regelfall, bei Anhang-IV-Produkten immer — teils mit verpflichtendem europäischem Zertifizierungsschema.

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 BSI-Richtlinie TR-03183 (insb. TR-03183-2, v2.1.0) konkretisiert SBOM-Format und Schwachstellenmanagement. Diese Normen ersetzen den CRA nicht, sie füllen ihn aus — und harmonisierte CRA-Normen werden diese Basis perspektivisch bündeln.

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 (WLAN-Router, Mobilfunk-Gateways) gibt es Überschneidungen bei den Cybersicherheitsanforderungen; der CRA ist das produktübergreifende Dach, die RED-DA das funkspezifische Detail.
• NIS2 adressiert nicht Sie als Hersteller, sondern die Betreiber wesentlicher/wichtiger Einrichtungen, die Ihre Geräte einsetzen. Getrennter Rechtsakt — nicht mit dem CRA gleichsetzen.
• DORA betrifft die Resilienz des Finanzsektors; relevant nur, wenn Ihre Kunden dort sitzen, nicht für die Produktkonformität selbst.
• AI Act greift, wenn Sie KI-gestützte Anomalieerkennung als eigenständiges KI-System vermarkten — ein zusätzlicher, nicht ersetzender Rahmen.
• Sektorale Ausnahmen: Medizinprodukte (MDR/IVDR), Kfz-Typgenehmigung, zivile Luftfahrt und Schiffsausrüstung sind vom CRA ausgenommen. Für klassische Netzwerk-Security-Hardware greift das in der Regel nicht.

SBOM- und Lieferketten-Realität dieser Branche

Kaum eine Produktkategorie trägt so viel fremden Code wie eine Security-Appliance. 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 häufig 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 sie als Teil der technischen Dokumentation (keine allgemeine Veröffentlichungspflicht). Konkret bedeutet „maschinenlesbar" nach BSI TR-03183-2:

• Format CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 — nicht eine PDF-Liste, sondern ein maschinell auswertbares Dokument.
• 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 Support-Zeitraum: Die SBOM muss zum jeweiligen Firmware-/Softwarestand passen, damit ein CVE-Treffer sofort dem betroffenen Release zugeordnet werden kann.

Der Support-Zeitraum orientiert sich an der erwarteten Produktlebensdauer; als Leitwert gelten mindestens fünf Jahre — bei Security-Hardware, die lange im Feld bleibt, oft deutlich länger. Über diesen gesamten Zeitraum muss die SBOM gepflegt und das Schwachstellen-Handling belegbar sein.

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

Ab 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 verbreitete Verkürzung auf „24h/72h/14 Tage" ist an dieser Stelle falsch:

• 24 Stunden — Frühwarnung ab Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schweren Sicherheitsvorfalls.
• 72 Stunden — vollständige Meldung inklusive verfügbarer Korrektur- oder Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat — Abschlussbericht bei einem schweren Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Gemeldet wird über die ENISA Single Reporting Platform (SRP) als Einmalmeldung an das zuständige CSIRT der Hauptniederlassung und ENISA. Die Plattform ist zum Geltungsbeginn bereitzustellen; Mitte 2026 ist sie noch nicht voll operativ, weshalb Hersteller ihre internen PSIRT-Abläufe jetzt aufsetzen und nicht auf das Tooling warten sollten. 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 — sonst reißt die 24-Stunden-Marke beim ersten echten Vorfall.

Welche Frist zuerst zählt: 2026 vor 2027

Zwei Daten strukturieren die Vorbereitung, und sie werden häufig verwechselt:

• 11.09.2026 — Meldepflichten (Art. 14). Die erste harte Herstellerpflicht. Ab hier müssen Sie aktiv ausgenutzte Schwachstellen und schwere 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 zuerst scharfgeschaltet wird. Parallel läuft der längere Aufbau von Threat-Modeling, technischer Dokumentation und — bei Klasse II — der Terminierung mit einer notifizierten Stelle, deren Kapazitäten begrenzt sind. Technische Dokumentation ist im Übrigen zehn Jahre ab Inverkehrbringen aufzubewahren.

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 ist die notifizierte Stelle der Regelweg. Das VPN-Modul wäre für sich genommen Klasse I, geht aber im übergeordneten Klasse-II-Produkt auf.

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 binnen 24 Stunden die Frühwarnung über die SRP ab, liefert nach 72 Stunden die vollständige Meldung samt Workaround und — 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. Genau diese Kette — SBOM, PSIRT, belegbares Vulnerability-Handling — betreibt Blackfort für die eigenen Produkte (Dogfooding), bevor wir sie empfehlen.

Was Blackfort für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Hersteller und Importeure von Netzwerk- und Security-Hardware entlang genau dieser Punkte — pragmatisch, technisch fundiert und ohne generische Checklisten:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Produkte sind PDE, welche fallen schematisch in Klasse I, II oder Anhang IV — und welcher Konformitätspfad folgt daraus (Modul A vs. notifizierte Stelle).
• SBOM-Setup: Erzeugung maschinenlesbarer SBOMs (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) im Build, Verknüpfung mit Releases und kontinuierliche Pflege über den Support-Zeitraum.
• PSIRT und CVD: Aufbau des Meldeprozesses mit den korrekten Art.-14-Fristen, CVD-Policy, Eskalationswegen und Anbindung an die ENISA-SRP-Logik.
• Risikobewertung und Threat-Modeling: dokumentierte Risikobewertung nach Anhang I als methodische Grundlage der technischen Dokumentation.
• Technische Dokumentation: Aufbau der Nachweisstruktur inklusive Aufbewahrung über zehn Jahre und Vorbereitung auf die notifizierte-Stelle-Bewertung.

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.