Intern entwickelte Maschinen & Software: Wann der CRA greift
„Das betrifft uns nicht, wir verkaufen die Software ja gar nicht." Diesen Satz hören Compliance-Verantwortliche häufig, wenn es um den Cyber Resilience Act (CRA) und intern entwickelte Produkte geht. Die Einschätzung ist nachvollziehbar, greift aber in vielen Fällen zu kurz. Denn der CRA knüpft nicht am klassischen Produktverkauf an, sondern am Begriff der Bereitstellung auf dem Markt, und der ist weiter gefasst, als viele annehmen.
Inhalt
Was der CRA unter „Bereitstellung auf dem Markt" versteht
Der CRA definiert den Begriff als die Lieferung eines Produkts zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit, unabhängig davon, ob dies entgeltlich oder unentgeltlich geschieht.
Entscheidend sind damit zwei Kriterien: Das Produkt wird einem Dritten zur Verfügung gestellt, und dies geschieht im Rahmen einer kommerziellen Tätigkeit. Wer ein Softwaretool ausschließlich für den eigenen Betrieb entwickelt, es auf eigenen Systemen betreibt und es keinem Dritten zugänglich macht, fällt damit grundsätzlich nicht in den Anwendungsbereich des CRA. Dieses Verständnis steht im Einklang mit dem EU Blue Guide, der als Orientierungsdokument für die Anwendung von EU-Produktregulierungen dient.
Soweit die Theorie. In der Praxis zeigt sich allerdings, dass die Grenzen zwischen „rein intern" und „auf dem Markt bereitgestellt" bei vielen Herstellern fließender sind als zunächst angenommen.
Grenzfälle: Wann interne Entwicklungen doch CRA-relevant werden
In der Praxis gibt es eine Reihe von Konstellationen, in denen intern entwickelte Produkte den Bereich des reinen Eigengebrauchs verlassen, oft ohne dass sich die Beteiligten dessen bewusst sind. Die folgenden Szenarien begegnen uns in der Beratungspraxis regelmäßig.
Weitergabe innerhalb eines Konzerns
Einer der häufigsten Grenzfälle betrifft konzerninterne Weitergaben. Ein Unternehmen entwickelt eine Steuerungssoftware, ein Diagnosetool oder eine Maschinenkomponente und stellt diese einer Tochtergesellschaft oder einem Schwesterunternehmen zur Verfügung. Obwohl die Weitergabe innerhalb der Unternehmensgruppe stattfindet, handelt es sich juristisch um eine Transaktion zwischen zwei eigenständigen Rechtspersönlichkeiten. Erfolgt diese Weitergabe im Rahmen einer Geschäftstätigkeit (wovon bei konzerninternen Lieferungen in der Regel auszugehen ist), liegt eine Bereitstellung auf dem Markt im Sinne des CRA vor.
Das gilt unabhängig davon, ob ein Entgelt fließt. Auch eine kostenfreie Überlassung an eine rechtlich eigenständige Konzerngesellschaft kann den Tatbestand erfüllen.
Software-Komponenten in verkauften Produkten
Ein weiterer relevanter Fall: Ein Hersteller entwickelt intern ein Software-Modul (etwa eine Kommunikationsbibliothek, ein Diagnoseprotokoll oder eine Firmware-Komponente) und integriert dieses in ein Produkt, das anschließend an Kunden ausgeliefert wird. Die Komponente selbst wird zwar nie separat vermarktet, gelangt aber als Bestandteil des verkauften Produkts auf den Markt.
In dieser Konstellation wird das Gesamtprodukt inklusive aller integrierten Komponenten auf dem Markt bereitgestellt. Der Hersteller muss daher sicherstellen, dass auch intern entwickelte Bestandteile den grundlegenden Cybersicherheitsanforderungen des CRA entsprechen. Das betrifft insbesondere die in Anhang I Teil I aufgeführten Anforderungen an Entwurf, Entwicklung und Produktion.
Kundenportale, Cloud-Dienste und Schnittstellen
Viele Hersteller bieten ihren Kunden digitale Dienste an, die intern entwickelt wurden: Serviceportale für Fernwartung, Cloud-basierte Datenplattformen, Konfiguratoren oder API-Schnittstellen. Auch wenn diese Anwendungen nie als eigenständiges Produkt verkauft werden, kann ihre Bereitstellung an Kunden eine Bereitstellung auf dem Markt darstellen.
Besonders relevant wird dies, wenn die Software als Remote-Datenverarbeitungslösung im Sinne des CRA einzuordnen ist, also als entfernt stattfindende Datenverarbeitung, deren Software der Hersteller selbst oder unter seiner Verantwortung entwickelt und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. In diesem Fall wird die Remote-Komponente regulatorisch als Teil des Produkts mit digitalen Elementen betrachtet.
Unentgeltlich bereitgestellte Software
Der CRA erfasst ausdrücklich auch Produkte, die kostenlos bereitgestellt werden, sofern dies im Rahmen einer Geschäftstätigkeit geschieht. Ein Hersteller, der ein intern entwickeltes Diagnose- oder Konfigurationstool seinen Kunden kostenfrei zum Download anbietet, bringt dieses Produkt im Sinne des CRA in den Verkehr. Die Unentgeltlichkeit allein schließt die Anwendbarkeit nicht aus.
Vergleich mit der Maschinenverordnung
Interessant ist der Blick auf die Maschinenverordnung (EU) 2023/1230, die ab Januar 2027 verbindlich gilt. Dort ist die Eigenherstellungs-Thematik deutlich klarer geregelt: Wer eine Maschine oder ein dazugehöriges Produkt für den eigenen Gebrauch herstellt, gilt als Hersteller und unterliegt den entsprechenden Pflichten, einschließlich Konformitätsbewertung und CE-Kennzeichnung.
Der CRA verfolgt hier eine andere Logik. Er knüpft nicht an die Herstellung als solche an, sondern an die Bereitstellung auf dem Markt. Das bedeutet: Die reine Tatsache, dass ein Unternehmen eine Software oder ein Gerät selbst entwickelt hat, begründet allein noch keine CRA-Pflichten. Entscheidend ist, ob und wie das Produkt Dritten zugänglich gemacht wird.
Für Hersteller, die sowohl Maschinen als auch digitale Produkte intern entwickeln, ergibt sich daraus eine unterschiedliche regulatorische Bewertung desselben Sachverhalts, je nachdem, welches Regelwerk einschlägig ist. Diese Divergenz macht eine sorgfältige Einzelfallbewertung unumgänglich.
Warum eine pauschale Einschätzung riskant ist
Die Beispiele zeigen: Die Frage, ob intern entwickelte Produkte unter den CRA fallen, lässt sich nicht pauschal mit Ja oder Nein beantworten. Sie hängt davon ab, wie das Produkt genutzt, weitergegeben und in den Markt eingebettet wird.
Viele Hersteller haben keinen vollständigen Überblick darüber, welche internen Entwicklungen letztlich in CRA-relevanten Kontexten zum Einsatz kommen. Das betrifft insbesondere Software-Bibliotheken, die in mehreren Produktlinien wiederverwendet werden, Werkzeuge, die ursprünglich für den internen Gebrauch entstanden und später Kunden zugänglich gemacht wurden, sowie Remote-Datenverarbeitungskomponenten, die funktional an verkaufte Produkte gekoppelt sind.
Bereit für den CRA?
Die Beispiele zeigen: Interne Entwicklungen sind häufiger CRA-relevant, als viele Hersteller annehmen. Wie gut Ihr Unternehmen für diesen Fall aufgestellt ist, zeigt unser CRA-Readiness-Check. In wenigen Minuten erhalten Sie eine Einschätzung Ihres aktuellen Reifegrads.
Fazit
Der CRA erfasst nicht jede intern entwickelte Software oder Maschine, aber deutlich mehr, als viele Hersteller zunächst annehmen. Insbesondere konzerninterne Weitergaben, in Produkte eingebettete Komponenten und kundenseitig bereitgestellte Dienste fallen häufig in den Anwendungsbereich der Verordnung.
Anders als die Maschinenverordnung, die Eigenherstellung explizit adressiert, setzt der CRA am Bereitstellungsakt an. Das macht die Bewertung im Einzelfall komplexer, aber nicht weniger relevant. Hersteller sind gut beraten, ihre internen Entwicklungen systematisch auf CRA-Relevanz zu prüfen; die Meldepflichten gelten seit September 2026, die vollständige Anwendbarkeit folgt im Dezember 2027.
Individuelle Einordnung gewünscht?
Nicht jede Konstellation lässt sich pauschal einordnen. In einem unverbindlichen Erstgespräch schauen wir uns Ihre konkrete Situation an und benennen die nächsten sinnvollen Schritte.
