Cyber Resilience Act (CRA): Anforderungen, Produkte mit digitalen Elementen und Risikoanalyse

Warum der Cyber Resilience Act eingeführt wurde

Digitale Funktionen sind heute kein Zusatz mehr, sondern Kernbestandteil vieler Produkte. Maschinen, Fahrzeuge, Geräte in der Medizintechnik oder industrielle Anlagen enthalten Software, kommunizieren über Netzwerke, werden remote gewartet oder sind an Cloud-Dienste angebunden. Damit wächst die Angriffsfläche – nicht nur in klassischen IT-Umgebungen, sondern in der gesamten Produktwelt.

Sicherheitsvorfälle der vergangenen Jahre zeigen ein wiederkehrendes Muster: Schwachstellen entstehen häufig an Schnittstellen, in Abhängigkeiten zu Drittkomponenten oder in Update-Mechanismen, die nicht konsequent abgesichert sind. Viele Produkte bleiben über Jahre oder Jahrzehnte im Feld. Genau dort verschärft sich das Problem, weil neue Schwachstellen und neue Angriffsmethoden oft erst lange nach der Markteinführung sichtbar werden. Wenn dann keine klaren Prozesse für Risikoanalyse, Updates und Schwachstellenbehandlung existieren, wird aus einer technischen Lücke schnell ein regulatorisches und wirtschaftliches Risiko.

Die Europäische Union hat den Cyber Resilience Act, kurz CRA, eingeführt, um dieses strukturelle Problem anzugehen. Ziel ist ein einheitlicher Rechtsrahmen, der Hersteller verpflichtet, Cybersicherheit als Produkteigenschaft nachweisbar umzusetzen. Die Verordnung ist Teil eines umfassenderen Ansatzes, der Produktsicherheit im digitalen Zeitalter verbindlich macht und gleichzeitig Markttransparenz schafft. Produkte sollen künftig nur dann in der EU bereitgestellt werden, wenn sie definierte Cybersecurity-Anforderungen erfüllen und über ihren Lebenszyklus hinweg sicher betrieben werden können.

Wichtig sind dabei drei Ebenen:

1. Produktanforderungen: Das Produkt selbst muss bestimmte Sicherheitsanforderungen erfüllen.
2. Prozessanforderungen: Der Hersteller muss Prozesse für Entwicklung und Schwachstellenbehandlung etablieren.
3. Lebenszyklusverantwortung: Nach der Bereitstellung auf dem Markt endet die Verantwortung nicht, sondern setzt sich fort, insbesondere bei Schwachstellen und Updates.

Damit wird Cybersicherheit zu einer regulatorisch verankerten Pflicht, vergleichbar mit anderen Produktvorschriften – nur eben mit Fokus auf digitale Risiken.

Was der Cyber Resilience Act regelt

Der CRA ist eine EU-Verordnung zur Verbesserung der Cybersicherheit von Produkten mit digitalen Elementen. Er harmonisiert Anforderungen innerhalb der EU und legt fest, welche Pflichten Hersteller erfüllen müssen. Der Fokus liegt nicht auf dem Betrieb von IT-Systemen, sondern auf dem Produkt und der Verantwortung des Herstellers.

Für das Verständnis des CRA sind vier Bausteine besonders zentral:

• Artikel 10 beschreibt Pflichten von Herstellern.
• Artikel 13 regelt die Behandlung von Schwachstellen.
• Anhang I enthält die wesentlichen Cybersecurity-Anforderungen, gegliedert in Anforderungen an Produkteigenschaften und Anforderungen an die Schwachstellenbehandlung.
• Anhang II konkretisiert Anforderungen an das Schwachstellenmanagement.

Der CRA ist zudem eng mit dem europäischen System der Konformitätsbewertung verknüpft. Produkte sollen eine CE-Kennzeichnung tragen, um die Konformität mit den CRA-Anforderungen zu signalisieren. Nationale Marktüberwachungsbehörden setzen die Regeln durch.

Zeitplan und Stichtage

Für die Umsetzung ist entscheidend, dass der CRA stufenweise wirksam wird. Nach Angaben der Europäischen Kommission ist die Verordnung am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab 11. September 2026. Die wesentlichen Pflichten gelten dann ab 11. Dezember 2027.

