CRA-Hersteller-Check nach der Verordnung (EU) 2024/2847

Hersteller ist nach Art. 3 Nr. 13 der Verordnung (EU) 2024/2847, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet — gegen Bezahlung, zur Monetarisierung oder unentgeltlich. Wer ausschließlich im Auftrag entwickelt und das Ergebnis unter dem Namen des Kunden erscheint, ist für dieses Produkt nicht Hersteller; dann trifft die Pflicht den Kunden. Wer dasselbe Werkzeug mehrfach unter eigenem Namen verkauft, ist es sehr wohl.

Reine Cloud-Dienste fallen nicht unter den Cyber Resilience Act, sondern unter die Richtlinie (EU) 2022/2555 (NIS2) — das stellt Erwägungsgrund 12 ausdrücklich klar. Die Grenze verläuft aber nicht am Geschäftsmodell, sondern an der Software: Wer neben dem Webdienst eine mobile App, einen Desktop-Client, einen Agenten oder ein SDK ausliefert, ist dafür Hersteller. Die zugehörige Backend-Schnittstelle wird dann als Datenfernverarbeitungslösung miterfasst (Art. 3 Nr. 1 und 2, Erwägungsgrund 11).

Nein. Hersteller ohne Hauptniederlassung in der Union sind voll erfasst. Für die Meldung gilt dann die Rangfolge des Art. 14 Abs. 7 Unterabs. 3: zuständig ist das CSIRT des Mitgliedstaats, in dem der Bevollmächtigte niedergelassen ist, sonst der Einführer, sonst der Händler, sonst der Mitgliedstaat mit den meisten Nutzern. Für Hersteller mit Hauptniederlassung in der Union ist es der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden — nicht der Handelsregistersitz.

Nein — Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme stehen in Anhang III Klasse II, nicht in Klasse I. Der Unterschied ist erheblich: Bei Klasse II ist an der Konformitätsbewertung stets ein Dritter beteiligt, auch wenn harmonisierte Normen vollständig angewandt wurden. Klasse II hat insgesamt nur vier Kategorien: Hypervisoren und Container-Runtime-Systeme, Firewalls/IDS/IPS, manipulationssichere Mikroprozessoren und manipulationssichere Mikrocontroller.

In aller Regel nicht. Industrielle Steuerungssysteme sind in Anhang III nicht gelistet. Ein Produkt wird nach Art. 7 Abs. 1 nur dann zum wichtigen Produkt, wenn es die Kernfunktionen einer dort aufgeführten Kategorie aufweist — etwa weil eine Firewall integriert ist. Der Einbau eines solchen Elements führt für sich genommen nicht dazu, dass das umgebende Produkt den strengeren Konformitätsbewertungsverfahren unterliegt. Der übrige Pflichtenkatalog aus Art. 13 und Anhang I gilt trotzdem.

Gleichzeitig an das für Sie zuständige, als Koordinator benanntes CSIRT und an die ENISA — über die von der ENISA betriebene einheitliche Meldeplattform, und zwar über den Meldeendpunkt Ihres CSIRT (Art. 14 Abs. 1 und 7, Art. 16 Abs. 1). Die verbreitete Darstellung, man melde an die ENISA und diese leite weiter, dreht die Kette um: Weitergeleitet wird vom erstempfangenden CSIRT an die CSIRTs der übrigen betroffenen Mitgliedstaaten (Art. 16 Abs. 2). Zuständige Meldestelle in Deutschland ist CERT-Bund beim BSI.

Drei Pflichtstufen — und ein Zwischenbericht, wenn Ihr CSIRT ihn anfordert. Nach Art. 14 Abs. 6 kann das als Koordinator benannte CSIRT einen Zwischenbericht über relevante Statusaktualisierungen verlangen. Wer seinen Ablauf auf 24 Stunden, 72 Stunden und Abschlussbericht auslegt, hat diesen vierten Fall nicht abgedeckt.

