CRA für Agenturen und Individualsoftware: Wer Hersteller ist und wer nicht
Eine Agentur, die nach Vorgaben eines Auftraggebers entwickelt, ist Dienstleister. Hersteller wird sie, sobald sie ein eigenes Plugin, Theme oder Produkt unter eigenem Namen verkauft. Diese Seite ordnet die typischen Fälle ein, von der Kunden-Website bis zur Standardsoftware, und zeigt, was in Verträge gehört.
Hersteller nach Artikel 3 Nummer 13 der Verordnung (EU) 2024/2847 ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet. Eine Agentur, die nach Vorgaben eines Auftraggebers entwickelt, ist nach dieser Definition Dienstleister; Hersteller ist der Auftraggeber, der das Produkt unter seinem Namen vermarktet. Hersteller wird die Agentur selbst, sobald sie ein eigenes Plugin, Theme oder Produkt verkauft. Websites und reine Online-Dienste sind keine Produkte (Erwägungsgrund 12). Software, die ein Unternehmen selbst für den eigenen Betrieb entwickelt und nicht weitergibt, ist nicht auf dem Markt bereitgestellt; wird Individualsoftware gegen Entgelt an einen Kunden geliefert, gehen BSI und EU-Kommission von einer Bereitstellung aus, auch bei einem einzigen Exemplar.
Das Wichtigste
- Hersteller ist, wer entwickelt oder entwickeln lässt und unter eigenem Namen vermarktet (Artikel 3 Nummer 13).
- Agentur nach Vorgaben des Auftraggebers: Dienstleister. Auftraggeber, der das Produkt unter seinem Namen vermarktet: Hersteller (Artikel 3 Nummer 13, zweite Alternative).
- Eigenes Plugin, Theme oder eigene App, mehrfach verkauft: Die Agentur ist Hersteller mit allen Pflichten; die Meldepflicht gilt seit dem 11. September 2026.
- Websites und reine Online-Dienste sind keine Produkte (Erwägungsgrund 12); für sie gilt gegebenenfalls NIS2.
- Ein Open-Source-Plugin ohne Geschäftstätigkeit bleibt außerhalb. Preis, bezahlte Stufe oder Datenverarbeitung als Bedingung ziehen es hinein (Artikel 3 Nummer 22, Erwägungsgründe 15 und 18).
Wer ist Hersteller nach Artikel 3 Nummer 13?
Die Verordnung kennt zwei Wege zur Herstellerrolle: selbst entwickeln und unter eigenem Namen vermarkten, oder konzipieren, entwickeln oder herstellen lassen und unter eigenem Namen vermarkten. Der zweite Weg ist die Auftragsentwicklung: Wer beauftragt und das Ergebnis als eigenes Produkt anbietet, ist Hersteller, ohne eine Zeile selbst geschrieben zu haben. Beide Wege setzen voraus, dass das Produkt auf dem Markt bereitgestellt wird, nach Artikel 3 Nummer 22 also im Rahmen einer Geschäftstätigkeit, entgeltlich oder unentgeltlich. Erwägungsgrund 15 nennt die Indizien: Preis, Entgelt für Support über die Kostendeckung hinaus, Gewinnerzielungsabsicht, Verarbeitung personenbezogener Daten als Nutzungsbedingung.
Die Kommissionsleitlinie C(2026) 5252 vom 27. Juli 2026 (rechtlich unverbindlich) äußert sich zur Auftragsentwicklung nicht ausdrücklich. Den Gedanken der Kontrolle nutzt sie für Open Source: Verantwortlich ist, wer die Software veröffentlicht und die primäre Kontrolle über Entwicklung, Releases und Verteilung hat (Rn. 49). Für die Fernverarbeitung stellt sie klar, dass Software, die ein Dienstleister nach Vorgaben und Spezifikationen des Herstellers baut, unter dessen Verantwortung entwickelt ist (Rn. 195).
Auftragsentwicklung: Agentur als Dienstleister, Auftraggeber als Hersteller
Entwickelt eine Agentur nach Vorgaben des Auftraggebers, und bringt dieser das Ergebnis unter seinem Namen auf den Markt, ist der Auftraggeber Hersteller. Die Agentur ist Zulieferer ohne eigene Pflichten aus Artikel 13 und 14, aber der Hersteller braucht sie für Softwarestückliste und Schwachstellenbehebung. Die Herstellerrolle knüpft an die Vermarktung unter eigenem Namen oder eigener Marke an (Artikel 3 Nummer 13), nicht an die Bezeichnung im Vertrag. Ein Vertrag kann regeln, wer die Arbeit macht, wer welche Unterlagen liefert und unter wessen Namen das Produkt erscheint. Die Herstellerrolle folgt aber aus diesen Tatsachen, nicht aus einer Bezeichnung im Vertrag, und gegenüber der Marktüberwachung abgeben lässt sich die Verantwortung nicht: Ein Hersteller, der Arbeiten an Subunternehmer vergibt, darf seine Verantwortung nach dem Blue Guide der Kommission "auf keinen Fall" an sie weiterreichen (Abschnitt 3.1).
Wenn der Auftraggeber die Software nur selbst nutzt
Entwickelt ein Unternehmen Software selbst für den eigenen Betrieb und gibt sie nicht weiter, fehlt die Abgabe an einen anderen; die Software ist nicht auf dem Markt bereitgestellt (Artikel 3 Nummer 22). Die FAQ der Kommission sagt das für Werkzeuge, die ein Hersteller für den eigenen Gebrauch entwickelt (Frage 1.5). Liefert dagegen ein Softwarehaus Individualsoftware gegen Entgelt an einen Kunden, gehen BSI und EU-Kommission übereinstimmend von einer Bereitstellung auf dem Markt aus. Das BSI nennt in seiner FAQ zum CRA ausdrücklich "Sonderanfertigungen und Individual-Software, unabhängig von der Stückzahl und allgemeinen Verfügbarkeit". Die FAQ der Kommission behandelt Software, die für die Bedürfnisse eines bestimmten gewerblichen Nutzers entwickelt wird, als maßgeschneidertes Produkt, das nur bei zwei Anforderungen abweichen darf (Frage 4.2.5), und die Leitlinie wertet Quellcode, den ein Unternehmen einem Kunden für eine interne Plattform lizenziert, als in Verkehr gebracht (Beispiel 7). Das passt zum Wortlaut: Artikel 3 Nummer 22 erfasst die Abgabe auch "zur Verwendung", nicht nur zum Weitervertrieb (Leitlinie Rn. 10), und die Bereitstellung bezieht sich auf jedes einzelne Exemplar (Leitlinie Rn. 11). Leitlinie und FAQ sind rechtlich unverbindlich; verbindlich auslegen kann nur der Europäische Gerichtshof. Hersteller ist in diesem Fall in der Regel das Softwarehaus, denn der Kunde, der nur intern nutzt, vermarktet nichts unter seinem Namen. Nicht geklärt ist, wer Hersteller ist, wenn die Software unter dem Namen des Kunden läuft oder unter dessen Weisung und Kontrolle entsteht. Wer Individualsoftware liefert, sollte deshalb im Vertrag festhalten, unter wessen Namen sie geliefert wird und wer Schwachstellen behandelt und meldet. Wird sie später weitergegeben oder Teil eines Produkts, ist sie in jedem Fall erfasst.
Für maßgeschneiderte Produkte an gewerbliche Nutzer erlaubt die Verordnung Abweichungen bei der sicheren Standardkonfiguration (Anhang I Teil I Nummer 2 Buchstabe b) und bei den kostenlosen Sicherheitsupdates (Anhang I Teil II Nummer 8, Erwägungsgrund 64). Die Schwachstellenbehandlung selbst bleibt Pflicht.
Wann ist die Agentur selbst Hersteller?
Sobald sie ein Produkt unter eigenem Namen vermarktet: ein Plugin für ein Content-Management-System, ein Theme, eine App oder eine Bibliothek, mehrfach verkauft oder im Rahmen des Geschäfts kostenlos angeboten. Artikel 3 Nummer 1 nimmt separat in Verkehr gebrachte Softwarekomponenten ausdrücklich in den Produktbegriff auf; ein Plugin wird beim Kunden installiert, anders als eine Website. Auf die Stückzahl kommt es nicht an. Hersteller ist auch, wer fremde Software unter eigener Marke verkauft (Artikel 21) oder ein fremdes Produkt wesentlich ändert und bereitstellt (Artikel 22).
Als Hersteller trägt die Agentur alle Pflichten aus Artikel 13 und Anhang I ab dem 11. Dezember 2027: Risikobewertung, Softwarestückliste, Unterstützungszeitraum von mindestens fünf Jahren, Kontaktadresse für Schwachstellen, Dokumentation, CE-Kennzeichnung. Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026 und erfasst nach Artikel 69 Absatz 3 auch Plugins, die seit Jahren im Umlauf sind. Die meisten Plugins sind Standardprodukte; eines mit Anmeldung, Single Sign-on oder Passwortverwaltung als Kernfunktion kann unter Anhang III Klasse I fallen und braucht dann ohne harmonisierte Norm eine notifizierte Stelle (Artikel 32 Absatz 2). Übersicht unter Die Pflichten der Hersteller.
Websites und reine Online-Dienste
Eine Website, die eine Agentur für einen Kunden baut, ist kein Produkt mit digitalen Elementen. Erwägungsgrund 12 nimmt Websites, die keine Produktfunktion unterstützen, aus und verweist Software-as-a-Service auf die NIS2-Richtlinie. Eine Anwendung, die nur im Browser läuft, ist nach der Leitlinie ebenfalls kein Produkt (Rn. 21, Beispiel 5). Produkt ist, was beim Nutzer heruntergeladen oder installiert wird und auf seinem System läuft: App, Desktop-Client, Browser-Erweiterung, Plugin (Rn. 20).
Eine Ausnahme: Baut die Agentur für den Kunden eine App mit Backend, ohne das die App eine Funktion verliert, ist das Backend Fernverarbeitung nach Artikel 3 Nummer 2. Es gehört dann zum Produkt des Kunden, weil es unter dessen Verantwortung entwickelt wurde; die Agentur, die es betreibt, ist Dienstleister (Leitlinie Rn. 195 und 196). Details unter SaaS, Cloud und Fernverarbeitung.
Open-Source-Plugins und Monetarisierung
Viele Agenturen veröffentlichen Plugins als freie und quelloffene Software nach Artikel 3 Nummer 48. Nach Erwägungsgrund 18 fällt sie nur in den Anwendungsbereich, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Ein Plugin ohne Preis, bezahlte Stufe oder Datenverarbeitung als Bedingung bleibt außerhalb; Spenden bis zur Kostendeckung ändern daran nichts (Erwägungsgrund 15). Das vereinfachte Regime für Verwalter quelloffener Software (Erwägungsgrund 19) gilt nur für juristische Personen, die Projekte dauerhaft tragen.
Nach der Leitlinie liegt eine Bereitstellung auf dem Markt neben einem Preis in drei weiteren Fällen vor: wenn der Zugang zu einer Version samt technischer Hilfe oder Leistungsoptimierung an ein Entgelt gebunden ist (Rn. 57), wenn das Plugin als Plattform für den Verkauf anderer Dienste dient oder wenn personenbezogene Daten als Nutzungsbedingung verarbeitet werden (Rn. 54). Getrennt angebotene Beratung, Schulung oder Support machen es nicht kommerziell (Rn. 55 und 56). Wer fremde Open Source beim Kunden installiert und betreut, bringt sie nicht in Verkehr, solange er sie dabei nicht wesentlich ändert (Rn. 59, Beispiel 19). Beim Modell "kostenlose Version plus Pro-Version" ist die Pro-Version damit ein Produkt. Die kostenlose Version ist nach der Leitlinie ein eigenes, nicht in Verkehr gebrachtes Produkt; eine Agentur als juristische Person trägt dafür die Pflichten eines Verwalters quelloffener Software nach Artikel 24 (Rn. 52 und 53). Mehr unter Open Source und CRA.
Was in Verträgen geregelt gehört
Die Herstellerrolle lässt sich nicht wegverhandeln, die Arbeit dahinter schon. Fünf Punkte gehören in jeden Entwicklungs- und Wartungsvertrag:
- Rolle. Wer ist Hersteller nach Artikel 3 Nummer 13, wer Zulieferer? Begründet aus der Vermarktung.
- Schwachstellenbehandlung. Wer behebt Schwachstellen während des Unterstützungszeitraums nach Artikel 13 Absatz 8, in welcher Zeit, zu welchen Kosten? Sicherheitsupdates müssen getrennt von Funktionsupdates möglich (Anhang I Teil II Nummer 2) und für Nutzer kostenlos sein (Nummer 8). Ein endender Wartungsvertrag beendet den Unterstützungszeitraum nicht.
- Komponenten. Wer führt die Softwarestückliste (Anhang I Teil II Nummer 1), wer prüft Bibliotheken nach Artikel 13 Absatz 5, wer meldet Funde an deren Hersteller (Absatz 6)?
- Meldeweg. Wer betreibt die Kontaktadresse für Schwachstellen (Artikel 13 Absatz 17)? Erfährt die Agentur von einer Ausnutzung beim Produkt des Kunden, muss der Hersteller das sofort wissen, weil seine 24-Stunden-Frist mit der Kenntnis beginnt. Die Meldung reicht der Hersteller ein; was ein Dienstleister übernehmen kann, steht unter CRA-Meldepflicht auslagern.
- Dokumentation und Quellcode. Technische Dokumentation zehn Jahre aufbewahren (Artikel 13 Absatz 13), jedes Sicherheitsupdate zehn Jahre verfügbar halten (Absatz 9). Beides braucht Zugriff auf Quellcode und Build-Umgebung, auch nach Ende der Zusammenarbeit.
Vier Fälle im Überblick
| Fall | Rolle | Pflichten |
|---|---|---|
| Agentur baut eine Website für einen Kunden | Kein Produkt (Erwägungsgrund 12). Agentur ist Dienstleister, Kunde ist Betreiber. | Keine Pflichten aus dem CRA. Für den Betreiber kann NIS2 gelten. |
| Agentur verkauft ein eigenes Plugin oder Theme | Agentur ist Hersteller (Artikel 3 Nummer 13), Kunden sind Nutzer. | Artikel 13 und Anhang I ab dem 11. Dezember 2027; Meldepflicht nach Artikel 14 seit dem 11. September 2026. |
| Softwarehaus liefert Individualsoftware an einen Kunden | Vermarktet der Kunde die Software, ist er Hersteller und das Softwarehaus Zulieferer. Nutzt er sie nur intern, ist die entgeltliche Lieferung nach BSI und Kommission eine Bereitstellung auf dem Markt (BSI-FAQ, FAQ der Kommission 4.2.5, Leitlinie Beispiel 7); Hersteller ist dann in der Regel das Softwarehaus. | Beim vermarktenden Kunden alle Herstellerpflichten. Bei interner Nutzung die Herstellerpflichten beim Softwarehaus; für maßgeschneiderte Produkte sind vereinbarte Abweichungen bei zwei Anforderungen möglich (Anhang I). Grenzfälle (Name des Kunden auf der Software, Entwicklung unter seiner Kontrolle) rechtlich prüfen lassen. |
| Softwarehaus verkauft Standardsoftware | Hersteller. | Alle Pflichten aus Artikel 13, 14 und Anhang I; Produktklasse nach Anhang III prüfen. |
Für Agenturen und Softwarehäuser, die Hersteller sind oder diese Rolle für Kunden operativ tragen, bietet CRA Response Center die Bereitschaft für Artikel 14 als Dienst. Das Tool liest das Sicherheits-Postfach mit, erkennt wichtige Meldungen, benachrichtigt die zuständigen Personen per SMS und E-Mail und hält Kenntnis und Fristen im Verlauf fest. Entscheidung und Einreichung bleiben beim Hersteller.
Checkliste für Agenturen und Softwarehäuser
- Eigene Produkte erfassen. Plugins, Themes, Apps, Bibliotheken unter eigenem Namen, mit Versionen und Verbreitung; für sie gilt die Meldepflicht seit dem 11. September 2026.
- Monetarisierung prüfen. Bei Open-Source-Plugins: Pro-Version, bezahlte Stufe, Datenverarbeitung als Bedingung? Dann liegt eine Geschäftstätigkeit vor.
- Klasse prüfen. Hat ein eigenes Produkt eine Funktion aus Anhang III als Kernfunktion?
- Verträge nachziehen. Rolle, Schwachstellenbehandlung, Stückliste, Meldeweg, Dokumentation und Quellcodezugang regeln.
- Meldeadresse einrichten. Für eigene Produkte Postfach und security.txt; für Kundenprodukte den Weg zum Hersteller festlegen.
- Kenntnis dokumentieren. Zeitpunkt und Quelle jedes Hinweises festhalten, Hersteller sofort informieren.
Häufige Fragen
Wir entwickeln ausschließlich im Auftrag. Sind wir Hersteller?
Das hängt davon ab, was der Auftraggeber mit der Software macht. Hersteller ist, wer das Produkt entwickeln lässt und unter eigenem Namen vermarktet (Artikel 3 Nummer 13). Vermarktet Ihr Auftraggeber das Ergebnis, ist er Hersteller und Sie Zulieferer. Liefern Sie Individualsoftware gegen Entgelt an einen Kunden, der sie nur intern nutzt, gehen BSI und Kommission von einer Bereitstellung auf dem Markt aus (BSI-FAQ zum CRA, FAQ der Kommission 4.2.5, Leitlinie Beispiel 7); Hersteller sind dann in der Regel Sie. Grenzfälle, etwa wenn die Software unter dem Namen des Kunden läuft, lassen Sie rechtlich prüfen.
Wir haben ein Plugin, das 2.000 Kunden gekauft haben. Was gilt?
Sie sind Hersteller. Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026 für alle Versionen im Umlauf (Artikel 69 Absatz 3); Anhang I, Dokumentation und CE-Kennzeichnung für Versionen ab dem 11. Dezember 2027.
Ist eine Kunden-Website ein Produkt mit digitalen Elementen?
Nein. Erwägungsgrund 12 nimmt Websites aus, die keine Produktfunktion unterstützen. Anders liegt es bei einem Backend, ohne das eine App des Kunden nicht funktioniert; das ist Fernverarbeitung nach Artikel 3 Nummer 2 und gehört zum Produkt.
Unser Open-Source-Plugin ist kostenlos, aber wir verkaufen Support. Sind wir drin?
Nach der Leitlinie nicht allein deshalb (Rn. 55 und 56, Beispiel 18). Getrennt angebotener Support macht ein Plugin nicht kommerziell. Anders bei einer bezahlten Version, die Funktionen freischaltet, oder wenn der Zugang zur Software samt Wartung an ein Entgelt gebunden ist (Erwägungsgrund 15, Leitlinie Rn. 57).
Kann der Vertrag festlegen, dass die Agentur Hersteller ist?
Nicht durch eine bloße Bezeichnung. Der Vertrag kann die Arbeit verteilen und festlegen, unter wessen Namen das Produkt erscheint. Die Rolle folgt dann aus diesen Tatsachen, vor allem aus der Vermarktung unter eigenem Namen (Artikel 3 Nummer 13). Die Verantwortung weiterreichen kann ein Hersteller nach dem Blue Guide der Kommission nicht, auch nicht an einen Subunternehmer (Abschnitt 3.1).
Weiterlesen
- Wer ist Hersteller nach dem CRA?Die Rollen im Überblick.
- Open Source und CRASteward, gewerbliche Nutzung, Meldepflichten.
- SaaS, Cloud und FernverarbeitungWann ein Online-Dienst zum Produkt gehört.
- CRA-Meldepflicht auslagernWas ein Dienstleister übernehmen kann und was nicht.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 3, 13, 14, 21, 22, 32, 69, Anhang I, Anhang III, Erwägungsgründe 12, 15, 18, 19, 64, EUR-Lex, 20. November 2024.
- Leitlinie der Kommission C(2026) 5252, Annex, Rn. 10, 11, 20, 21, 49 bis 59, 195 und 196, Beispiele 5, 7, 18 und 19, Europäische Kommission, 27. Juli 2026.
- FAQs on the Cyber Resilience Act, Version 1.4, Fragen 1.5 und 4.2.5, Kommissionsdienststellen, 4. September 2026.
- Cyber Resilience Act, Fragen und Antworten, BSI, abgerufen am 8. Oktober 2026.
- Leitfaden für die Umsetzung der Produktvorschriften der EU 2022 (Blue Guide), Abschnitt 3.1, Europäische Kommission, 29. Juni 2022.
- Cyber Resilience Act guidance: products, obligations, Gamingtechlaw, 5. August 2026.
- EU Cyber Resilience Act: New Guidance Clarifies Scope and Reporting, Orrick, September 2026.
- CRA Commission Guidance, Noze, 28. Juli 2026.
- Cyber Resilience Act: the fine line between SaaS and digital products, DLA Piper, 16. Februar 2026.
- EU clarifies CRA rules for non-commercial open source, Open Source For U, 29. Juli 2026.
- FAQ: The Cyber Resilience Act, cyberresilienceact.eu, 2026.
- Single Reporting Platform: Frequently Asked Questions, ENISA, Stand 3. Oktober 2026.