Für Hersteller bedeutet das: Die operative Vorbereitung muss deutlich vor 2027 beginnen, weil Risikoanalyse, Secure-Development-Prozesse, Dokumentation und Schwachstellenmanagement nicht kurzfristig eingeführt werden können – insbesondere nicht bei komplexen Produkten oder langen Lieferketten.

Produkte mit digitalen Elementen: Wer und was ist betroffen

Der CRA gilt für sogenannte Produkte mit digitalen Elementen. Die Definition steht in Artikel 3. Im Kern geht es um Produkte, die Software enthalten oder deren Funktion wesentlich von Software abhängt. Das umfasst physische Produkte mit integrierter Software ebenso wie reine Softwareprodukte.

Wichtig ist: Die Verordnung ist bewusst weit formuliert. Sie will nicht nur klassische IT-Produkte abdecken, sondern auch vernetzte Produktwelten in Industrie und Konsum. Maßgeblich ist nicht, ob ein Produkt als Hardware oder Software wahrgenommen wird, sondern ob digitale Komponenten Teil der Funktion sind und ob daraus Cyberrisiken entstehen können.

Typische Beispiele sind Softwareanwendungen, Betriebssysteme, Middleware, IoT-Geräte, Maschinen mit Embedded Software, industrielle Steuerungssysteme oder Produkte mit Fernwartungsfunktionen.

Zudem unterscheidet der CRA Produktkategorien, insbesondere mit Blick auf Produkte, bei denen ein erhöhtes Sicherheitsrisiko anzunehmen ist. Das wirkt sich in der Praxis auf die Pfade der Konformitätsbewertung und die Tiefe der Nachweise aus, ohne dass ein Unternehmen allein anhand eines Schlagworts entscheiden kann. Häufig ist eine strukturierte Einordnung notwendig.

Typische Produktkategorien, die unter den CRA fallen können

Damit die Einordnung greifbar wird, hilft ein Blick auf typische Kategorien. Entscheidend ist nicht die Branche, sondern die digitale Funktion und der Grad der Vernetzung.

Softwareprodukte

Softwareprodukte gehören zu den offensichtlichsten Fällen. Betroffen sein können zum Beispiel Business-Software, technische Softwaretools, Plattformsoftware, Konfigurationssoftware oder Wartungssoftware. Relevant sind auch Softwarekomponenten, wenn sie als eigenständige Produkte bereitgestellt werden, etwa bestimmte Plattformmodule oder sicherheitsrelevante Komponenten.

Software ist nicht nur wegen ihres Funktionsumfangs relevant, sondern weil sie in der Praxis stark von Abhängigkeiten geprägt ist. Bibliotheken, Frameworks und Drittkomponenten beeinflussen die Angriffsfläche. Damit rückt die Fähigkeit des Herstellers in den Vordergrund, Abhängigkeiten zu kennen, Risiken zu bewerten und Schwachstellen zu behandeln. Genau hier setzt der CRA mit seinen Anforderungen an Risikoanalyse und Schwachstellenhandling an.

Vernetzte Geräte und IoT-Systeme

Bei IoT-Systemen entstehen Risiken häufig durch Netzwerkkommunikation, Identitäten, Update-Mechanismen und Cloud-Anbindungen. Typische Beispiele sind Sensoren, Smart-Home-Komponenten, vernetzte Geräte in Industrieanlagen oder Geräte mit Cloud-Anbindung. Sobald Daten übertragen werden oder Fernzugriffe möglich sind, entstehen Angriffsflächen, die produktseitig beherrscht werden müssen.

Der CRA zielt gerade auf solche Szenarien, weil Produkte häufig in fremden Netzwerken betrieben werden. Hersteller müssen deshalb nicht nur das Gerät isoliert betrachten, sondern auch typische Einsatzumgebungen berücksichtigen, soweit sie vernünftigerweise vorhersehbar sind.

Maschinen und industrielle Systeme

