Cyber Resilience Act und Individualsoftware: Betrifft mich das, wenn die Software nur intern läuft?

"Das betrifft uns nicht, die Software läuft doch nur intern." Diesen Satz hören wir seit Monaten immer wieder. Der Cyber Resilience Act und Individualsoftware klingen nach einem Thema für Softwarehäuser. Für Firmen, die ihre Produkte aktiv verkaufen. Wer sein eigenes System nur für den eigenen Betrieb nutzt, fühlt sich schnell außen vor.

Oft stimmt das auch. Aber nicht immer. Die Grenze zwischen "rein intern" und "am Markt bereitgestellt" ist enger gezogen, als viele Unternehmen annehmen. Gerade bei gewachsener Individualsoftware verschiebt sich diese Grenze oft schleichend. Über Jahre war sie nur für den eigenen Betrieb gedacht. Dann ändert sich etwas, ohne dass es jemand bewusst entscheidet.

Dieser Artikel zeigt, wann Individualsoftware tatsächlich ausgenommen ist. Und wo die Ausnahme endet. Dazu: Was Sie von Ihrem Entwicklungsdienstleister verlangen sollten, auch wenn der Cyber Resilience Act (CRA) formal nicht greift.

Was der Cyber Resilience Act zu interner Software sagt

Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen. Er verpflichtet Hersteller zu Sicherheitsstandards und Meldepflichten. Ab Dezember 2027 kommt eine vollständige Dokumentationspflicht für die eigene Software dazu. Wer grundsätzlich unter den Cyber Resilience Act fällt, haben wir in einem früheren Artikel erklärt.

Für Individualsoftware gilt eine klare Grundregel. Nutzt ein Unternehmen seine selbst entwickelte Software ausschließlich für den eigenen Betrieb, gilt eine Ausnahme. Stellt es sie niemandem sonst bereit, fällt sie nach aktuellem Stand nicht unter die Meldepflichten des CRA. Der Fachbegriff dafür ist "Inverkehrbringen". Erst wenn ein Produkt den eigenen Betrieb verlässt und an Dritte geht, greift die Verordnung.

Das klingt nach einer sauberen Grenze. In der Praxis ist sie es oft nicht. Viele Unternehmen merken erst nachträglich, dass sich an ihrer Software über die Jahre etwas geändert hat. Bewusst entschieden hat das niemand.

Wann wird aus "nur intern" doch ein Produkt am Markt?

Drei Situationen sorgen immer wieder für Unsicherheit.

Die interne Software bekommt einen externen Nutzer

Ein Beispiel aus der Praxis: Ein Maschinenbauer entwickelt ein Tool zur Lagerverwaltung. Gedacht war es nur für die eigene Produktion. Später bekommt ein Zulieferer Zugriff, um Bestellungen direkt einzutragen. Sobald ein Unternehmen außerhalb der eigenen Organisation mit dem System arbeitet, ist es kein rein internes Werkzeug mehr. Es wurde faktisch bereitgestellt, auch ohne Verkauf und ohne Rechnung. Oft passiert das schrittweise. Ein Zugang hier, ein Gast-Login dort. Irgendwann kann niemand mehr sagen, seit wann die Software eigentlich extern genutzt wird.

Aus dem internen Tool wird ein Angebot für Kunden

Viele Unternehmen bauen interne Software, die sich bewährt. Später bieten sie sie anderen Firmen an, oft zunächst kostenlos für ausgewählte Kunden. In dem Moment wechselt die Software vom internen Werkzeug zum Produkt. Wie sich dieser Schritt von einer klassischen SaaS-Lösung unterscheidet, zeigt unser Vergleich SaaS vs. eigene Software im Mittelstand. Dort erklären wir auch, welche Pflichten dabei entstehen.

Eine Tochtergesellschaft nutzt dieselbe Software

Nutzt eine rechtlich eigenständige Tochtergesellschaft dieselbe Anwendung, ist die Einordnung nicht immer eindeutig. Entscheidend ist, ob die Software innerhalb eines zusammenhängenden Unternehmens bleibt. Oder ob sie einer eigenständigen juristischen Person bereitgestellt wird, die sie als Kunde nutzt. Bei einer vollständig konsolidierten Tochtergesellschaft im selben Konzern spricht vieles für eine interne Nutzung. Bei einem Joint Venture mit externen Gesellschaftern sieht das anders aus. Genauso bei einer später verkauften Tochter. Im Zweifel lohnt sich hier eine rechtliche Prüfung des konkreten Konzernverhältnisses.