Nein. Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit des Produkts (Art. 14 Abs. 1 und 3). Erwägungsgrund 68 nimmt Schwachstellen ausdrücklich aus, die ohne böswillige Absicht bei gutgläubigen Tests, Untersuchungen, Korrekturen oder Offenlegungen gefunden werden — Bug-Bounty- und Pentest-Funde lösen also keine Meldung aus. Nach der Kommissionsleitlinie C(2026) 5252 (Randnummer 218) ist eine Schwachstelle in einer Drittkomponente nur zu melden, wenn sie im eigenen Produkt ausgenutzt wurde.

Nur, wenn Ihr Produkt voraussichtlich weniger als fünf Jahre genutzt wird. Der Maßstab ist nach Art. 13 Abs. 8 die voraussichtliche Nutzungsdauer; fünf Jahre sind die Untergrenze, kein Wahlrecht. Erwägungsgrund 60 nennt ausdrücklich Router, Betriebssysteme und Produkte für industrielle Umgebungen als Fälle, in denen längere Zeiträume geboten sind. Unabhängig davon müssen bereitgestellte Sicherheitsaktualisierungen mindestens zehn Jahre verfügbar bleiben (Art. 13 Abs. 9).

Nein. Die Software-Stückliste ist in einem gängigen maschinenlesbaren Format zu erstellen und muss mindestens die obersten Abhängigkeiten ausweisen (Anhang I Teil II Nr. 1). Sie gehört in die technische Dokumentation und geht auf begründetes Verlangen an die Marktüberwachungsbehörde (Anhang VII Nr. 2 Buchst. b und Nr. 8). Eine Veröffentlichungspflicht gibt es nicht; Erwägungsgrund 22 betont sogar den Schutz ihrer Vertraulichkeit. CycloneDX und SPDX schreibt die Verordnung nicht vor — Format und Elemente kann die Kommission per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24).

Das hängt an der Geschäftstätigkeit. Freie und quelloffene Software fällt nur unter den CRA, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird (Art. 3 Nr. 22, Erwägungsgrund 18). Finanzielle Unterstützung durch Hersteller oder regelmäßige Veröffentlichungen von Versionen machen daraus für sich genommen keine Geschäftstätigkeit. Der Herstellerbegriff erfasst allerdings ausdrücklich auch die Vermarktung „zur Monetarisierung“ — wer die Software kostenlos abgibt und über Support, Dual-Lizenz oder eine Pro-Version verdient, ist Hersteller.

Für sie gilt eine reduzierte Regelung: eine auf überprüfbare Weise dokumentierte Cybersicherheitsstrategie (Art. 24 Abs. 1) und die Zusammenarbeit mit den Marktüberwachungsbehörden auf deren Verlangen (Art. 24 Abs. 2). Die Meldung aktiv ausgenutzter Schwachstellen nach Art. 14 Abs. 1 gilt aber auch für sie, soweit sie an der Entwicklung beteiligt sind — sie ist nicht freiwillig (Art. 24 Abs. 3). Dafür dürfen Verwalter keine CE-Kennzeichnung anbringen (Erwägungsgrund 19), und Geldbußen sind gegen sie bei jedem Verstoß ausgeschlossen (Art. 64 Abs. 10 Buchst. b).

Für Verstöße gegen die Artikel 13 und 14 und gegen die grundlegenden Anforderungen des Anhang I sieht Art. 64 Abs. 2 Geldbußen von bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Für ein Unternehmen unterhalb von 600 Mio. € Umsatz ist damit immer der Festbetrag die Obergrenze. Wichtig für kleine Anbieter: Gegen Kleinst- und Kleinunternehmen sollen wegen Versäumens der 24-Stunden-Frist keine Geldbußen verhängt werden, gegen Verwalter quelloffener Software überhaupt keine (Art. 64 Abs. 10, Erwägungsgrund 120). Die Sanktionen selbst erlässt der nationale Gesetzgeber (Art. 64 Abs. 1).