Sie bauen Software? Dann gelten die CRA-Pflichten für Hersteller.

Nein. Die Meldung nach Art. 14 ist Ihre Handlung. Sie läuft über die Weboberfläche der von der ENISA betriebenen einheitlichen Meldeplattform; Zugang haben benannte Ansprechpersonen des Herstellers über ein EU-Login mit Zwei-Faktor-Anmeldung, und eine Programmierschnittstelle stellt die ENISA zum Start nicht bereit. Wir bereiten die Meldung feldgenau vor, führen die Fristen und dokumentieren jeden Schritt — abschicken müssen Sie selbst.

Reine Cloud-Dienste fallen nicht unter den Cyber Resilience Act. Erwägungsgrund 12 sagt ausdrücklich, dass für Cloud-Computing-Dienste und Dienstmodelle wie SaaS, PaaS und IaaS die Richtlinie (EU) 2022/2555 (NIS2) gilt. Aber die Grenze verläuft nicht am Geschäftsmodell, sondern an der Software: Sobald Sie neben dem Webdienst eine mobile App, einen Desktop-Client, einen Agenten oder ein SDK ausliefern, sind Sie dafür Hersteller — und die zugehörige Backend-Schnittstelle wird als Datenfernverarbeitungslösung miterfasst (Art. 3 Nr. 1 und 2, Erwägungsgrund 11). Wenn Sie ausschließlich einen Webdienst betreiben, brauchen Sie Hugo Hersteller nicht; prüfen Sie stattdessen Ihre NIS2-Betroffenheit.

Das hängt an zwei Fragen. Erstens: Stellen Sie die Software im Rahmen einer Geschäftstätigkeit bereit? Freie und quelloffene Software fällt nur dann unter den CRA (Art. 3 Nr. 22, Erwägungsgrund 18) — weder die finanzielle Unterstützung durch Hersteller noch regelmäßige Veröffentlichungen von Versionen begründen für sich genommen eine Geschäftstätigkeit. Zweitens: Verdienen Sie mittelbar daran? Der Herstellerbegriff erfasst ausdrücklich die Vermarktung „zur Monetarisierung“ — bezahlter Support, Dual-Lizenz oder eine kostenpflichtige Pro-Version machen Sie zum Hersteller. Für Verwalter quelloffener Software gilt eine reduzierte Regelung nach Art. 24: eine dokumentierte Cybersicherheitsstrategie und die Zusammenarbeit mit den Marktüberwachungsbehörden. Die Meldung aktiv ausgenutzter Schwachstellen gilt aber auch für sie und ist nicht freiwillig (Art. 24 Abs. 3).

Eine Software-Stückliste (englisch Software Bill of Materials) ist nach Art. 3 Nr. 39 eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts enthalten sind. Anhang I Teil II Nr. 1 verlangt sie in einem gängigen maschinenlesbaren Format, aus dem zumindest die obersten Abhängigkeiten hervorgehen. Veröffentlichen müssen Sie sie nicht: 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). Erwägungsgrund 22 betont sogar ausdrücklich 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); wir unterstützen beide, weil sie sich in der Praxis durchgesetzt haben.

Zuerst die Einordnung, die selten jemand mitliefert: Gegen Hersteller, die als Kleinst- oder Kleinunternehmen gelten, sollen wegen Versäumens der 24-Stunden-Frist für die Frühwarnung keine Geldbußen verhängt werden — das steht in Art. 64 Abs. 10 Buchst. a und in Erwägungsgrund 120, der die Mitgliedstaaten ausdrücklich auch von anderweitigen finanziellen Sanktionen abhält. Gegen Verwalter quelloffener Software sind Geldbußen bei jedem Verstoß ausgeschlossen. Das heißt nicht, dass nichts passiert: Die Pflicht besteht weiter, die Meldung ist unverzüglich nachzuholen, und die Marktüberwachungsbehörde kann tätig werden. Praktisch wirksamer als jedes Bußgeld ist ohnehin Art. 14 Abs. 8 — informiert der Hersteller seine Nutzer nicht rechtzeitig, dürfen die CSIRTs das selbst tun.

Für Verstöße gegen die grundlegenden Cybersicherheitsanforderungen des Anhang I und gegen die Pflichten der Artikel 13 und 14 sieht Art. 64 Abs. 2 Geldbußen bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Für Verstöße gegen die Artikel 18 bis 23 und weitere Vorschriften liegt der Rahmen bei 10 Mio. € oder 2 % (Art. 64 Abs. 3), für falsche Angaben gegenüber Behörden bei 5 Mio. € oder 1 % (Art. 64 Abs. 4). Zwei Einschränkungen gehören dazu: Die Verordnung setzt nur Obergrenzen — die Sanktionen selbst erlassen die Mitgliedstaaten (Art. 64 Abs. 1), und zu einem deutschen Durchführungsgesetz lag am 5. September 2026 keine belastbare Quelle vor. Und die Größe des Unternehmens ist ein ausdrücklicher Zumessungsfaktor (Art. 64 Abs. 5 Buchst. c).

