Cyber Resilience Act: Welche Pflichten gelten für Software-Hersteller?

Kategorie: IT-Sicherheit

Der Cyber Resilience Act verpflichtet Hersteller vernetzter Produkte und Software zu mehr IT-Sicherheit. Sie müssen Sicherheitsmaßnahmen bereits in der Entwicklung berücksichtigen, Schwachstellen managen und Updates bereitstellen. Entscheidend ist dabei immer: Was ist angesichts des konkreten Risikos „angemessen“?

Cyber Resilience Act und Softwaresicherheit in der EU

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (CRA) ist Teil eines größeren EU-Regulierungspakets zur Stärkung der Cybersicherheit.  Zu diesem Maßnahmenpaket gehört unter anderem auch die NIS2-Richtlinie. Während andere Regelungen vor allem Organisationen betreffen, richtet sich der CRA unmittelbar an Hersteller von Produkten mit digitalen Elementen– also Software und vernetzte Geräte.

Gemeint sind insbesondere:

  • IoT-Produkte wie Smart-Home-Geräte oder Wearables
  • Software-Anwendungen (auch ohne physisches Produkt)
  • Generell Produkte, die mit dem Internet oder anderen Geräten verbunden sind

Die Grundidee: Vernetzte Produkte bergen ein höheres Risiko. Anders als ein klassisches fehlerhaftes Produkt kann eine Sicherheitslücke auf andere Geräte oder Systeme im Netzwerk übergreifen und dort weiteren Schaden verursachen. Genau dieses erhöhte Schadenspotenzial ist der Grund für die besonderen Anforderungen des Cyber Resilience Act.

Security by Design und Security by Default

Eine der zentralen Anforderungen: Sicherheit darf kein nachträglicher Gedanke sein. Sie müssen bereits bei der Entwicklung berücksichtigt werden.

Security by Design

Schon in der Planungs- und Entwicklungsphase müssen angemessene Sicherheitsmechanismen vorgesehen werden. Dazu gehört insbesondere:

  • Identifikation möglicher Risiken
  • Definition geeigneter Schutzmaßnahmen
  • Technische Umsetzung (z. B. Verschlüsselung, Zugriffskontrollen)
  • Berücksichtigung der Sicherheitsanforderungen bereits bei der Architektur und Entwicklung des Produkts

Security by Default

Produkte müssen standardmäßig so konfiguriert sein, dass sie möglichst sicher sind. Nutzer können Einstellungen zwar ändern – aber die Ausgangseinstellung muss ein hohes Sicherheitsniveau gewährleisten. Der Gesetzgeber verlangt also, dass Geräte bereits bei der Auslieferung mit möglichst sicheren Standardeinstellungen versehen sind.

Risikobasierter Ansatz: Was ist „angemessen“?

Ein Schlüsselbegriff im Cyber Resilience Act ist die „Angemessenheit“. Welche Sicherheitsmaßnahmen erforderlich sind, hängt stark vom jeweiligen Produkt ab.

Ein Beispiel:

  • Eine Fitnessuhr hat ein vergleichsweise geringes Risikoprofil
  • Vernetzte Medizintechnik im Krankenhaus unterliegt deutlich strengeren Anforderungen

Für Sie bedeutet das: Ohne fundierte Risikoanalyse kommen Sie nicht weit. Sie müssen nachvollziehbar darlegen können, warum bestimmte Maßnahmen gewählt wurden – und warum diese zum Risikoprofil passen.

Die Risikoanalyse bildet dabei die Grundlage für sämtliche Sicherheitsmaßnahmen. Erst aus ihr lässt sich ableiten, welche Schutzmechanismen für das jeweilige Produkt angemessen sind. Genau diese Herleitung muss später auch nachvollziehbar dokumentiert werden.

Pflichten im Umgang mit Sicherheitslücken

Der CRA verpflichtet Hersteller dazu, aktiv mit Schwachstellen umzugehen.

Konkret heißt das:

  • Sie müssen erreichbar sein für Meldungen zu Sicherheitslücken
  • Meldungen müssen geprüft und bewertet werden
  • Gemeldete Schwachstellen müssen zunächst verifiziert werden. Nicht jede Meldung stellt tatsächlich eine Sicherheitslücke dar
  • Sicherheitslücken müssen behoben werden
  • Updates müssen bereitgestellt werden

