Bin ich Hersteller? Die CRA-Frage, die niemand beantwortet.
Wer ein Plugin veröffentlicht, will wissen, ob die Cyberresilienz-Verordnung ihn zum Hersteller macht. Die Quellen geben darauf zwei verschiedene Antworten.
Die Frage ist in einem Satz gestellt. Du hast ein WordPress-Plugin gebaut, es liegt im offenen Verzeichnis, jeder darf es herunterladen, und daneben verkaufst du eine Pro-Fassung. Bist du damit Hersteller im Sinne der Cyberresilienz-Verordnung, der Verordnung (EU) 2024/2847?
Die ehrliche Antwort ist unbequem. Es kommt darauf an, die Quellen widersprechen sich an genau dieser Stelle, und ein Teil der lautesten Stimmen im Markt verkauft selbst Werkzeuge, die bei der Antwort helfen sollen. Wir haben die Behauptung, kostenlose Plugins mit Pro-Version fielen automatisch unter den CRA, im August 2026 systematisch gegen die verfügbaren Quellen geprüft. Das Ergebnis ist kein sauberes Ja und kein sauberes Nein.
Deshalb steht hier keine Antwort, die es nicht gibt. Hier steht, was die Verordnung sagt, was die Kommission dazu sagt, wo beides auseinanderläuft, und mit welchen Fragen du deine eigene Lage sortierst. Das ist eine Einordnung und keine Rechtsberatung.
Der Satz, bei dem die meisten zusammenzucken
Fang bei der Definition an. Die Ausnahme kommt danach. Artikel 3 Nummer 1 CRA beschreibt das Produkt mit digitalen Elementen als "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Ein separat vertriebenes Software-Modul ist damit erfasst. Ein Plugin ist ein separat vertriebenes Software-Modul.
Artikel 3 Nummer 13 CRA definiert dann den Hersteller: wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt und sie unter eigenem Namen oder eigener Marke vermarktet, "whether for payment, monetisation or free of charge". Diese letzte Wendung ist die Stelle, an der die Diskussion normalerweise endet, bevor sie anfängt. Der Preis ist kein Merkmal des Herstellerbegriffs. Das Vermarkten unter eigenem Namen ist es.
Ein Vorbehalt gehört hierher, weil er den ganzen Beitrag betrifft: EUR-Lex war während unserer Recherche über mehrere URL-Formen nicht auslesbar. Die Artikelzitate stammen aus Volltextspiegelungen der Verordnung, die untereinander übereinstimmten. Wer ein wörtliches Zitat weiterverwendet, prüft es vorher gegen EUR-Lex.
Der Gegenpol steht in der Guidance der Kommission
Ende Juli 2026 hat die Europäische Kommission eine Anwendungshilfe zum CRA veröffentlicht, Aktenzeichen C(2026) 5252, bestehend aus einer Mitteilung und einem Annex mit der eigentlichen Anleitung. Rund 80 Seiten, 67 praktische Beispiele, Ablaufdiagramme, ausdrücklich mit Kleinstunternehmen und KMU als Zielgruppe. Kleine Randnotiz zur Genauigkeit: Die Kommission datiert das Dokument auf Brüssel, 27.07.2026, heise online berichtet von einer Veröffentlichung am 28.07.2026. Vermutlich Ausstellungsdatum gegen Veröffentlichungsdatum. Wir schreiben deshalb Ende Juli und nennen das Aktenzeichen.
Inhaltlich sagt die Guidance zu Open Source das Gegenteil dessen, was viele nach dem Blick in Artikel 3 erwarten: Frei verfügbare Open-Source-Software fällt grundsätzlich nicht in den Anwendungsbereich des CRA, solange sie nicht kommerzialisiert wird. Als kommerzielle Tätigkeit gelten laut Guidance unter anderem der Verkauf der Software, kostenpflichtige Enterprise-Fassungen, die Monetarisierung von Diensten über das Programm, das Verlangen personenbezogener Daten über Sicherheits- und Interoperabilitätszwecke hinaus sowie faktisch verpflichtende Spenden als Zugangsvoraussetzung.
Ausdrücklich nicht kommerziell sind laut Guidance freiwillige Beiträge, öffentliche Förderung und Sponsoring allein. Bezahlte Supportleistungen unterwerfen ein Projekt nicht automatisch dem CRA, solange die Software selbst frei verfügbar bleibt.
Beachte, was in der Verordnung fehlt: Der CRA definiert den Begriff der kommerziellen Tätigkeit nicht eigenständig im Artikeltext. Die Kriterien dafür stammen aus den Erwägungsgründen und aus dieser Guidance. Genau daraus entsteht der Raum, in dem sich die Auslegungen unterscheiden.
Der Steward ist ein leichteres Regime, kein Freibrief
Zwischen Hersteller und Nichtbeteiligtem gibt es eine dritte Rolle. Artikel 3 Nummer 14 CRA definiert den Open-Source-Software-Steward als juristische Person, die kein Hersteller ist und deren Zweck darin besteht, dauerhaft und systematisch die Entwicklung bestimmter Produkte mit digitalen Elementen zu unterstützen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind.
Was daraus folgt, steht in Artikel 24. Absatz 1 verlangt eine dokumentierte Cybersicherheitspolitik, die sichere Entwicklung und den Umgang mit Schwachstellen fördert, einschließlich der freiwilligen Schwachstellenmeldung nach Artikel 15. Absatz 2 verlangt Zusammenarbeit mit den Marktüberwachungsbehörden und auf begründetes Verlangen die Vorlage der Dokumentation in einer für die Behörde leicht verständlichen Sprache. Absatz 3 erklärt Artikel 14 Absatz 1 für Stewards anwendbar, bezogen auf die Produkte, an deren Entwicklung sie beteiligt sind, und Artikel 14 Absatz 3 sowie Absatz 8, soweit schwere Vorfälle die eigene Entwicklungsinfrastruktur betreffen.
Merke dir die Kombination: Stewards trifft ab dem 11.09.2026 eine Meldepflicht, aber nach Artikel 64 Absatz 10 keine Geldbuße. Wer "fällt unter den CRA" hört und an Bußgeldbescheide denkt, hat bei dieser Rolle das falsche Bild. Was für Hersteller ab dem 11.09.2026 gilt und welche Fristen dabei laufen, steht ausführlich im Beitrag über die CRA-Meldepflicht ab September.
Hier laufen die Quellen auseinander
Der Kernfall ist das kostenlose Plugin im offenen Verzeichnis, daneben eine kostenpflichtige Pro-Fassung desselben Anbieters. Dazu gibt es zwei Lesarten, und sie führen zu unterschiedlichen Ergebnissen.
Lesart A: die kostenlose Fassung wird eigenständig beurteilt
Nach dieser Lesart bleibt die freie Version für sich zu prüfen. Wird sie selbst nicht monetarisiert, also kein Kauf nötig, keine Zugangs- oder Update-Sperre gegen Bezahlung, keine Datenverarbeitung über Sicherheits- und Interoperabilitätszwecke hinaus, dann fällt sie nicht automatisch unter volle Herstellerpflichten, nur weil derselbe Anbieter daneben eine Pro-Version verkauft. Die Open Regulatory Compliance Working Group gibt die Guidance so wieder, dass eine juristische Person gleichzeitig unterschiedliche Rollen einnehmen kann, auch für unterschiedliche Versionen derselben Software, Community-Fassung und monetarisierte Fassung eingeschlossen. Gestützt wird das durch Erwägungsgrund 18 der Verordnung, wonach die Bereitstellung von Produkten, die als freie und quelloffene Software gelten und von ihren Herstellern nicht monetarisiert werden, nicht als gewerbliche Tätigkeit gelten sollte. Erwägungsgrund 18 hält außerdem fest, dass die bloße Existenz regelmäßiger Releases und die bloße finanzielle Unterstützung durch Hersteller für sich genommen keine gewerbliche Natur begründen.
Lesart B: die Pro-Version färbt auf die kostenlose ab
Mehrere auf CRA-Compliance spezialisierte Anbieter formulieren pauschaler. Wer das Plugin verkauft, eine Pro-Version anbietet, bezahlten Support leistet oder es in irgendeiner Weise monetarisiert, liefere im Rahmen gewerblicher Tätigkeit und sei im Anwendungsbereich, unabhängig von der GPL-Lizenz. Interessanterweise differenziert einer dieser Anbieter an anderer Stelle selbst wieder und stellt darauf ab, ob das kostenlose Produkt als Vertriebsinstrument für ein bezahltes Angebot dient.
Und jetzt die Offenlegung, die zu dieser Position gehört: Diese Anbieter verkaufen CRA-Compliance-Werkzeuge und Beratung an Plugin-Entwickler. Ein wirtschaftliches Interesse an einer möglichst weiten Auslegung des Anwendungsbereichs lässt sich nicht ausschließen, weil mehr erfasste Entwickler mehr Kunden bedeuten. Das ist keine Unterstellung und macht die Aussage nicht falsch. Es heißt nur: Diese Formulierung stammt nicht aus der Guidance. Sie ist deren Auslegung durch Marktteilnehmer mit Eigeninteresse. Wer eine Quelle gewichtet, gewichtet auch ihr Interesse.
Ein weiterer Vorbehalt, den kaum jemand mitliefert: Der Annex von C(2026) 5252 war maschinell nicht auswertbar. Sämtliche inhaltlichen Aussagen zu Open Source in diesem Beitrag stammen aus der Kommissionspressemitteilung, aus Fachmedien und aus NGO-Blogs. Die 67 Beispiele und die genauen Abgrenzungskriterien haben wir nicht gegengelesen. Wer dir sagt, er wisse genau, was auf Seite 41 steht, hat entweder mehr Zugang als wir oder erzählt mehr, als er weiß.
Dazu kommt: Es gibt keine Behörden- oder Kommissionsaussage, die WordPress-Plugins ausdrücklich nennt. Die Einordnung von Plugins als Produkt mit digitalen Elementen ist über Artikel 3 Nummer 1 und Nummer 13 gut begründbar. Die Quellen, die Plugins beim Namen nennen, sind ausnahmslos Blogs von Anbietern, die Compliance-Werkzeuge verkaufen.
Sieben Fragen, an denen du dich selbst einordnest
Die folgenden Fragen ersetzen keine Prüfung deines Falls durch jemanden mit Zulassung. Sie sind ein Raster zum Selbstsortieren, gebaut aus den Kriterien, die Guidance und Erwägungsgründe nach den ausgewerteten Quellen nennen. Je öfter die rechte Spalte in Richtung gewerblich zeigt, desto eher solltest du dich vorsichtshalber wie ein Hersteller verhalten.
| Frage an dein eigenes Produkt | Was die Antwort bedeutet |
|---|---|
| Ist der Zugang zur kostenlosen Fassung an eine Zahlung gekoppelt, auch verdeckt über eine Registrierung mit Kaufzwang? | Verlangter Preis für die Software oder für vorkompilierte Dateien zählt laut Guidance zur kommerziellen Tätigkeit. Freier Download ohne Gegenleistung zählt nicht. |
| Bekommt die kostenlose Fassung Sicherheitsupdates nur gegen Bezahlung? | Eine Update-Sperre gegen Bezahlung ist nach der ausgewerteten Lesart eines der stärksten Argumente für Monetarisierung der freien Fassung selbst. |
| Verlangst du personenbezogene Daten über Sicherheits- und Interoperabilitätszwecke hinaus? | Die Guidance nennt genau das als kommerzielle Tätigkeit. Eine E-Mail-Adresse für den Download einzusammeln ist damit ein Risikofaktor, keine Nebensache. |
| Ist die kostenlose Fassung funktional eigenständig, oder ist sie eine Zahlschranke vor der eigentlichen Funktion? | Ein eigenständig nutzbares Produkt spricht für Lesart A. Eine Gratis-Hülle, die ohne Kauf nichts leistet, spricht für die funktionale Verzahnung mit dem Verkauf. |
| Monetarisierst du über das Programm andere Dienste, etwa Werbung oder Datenerhebung? | Die Software als Plattform zur Monetarisierung anderer Produkte gilt laut Guidance als kommerzielle Tätigkeit, auch wenn die Software selbst gratis ist. |
| Sind Spenden faktisch Bedingung für den Zugang zur Software oder zu Updates? | Freiwillige Spenden ohne Gewinnabsicht gelten nicht als gewerblich. Spenden, die de facto Zugangsvoraussetzung sind, schon. |
| Vermarktest du unter eigenem Namen oder eigener Marke? | Das ist das Merkmal aus Artikel 3 Nummer 13, das unabhängig vom Preis greift. Es beantwortet die Herstellerfrage nicht allein, es ist aber die Tür, durch die sie überhaupt kommt. |
Wenn du das Ergebnis in etwas Verwertbares übersetzen willst: Unser kostenloses Werkzeug zur CRA-Selbstauskunft erzeugt aus deinen Angaben eine security.txt und die öffentlichen Kontaktangaben für Schwachstellenmeldungen, ohne dass wir eine E-Mail-Adresse erheben. Das nimmt dir die Einordnung nicht ab. Es macht nur den Teil fertig, der unabhängig von der Einordnung sinnvoll ist.
Wie wir uns selbst einordnen
hafenstudios ist genau der Fall, um den gestritten wird. Wir haben mehrere Plugins mit kostenloser Fassung und kostenpflichtiger Pro-Version, darunter Wellenbrecher, das seit dem 21.08.2026 im WordPress-Verzeichnis liegt. Wir haben mit dem Hafen-Theme auch ein Stück Software ganz ohne bezahlte Fassung. Alles steht unter GPLv2 oder später.
Unsere Haltung dazu: Wir verhalten uns wie ein Hersteller. Das ist die vorsichtige Annahme, und sie kostet uns weniger, als es kosten würde, im Ernstfall falsch gelegen zu haben. Praktisch heißt das dokumentierte Kontaktwege für Schwachstellenmeldungen, ein Verfahren für die Fristen aus Artikel 14 und die Vorbereitung auf das volle Pflichtenprogramm ab dem 11.12.2027, wenn CE-Kennzeichnung, technische Dokumentation, Konformitätsbewertung und die Software-Stückliste aus Anhang I Teil II greifen.
Wir sagen dabei offen, dass die Frage nicht abschließend geklärt ist. Ein Anwaltstermin dazu steht an. Das ist ehrlicher, als hier eine Gewissheit zu behaupten, die die Quellenlage nicht hergibt. Nochmal deutlich an der Stelle, wo es zählt: Dieser Beitrag ist eine Einordnung und keine Rechtsberatung. Für die verbindliche Bewertung deines Falls brauchst du jemanden mit Zulassung.
Die Unsicherheit ist der eigentliche Schaden
Jetzt die Meinung, für die dieser Beitrag geschrieben ist. Das Problem an dieser Lage ist nicht die Regulierung als solche. Sicherheitsanforderungen an Software, die auf hunderttausenden Websites läuft, sind gut begründbar. Das Problem ist, dass niemand verlässlich sagen kann, wer erfasst ist.
Diese Unsicherheit verteilt sich ungleich. Ein Konzern hat eine Rechtsabteilung, die eine Einschätzung schreibt, und ein Budget, das eine falsche Einschätzung überlebt. Ein Zwei-Personen-Betrieb hat einen Abend und eine Trefferliste, auf der die ersten fünf Ergebnisse von Anbietern stammen, die ihm ein Abo verkaufen wollen. Die Kosten der Unklarheit trägt der Kleine, obwohl die Guidance ausdrücklich für Kleinstunternehmen und KMU geschrieben wurde.
Der deutsche Rahmen macht es nicht ruhiger. Gemeldet wird an das CSIRT des Mitgliedstaats der Hauptniederlassung, für Deutschland das BSI mit CERT-Bund. Das deutsche CRA-Durchführungsgesetz war am 21.08.2026 noch nicht in Kraft. Es liegt als Bundestagsdrucksache 21/6134 vom 26.05.2026 im Verfahren, erste Lesung am 11.06.2026, danach Innenausschuss. Neue Pflichten schafft es nicht, es benennt die Zuständigkeiten. Artikel 14 gilt am 11.09.2026 unabhängig davon unmittelbar. Zum Vergleich: Beim AI Act ist das deutsche Durchführungsgesetz seit dem 29.07.2026 in Kraft.
Was daraus folgt, ist unspektakulär. Verhalte dich vorsichtshalber wie ein Hersteller, wenn mehrere der sieben Fragen in Richtung gewerblich zeigen. Dokumentiere, wie du zu deiner Einordnung gekommen bist. Und misstraue jeder Quelle, die dir diese Frage in zwei Sätzen beantwortet, ganz besonders dann, wenn sie im dritten Satz etwas verkauft.
Was wir zu Sicherheit und Meldewegen offenlegen
Auf unserer Sicherheitsseite steht, wie du eine Schwachstelle in einem unserer Plugins meldest, wie wir damit umgehen und in welchem Zeitrahmen. Das ist der Teil, den ein Anbieter unabhängig von der Herstellerfrage schuldig ist.
Häufige Fragen
Macht mich eine kostenlose Abgabe wirklich zum Hersteller?
Nach Artikel 3 Nummer 13 CRA kommt es auf den Preis nicht an. Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet, im englischen Wortlaut "whether for payment, monetisation or free of charge". Ob die Vermarktung im Rahmen einer gewerblichen Tätigkeit stattfindet, ist die zweite, umstrittene Frage. Der CRA definiert diesen Begriff im Artikeltext nicht.
Fällt mein kostenloses Plugin automatisch unter den CRA, weil es eine Pro-Version gibt?
Nach den Quellen, die sich mit der Guidance selbst befassen, nicht automatisch. Sie beschreiben eine fallabhängige Prüfung: Eine eigenständige, nicht monetarisierte Fassung bleibt im leichteren Regime oder außerhalb, es sei denn, sie ist selbst monetarisiert oder funktional an den Verkauf gekoppelt. Kommerzielle Compliance-Anbieter vertreten die weitere Lesart. Die Frage ist nicht abschließend geklärt.
Was ist ein Open-Source-Software-Steward?
Artikel 3 Nummer 14 CRA beschreibt eine juristische Person, die kein Hersteller ist und deren Zweck darin besteht, dauerhaft und systematisch die Entwicklung bestimmter quelloffener Produkte zu unterstützen, die für kommerzielle Tätigkeiten bestimmt sind. Artikel 24 verlangt eine dokumentierte Cybersicherheitspolitik, Zusammenarbeit mit den Behörden und eine eingeschränkte Meldepflicht. Nach Artikel 64 Absatz 10 sind Stewards von Geldbußen nach dieser Vorschrift ausgenommen.
Ist die Kommissions-Guidance verbindlich?
Nein. Die Kommission stellt selbst klar, dass allein der Gerichtshof der Europäischen Union das Unionsrecht verbindlich auslegen kann. C(2026) 5252 ändert keine Pflicht und keinen Stichtag. Für Marktüberwachungsbehörden dürfte sie praktisch trotzdem ein Referenzpunkt sein, weshalb man sie kennen sollte, ohne sie für Gesetz zu halten.
Ab wann gilt was?
Kapitel IV zu den notifizierten Stellen gilt seit dem 11.06.2026. Artikel 14 mit den Meldepflichten der Hersteller gilt ab dem 11.09.2026. Die Verordnung im Übrigen gilt ab dem 11.12.2027, dazu gehören CE-Kennzeichnung, technische Dokumentation, Konformitätsbewertung und die Software-Stückliste aus Anhang I Teil II. Fundstelle für alle drei Daten ist Artikel 71 CRA.