Das entscheidet die Produktklasse, nicht die Firmengröße. Steht Ihr Produkt weder in Anhang III noch in Anhang IV — das ist die Mehrheit —, genügt das interne Kontrollverfahren nach Modul A, also die Konformitätsbewertung in eigener Verantwortung (Art. 32 Abs. 1 Buchst. a). Bei wichtigen Produkten der Klasse I ist Modul A nur zulässig, wenn harmonisierte Normen, gemeinsame Spezifikationen oder eine europäische Cybersicherheitszertifizierung mindestens der Stufe „mittel“ vollständig angewandt wurden (Art. 32 Abs. 2); solange keine solchen Normen im Amtsblatt gelistet sind, führt praktisch kein Weg an einer notifizierten Stelle vorbei. Bei Klasse II ist stets ein Dritter beteiligt (Art. 32 Abs. 3), bei kritischen Produkten des Anhang IV steht die europäische Cybersicherheitszertifizierung nach Art. 8 Abs. 1 im Vordergrund. Am Ende jedes Weges stehen die EU-Konformitätserklärung und die CE-Kennzeichnung. Der Hersteller-Check nennt Ihnen Klasse und Weg; die Bewertung selbst nehmen Sie oder eine notifizierte Stelle vor, nicht wir.

Nein. Firewalls, Intrusion-Detection-Systeme und Intrusion-Prevention-Systeme stehen in Anhang III Klasse II. Der Unterschied entscheidet über Geld und Zeitplan: Bei Klasse II ist an der Konformitätsbewertung stets ein Dritter beteiligt, auch wenn harmonisierte Normen vollständig angewandt wurden (Art. 32 Abs. 3, Erwägungsgrund 91). Klasse II hat insgesamt nur vier Kategorien — Hypervisoren und Container-Runtime-Systeme, Firewalls/IDS/IPS, manipulationssichere Mikroprozessoren und manipulationssichere Mikrocontroller. Zu Klasse I gehören unter anderem Identitätsmanagement, Browser, Passwort-Manager, VPN, Betriebssysteme sowie Router, Modems und Switches.

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; der Einbau eines solchen Elements führt für sich genommen nicht dazu, dass das umgebende Produkt den strengeren Verfahren unterliegt. Der übrige Pflichtenkatalog aus Art. 13 und Anhang I gilt trotzdem — und der Unterstützungszeitraum fällt bei Industrieanlagen typischerweise länger aus, weil Erwägungsgrund 60 industrielle Steuerungssysteme ausdrücklich als Beispiel für lange Nutzungsdauern nennt.

Nur, wenn Ihr Produkt voraussichtlich weniger als fünf Jahre genutzt wird. Der Rechtsbegriff lautet Unterstützungszeitraum, und Art. 13 Abs. 8 macht daraus kein Wahlrecht: Der Zeitraum muss die voraussichtliche Nutzungsdauer abbilden; fünf Jahre sind die Untergrenze. Erwägungsgrund 60 nennt Router, Modems, Switches, Betriebssysteme und Produkte für industrielle Umgebungen als Fälle, in denen längere Zeiträume geboten sind. Zwei angrenzende Pflichten werden dabei oft übersehen: Bereitgestellte Sicherheitsaktualisierungen müssen mindestens zehn Jahre verfügbar bleiben (Art. 13 Abs. 9), und das Enddatum ist zum Zeitpunkt des Kaufs mit mindestens Monat und Jahr leicht zugänglich anzugeben (Art. 13 Abs. 19).

Für den Pflichtenkatalog nein, für die Meldepflicht ja. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Anforderungen der Verordnung nur dann, wenn sie nach diesem Zeitpunkt einer wesentlichen Änderung unterliegen (Art. 69 Abs. 2). Die Meldepflicht des Artikels 14 gilt dagegen für alle Produkte im Anwendungsbereich, auch für den Altbestand (Art. 69 Abs. 3) — nach der Kommissionsleitlinie C(2026) 5252 (Randnummer 210) sogar nach dem Ende des Unterstützungszeitraums. Wichtig ist deshalb, den Stand jedes Produkts festzuhalten: Ohne diese Dokumentation lässt sich später nicht belegen, dass eine Änderung nicht wesentlich war.

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 keine Meldung aus. Und nach der Kommissionsleitlinie C(2026) 5252 (Randnummer 218) ist eine Schwachstelle in einer Drittkomponente nur dann zu melden, wenn sie im eigenen Produkt ausgenutzt wurde. Die Frist beginnt außerdem nicht mit dem ersten Verdacht, sondern sobald Sie nach einer unverzüglichen Erstbewertung mit hinreichender Sicherheit davon ausgehen können, dass ausgenutzt wird (Randnummer 213).

Nein. Hersteller ohne Hauptniederlassung in der Union sind voll erfasst und melden nach der 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 der Mitgliedstaat maßgeblich, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden — nicht der Handelsregistersitz. Lässt sich das nicht bestimmen, gilt der Mitgliedstaat mit der höchsten Beschäftigtenzahl in der Union.

In der Stufe Enterprise nicht — dort ist Hugo Hersteller enthalten. Wer Hugo ISMS Starter oder Professional nutzt, bekommt Hugo Hersteller mit 15 % Nachlass über den Code COMBO-ISMS-CRA-15. Inhaltlich überschneiden sich die beiden ohnehin kaum: Hugo ISMS ordnet die Informationssicherheit Ihrer eigenen Organisation, Hugo Hersteller die Cybersicherheit der Produkte, die Sie in Verkehr bringen. Das eine ersetzt das andere nicht.