Wichtig ist: Es geht nicht um neue Features, sondern ausschließlich um Sicherheitsupdates. Hersteller müssen ihre Software über den vorgesehenen Produktlebenszyklus hinweg pflegen und neu entdeckte Sicherheitslücken schließen. Diese Pflicht besteht unabhängig von etwaigen Abo-Modellen.

IT-Recht für Ihr Unternehmen

Erhalten Sie fundierte Unterstützung im IT-Recht – abgestimmt auf Ihr Unternehmen und Ihre konkreten digitalen Herausforderungen.

Verbindliche Prozesse und Dokumentation

Ein häufiger Knackpunkt in der Praxis: Sie müssen all das nicht nur tun – sondern auch nachweisen können.

Das betrifft insbesondere:

  • Dokumentierte Risikoanalysen
  • Definierte Prozesse zur Schwachstellenbearbeitung
  • Dokumentierte Abläufe für die Annahme, Prüfung, Verifizierung und Behebung gemeldeter Sicherheitslücken
  • Klare interne Zuständigkeiten und Verantwortlichkeiten
  • Festgelegte Bearbeitungsabläufe und interne Fristen
  • Nachweise über umgesetzte Sicherheitsmaßnahmen

Ein bloßes „Wir kümmern uns darum“ reicht nicht. Ohne dokumentierte Prozesse wird es schwierig, die Anforderungen zu erfüllen.

Gerade diese Dokumentation gehört in der Praxis zu den größten Herausforderungen des Cyber Resilience Act. Entscheidend ist, dass Dritte nachvollziehen können, wie Sicherheitsentscheidungen getroffen wurden und warum sie angesichts des jeweiligen Risikos angemessen sind.

Transparenzpflichten bei Software-Komponenten

Ein weiterer relevanter Punkt: Sie müssen offenlegen, welche Drittkomponenten in Ihrer Software enthalten sind.

Dazu zählen:

  • Open-Source-Komponenten
  • Proprietäre Drittsoftware

Diese Informationen müssen für Nutzer zugänglich sein – etwa über:

  • Produktseiten (z. B. App Stores)
  • Online-Dokumentation
  • Begleitende Softwareunterlagen

Entscheidend ist nicht der konkrete Veröffentlichungsort, sondern dass die Informationen für den Nutzer leicht zugänglich sind und nachvollziehbar dokumentieren, welche Fremdkomponenten eingesetzt werden.

Praxisproblem: Umsetzung erst nach Markteinführung?

Viele Unternehmen unterschätzen den Aufwand. Die größte Herausforderung liegt oft nicht in einzelnen Maßnahmen, sondern in der Struktur dahinter.

Wenn Sie erst nachträglich versuchen, Prozesse, Komponentenlisten und Risikobewertungen zusammenzustellen, wird es schnell unübersichtlich – und teuer.

Gerade bei größeren Softwareprojekten kommen häufig Hunderte oder sogar Tausende Drittkomponenten zum Einsatz. Werden diese nicht bereits während der Entwicklung sauber dokumentiert, wird die nachträgliche Aufarbeitung schnell zur Mammutaufgabe.

Sinnvoll ist daher:

  • frühe Integration der Anforderungen in Entwicklungsprozesse
  • Schulung von Entwicklerteams
  • frühzeitige Sensibilisierung der Entwickler für die Dokumentation eingesetzter Komponenten
  • laufende Dokumentation der eingesetzten Komponenten

Fazit: Cyber Resilience Act als Daueraufgabe

Der Cyber Resilience Act ist kein einmaliges Compliance-Projekt, sondern betrifft den gesamten Lebenszyklus eines Produkts – von der Entwicklung bis zur Wartung.

Hersteller müssen:

  • Sicherheitsmaßnahmen systematisch integrieren
  • Schwachstellen aktiv managen
  • Transparenz schaffen
  • alles nachvollziehbar dokumentieren

Gerade für Unternehmen mit komplexer Softwarearchitektur lohnt sich eine frühzeitige rechtliche und technische Begleitung. Wenn Sie unsicher sind, wie die Anforderungen konkret umzusetzen sind, kann eine erste Einschätzung helfen – etwa über den Datenschutz Check für Unternehmen oder die Beratung durch einen Fachanwalt für IT-Recht. Auch ein Blick auf die grundlegenden Zusammenhänge im IT-Recht kann helfen, die Regulierung besser einzuordnen.

Individuelle Fragen zum Thema oder sonstige Anliegen?