Praxis-Check: betroffen oder nicht?

Als grobe Orientierung helfen diese drei Fragen.

Nutzen ausschließlich eigene Mitarbeiter die Software? Ohne dass externe Personen oder Unternehmen Zugriff erhalten? Dann bleibt sie in der Regel innerhalb der CRA-Ausnahme für rein interne Nutzung.

Erhält ein Kunde, Partner oder Lieferant eigenen Zugang zur Anwendung? Etwa über ein Portal oder eine Schnittstelle? Dann wird die Software in aller Regel Dritten bereitgestellt. Die Ausnahme entfällt.

Gibt es Pläne, die Software künftig zu verkaufen oder zu lizenzieren? Dann sollte die CRA-Konformität schon jetzt mitgedacht werden. Bevor der erste externe Nutzer dazukommt.

Schon ein einziges Ja bei den letzten beiden Fragen reicht, um die Einordnung neu zu prüfen. Halten Sie das Ergebnis schriftlich fest, auch wenn die Antwort heute klar "nein" lautet. In einem Jahr kann sich die Situation ändern. Dann ist es hilfreich, nachvollziehen zu können, worauf die ursprüngliche Einschätzung beruhte.

Was Sie trotzdem von Ihrem Entwicklungsdienstleister verlangen sollten

Selbst wenn der Cyber Resilience Act formal nicht greift, bleibt eine Frage bestehen. Wer kümmert sich um Sicherheitslücken in Ihrer internen Software?

Ein gutes Zeichen für seriöse Dienstleister: Sie nehmen Sicherheit auch ohne gesetzlichen Zwang ernst. Konkret heißt das: Abhängigkeiten und eingesetzte Bibliotheken werden dokumentiert. So sind bekannte Sicherheitslücken schnell auffindbar. Updates laufen nach einem festen Rhythmus, nicht nur wenn gerade Zeit ist. Und es gibt einen klaren Ansprechpartner, wenn ein Sicherheitsproblem auftaucht.

Genau diese Punkte gehören in einen guten Wartungsvertrag. Unabhängig davon, ob der CRA rechtlich verpflichtet oder nicht. Welche Inhalte dabei häufig fehlen, zeigt unser Artikel zum Software-Wartungsvertrag. Wer diese Punkte heute schon regelt, muss später nicht hastig nachbessern. Auch dann nicht, wenn sich die Nutzung der Software doch einmal ändert.

Was tun, wenn Sie sich nicht sicher sind?

Vier Schritte helfen bei der Einordnung.

Prüfen Sie zuerst konkret, wer tatsächlich Zugriff auf die Software hat. Nicht, wer theoretisch Zugriff haben könnte. Sondern wer heute damit arbeitet.

Schauen Sie sich bestehende Verträge mit Kunden, Partnern und Zulieferern an. Räumt einer davon externen Zugriff auf Ihre interne Anwendung ein, ändert das die Einordnung.

Dokumentieren Sie Ihre Einschätzung schriftlich, inklusive der Begründung. Das ist im Fall einer späteren Prüfung die beste Absicherung.

Planen Sie, eine Software extern anzubieten oder zu verkaufen? Dann ziehen Sie die CRA-Anforderungen frühzeitig in die Entwicklung mit ein. Nachträglich ist das deutlich aufwendiger, als Sicherheit von Anfang an einzuplanen. Wer hier abwartet, sammelt genau die technischen Schulden an, die sich später nur mit Mehraufwand abbauen lassen.

Fazit: Intern ist kein Freifahrtschein für immer

Individualsoftware, die wirklich nur im eigenen Haus läuft, bleibt vom Cyber Resilience Act meist unberührt. Das ändert sich in dem Moment, in dem ein Externer Zugriff bekommt. Oder in dem die Software den Weg zu einem Kunden findet.

Wer diese Grenze kennt und im Blick behält, vermeidet eine unangenehme Überraschung. Wer sie ignoriert, merkt es oft erst, wenn es zu spät ist. Dann hat sich der Status der Software längst verändert.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Software an und sagen Ihnen ehrlich, ob und wie der Cyber Resilience Act Sie bei Individualsoftware betrifft.