Auch Maschinen und industrielle Anlagen sind betroffen, wenn Software zentral für Funktion, Steuerung oder Wartung ist. Viele Produkte enthalten Embedded Software, Diagnosefunktionen, Fernwartungszugänge und Netzwerkverbindungen. Gerade Fernwartung ist ein Klassiker: Sie bringt enorme Vorteile, aber auch reale Angriffsflächen, die im Design adressiert werden müssen.

In Industrieumgebungen ist zudem häufig die Integration in größere Systeme entscheidend. Eine Maschine ist selten allein. Sie hängt an Produktionsnetzen, an Leitständen, an Remote-Service-Plattformen und an Datenpipelines. Damit wird das Produkt Teil eines Systems, dessen Cyberrisiken sich nicht auf ein einzelnes Gerät reduzieren lassen. Das ist einer der Gründe, warum der CRA so stark auf Risikoanalyse und Lebenszyklusprozesse fokussiert.

Trifft der CRA auf mein Produkt zu: Ein pragmatischer Entscheidungsrahmen

Viele Unternehmen wollen keine juristische Abhandlung, sondern eine belastbare erste Entscheidung: Ja oder nein – und warum. Dafür hilft ein Entscheidungsrahmen, der direkt an die CRA-Logik anschließt.

Schritt 1: Enthält Ihr Produkt Software oder hängt die Funktion wesentlich von Software ab?

Wenn Ihr Produkt ohne Software nicht oder nicht wie vorgesehen funktioniert, ist das ein starkes Indiz, dass es unter den CRA fällt. Das gilt für Embedded Software ebenso wie für Software, die auf einem separaten Rechner läuft, aber für den Betrieb des Produkts erforderlich ist.

Schritt 2: Kommuniziert Ihr Produkt über Netzwerke oder bietet es Schnittstellen zu anderen Systemen?

Netzwerkfähigkeit ist kein Muss, aber in der Praxis ein häufiger Treiber für CRA-Relevanz. Sobald Ihr Produkt Daten sendet oder empfängt, sich remote konfigurieren lässt oder in Cloud-Dienste integriert ist, entstehen Cyberrisiken, die produktseitig adressiert werden müssen.

Schritt 3: Wird Ihr Produkt als eigenständige Software bereitgestellt?

Reine Softwareprodukte können direkt unter den CRA fallen. Wenn Sie Software als Produkt anbieten – unabhängig davon, ob sie als App, Desktop-Software, Embedded-Komponente oder cloudgesteuerter Client bereitgestellt wird –, ist CRA-Relevanz wahrscheinlich. Wichtig ist dabei, dass es um ein Produkt geht, das auf dem EU-Markt bereitgestellt wird.

Schritt 4: Ist Ihr Produkt Teil eines Produktsystems mit mehreren digitalen Komponenten?

Viele Produkte sind Systeme, nicht Einzelteile. Häufig gehören Hardware, Firmware, Cloud-Plattform und mobile Anwendung zusammen. Der CRA betrachtet in solchen Fällen nicht nur einen Baustein, sondern das Produkt mit seinen digitalen Elementen im Zusammenhang. Das ist besonders relevant, wenn eine Komponente Zugriff auf sicherheitsrelevante Funktionen hat, etwa Steuerung, Authentifizierung oder Update.

Wenn mehrere dieser Punkte zutreffen, ist es in der Regel sinnvoll, von CRA-Relevanz auszugehen und die Einordnung strukturiert zu dokumentieren.

Wann der CRA in der Regel nicht greift

Die häufigsten Fälle, in denen Unternehmen fälschlich CRA-Relevanz annehmen oder ablehnen, lassen sich klarer formulieren:

• Reine interne Software, die nicht als Produkt auf dem EU-Markt bereitgestellt wird, fällt typischerweise nicht unter den CRA.
• Nicht kommerzielle Open-Source-Software, die außerhalb wirtschaftlicher Tätigkeiten entwickelt wird, ist in der Regel ausgenommen.
• Reine Dienstleistungen ohne eigenständiges Produkt sind nicht der Kernadressat des CRA.

Entscheidend ist der Produktcharakter und die Bereitstellung im europäischen Markt. Sobald Software oder ein Produkt mit digitalen Elementen unter eigenem Namen bereitgestellt wird, verschiebt sich die Bewertung schnell.

Fallen Apps unter den Cyber Resilience Act?

Ja, Apps können unter den CRA fallen, aber nicht jede App automatisch. Entscheidend ist, ob die App ein eigenständiges Softwareprodukt ist oder Teil eines Produktsystems mit digitalen Elementen.

Eine App ist typischerweise relevant, wenn sie:

• Geräte konfiguriert oder steuert
• Betriebsdaten aus einem Produkt ausliest oder verändert
• sicherheitsrelevante Funktionen anbietet, etwa Benutzerverwaltung
• als Remote-Bedienoberfläche dient
• Updates oder Konfigurationen anstößt

In solchen Fällen ist die App kein beliebiges Frontend, sondern Teil der sicherheitsrelevanten Architektur. Wenn eine App beispielsweise ein IoT-Gerät steuert, ist sie Teil der Angriffsfläche des Gesamtsystems. Dann muss sie in der Risikoanalyse berücksichtigt werden.

Weniger relevant ist eine App, die ausschließlich als nicht sicherheitskritische Zusatzfunktion dient und keine produktkritischen Schnittstellen anspricht. Dennoch kann auch hier der Kontext entscheidend sein, etwa wenn Authentifizierung oder Datenintegrität betroffen sind.

Risikoanalyse als Kernpflicht im CRA

Jetzt zum Kern Ihrer Vorgabe: Risikoanalyse ist nicht ein Teilaspekt, sondern das Fundament, auf dem viele CRA-Pflichten aufbauen.

Warum die Risikoanalyse zentral ist

Der CRA verlangt von Herstellern, Cyberrisiken zu bewerten und Maßnahmen abzuleiten. Artikel 10 fordert, dass Hersteller die Konformität sicherstellen und entsprechende Nachweise erbringen. In diesem Kontext spielt die Cybersecurity-Risikobewertung eine zentrale Rolle. Sie ist auch Teil der technischen Dokumentation und muss nachvollziehbar begründen, wie Anforderungen aus Anhang I umgesetzt werden.

Anders gesagt: Ohne Risikoanalyse bleibt unklar, ob ein Produkt angemessene Schutzmaßnahmen enthält und ob diese Schutzmaßnahmen zu den tatsächlichen Risiken passen. Genau diese Passung fordert der CRA.

Was eine CRA-taugliche Risikoanalyse abdecken muss

Eine CRA-taugliche Risikoanalyse muss mehr leisten als eine generische Checkliste. Sie sollte mindestens folgende Fragen beantworten, bezogen auf das konkrete Produkt:

1. Was ist der Gegenstand der Betrachtung? Welche Komponenten gehören zum Produkt und welche digitalen Elemente sind relevant?
2. Welche Angriffsflächen existieren? Schnittstellen, Netzwerke, Update-Kanäle, Fernzugänge, Cloud-Anbindungen
3. Welche Bedrohungen sind plausibel? Angriffe auf Verfügbarkeit, Integrität, Vertraulichkeit, Missbrauch von Funktionen
4. Welche Auswirkungen wären zu erwarten? technisch, betrieblich, sicherheitsrelevant
5. Welche Schutzmaßnahmen sind implementiert? Und warum sind sie angemessen?
6. Wie wird die Risikoanalyse aktuell gehalten? Weil Bedrohungen sich ändern und Schwachstellen neu entstehen

Der CRA macht keine Vorgabe, dass eine bestimmte Methodik genutzt werden muss. In der Praxis ist aber entscheidend, dass die Analyse nachvollziehbar, reproduzierbar und an das Produkt angepasst ist.

Produktkontext und Betriebsumgebung

Ein häufiger Fehler ist, das Produkt isoliert zu betrachten. Bei vernetzten Produkten ist der Kontext entscheidend: typische Netzwerke, typische Nutzerrollen, typische Integrationen. Ein Gerät, das in einem abgeschotteten Netz betrieben wird, hat andere Risiken als ein Gerät, das über öffentliche Netze erreichbar ist oder remote gewartet wird.

Der CRA zielt auf realistische Cyberrisiken, nicht auf theoretische. Das bedeutet: Die Risikoanalyse muss die vernünftigerweise erwartbare Umgebung berücksichtigen, soweit sie für die Produktfunktion relevant ist.

Risikoanalyse als Grundlage für Security by Design und Security by Default

Security by Design bedeutet, Risiken frühzeitig zu berücksichtigen, bevor Architekturentscheidungen feststehen. Ohne Risikoanalyse bleibt Security by Design häufig ein allgemeines Prinzip ohne konkrete Konsequenzen.

Security by Default bedeutet, dass Standardkonfigurationen sicher sein müssen. Auch hier ist die Risikoanalyse der Maßstab: Welche Default-Einstellungen reduzieren reale Risiken, ohne den Betrieb unzumutbar zu erschweren?

Risikoanalyse als Teil der Konformitätsbewertung und CE-Konformität

Der CRA ist in den europäischen Rahmen der Konformitätsbewertung eingebettet. Produkte sollen CE-gekennzeichnet werden, um die Einhaltung der CRA-Anforderungen zu signalisieren. Damit wird die Risikoanalyse indirekt zu einem Nachweisbaustein, weil sie die Umsetzung der wesentlichen Anforderungen begründet und in der technischen Dokumentation verankert wird.

Schwachstellenmanagement und Meldepflichten als Fortsetzung der Risikoanalyse

Risikoanalyse endet nicht mit der Markteinführung. Der CRA legt besonderen Wert auf die Behandlung von Schwachstellen. Artikel 13 beschreibt Anforderungen an den Umgang mit Schwachstellen. Die Europäische Kommission nennt ab 11. September 2026 den Start der Meldepflichten.

Praktisch bedeutet das: Hersteller müssen Prozesse etablieren, um Schwachstellen zu erkennen, zu bewerten, zu beheben und Informationen zu kommunizieren. Dazu gehört auch die Nutzung der vorgesehenen Meldestrukturen.

Für den Artikel ist hier vor allem wichtig: Schwachstellenmanagement ist die operative Fortsetzung der Risikoanalyse. Neue Schwachstellen können Risiken verändern. Damit muss die Risikoanalyse regelmäßig überprüft und aktualisiert werden – zumindest dann, wenn sich die Bedrohungslage oder das Produkt verändert.

Häufige Fragen zum CRA

Was ist der Cyber Resilience Act in einem Satz?

Der Cyber Resilience Act ist eine EU-Verordnung, die Hersteller verpflichtet, Produkte mit digitalen Elementen mit grundlegenden Cybersecurity-Anforderungen zu entwickeln und Schwachstellen über den Produktlebenszyklus systematisch zu behandeln.

Gilt der CRA auch für Software und Apps?

Ja, der CRA kann für reine Softwareprodukte und auch für Apps gelten, wenn sie als Produkt bereitgestellt werden oder Teil eines Produktsystems mit digitalen Elementen sind. Maßgeblich ist die Definition in Artikel 3.

Ab wann gelten die Pflichten?

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Meldepflichten gelten ab 11. September 2026. Die wesentlichen Pflichten gelten ab 11. Dezember 2027.

Fazit: Was Sie aus CRA-Sicht jetzt klar haben sollten

Der CRA verankert Cybersicherheit als Produkteigenschaft. Er richtet sich an Hersteller von Produkten mit digitalen Elementen und verlangt, dass wesentliche Cybersecurity-Anforderungen erfüllt und über den Lebenszyklus hinweg aufrechterhalten werden. Dazu gehören Security by Design, Security by Default, Risikoanalyse und ein belastbares Schwachstellenmanagement.

Für Unternehmen sind drei Punkte entscheidend:

1. Betroffenheit klären: Ist Ihr Produkt ein Produkt mit digitalen Elementen, wird es im EU-Markt bereitgestellt, und welche digitalen Komponenten sind relevant?
2. Risikoanalyse aufsetzen: Produktkontext, Angriffsflächen, Bedrohungen, Auswirkungen, Maßnahmen, Aktualisierung
3. Lebenszyklusprozesse etablieren: Schwachstellenbehandlung, Updates, Meldepflichten und Nachweise im Rahmen der Konformitätsbewertung

Wenn Sie diese drei Punkte strukturiert angehen, vermeiden Sie Blindflug. Sie reduzieren regulatorische Risiken und schaffen gleichzeitig eine Grundlage für robustere Produkte.