CRA-Anwendungsbereich: Welche Produkte und Unternehmen sind betroffen?

Der Cyber Resilience Act erfasst grundsätzlich Hardware- und Softwareprodukte mit digitalen Elementen, die im EU-Markt bereitgestellt werden. Ob ein Unternehmen Pflichten hat, entscheidet sich aber nicht allein an der Frage „Software oder Hardware?“. Entscheidend sind Produktfunktion, Marktbereitstellung, wirtschaftliche Tätigkeit, Remote-Komponenten und die eigene Rolle als Hersteller, Importeur, Händler oder anderer Wirtschaftsakteur.

Den übergeordneten Einstieg mit Pflichten, Fristen und Umsetzung finden Sie im großen Überblick zum Cyber Resilience Act. Diese Seite vertieft gezielt die Frage, welche Produkte, Geschäftsmodelle und Unternehmen tatsächlich in den CRA-Anwendungsbereich fallen.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Grundlagen & Anwendungsbereich. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Welche Produkte fallen grundsätzlich unter den CRA?

Der CRA gilt für „Produkte mit digitalen Elementen“. Artikel 3 definiert diesen Begriff als Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in Verkehr gebracht werden. Diese Formulierung ist bewusst breit.

Typische Beispiele sind vernetzte Geräte, Router, Smart-Home-Produkte, Softwareanwendungen, Betriebssysteme, mobile Apps, Sicherheitssoftware, industrielle Steuerungskomponenten, Firmware, Mikrocontroller mit bestimmten Funktionen und Softwarebibliotheken, wenn sie als Produkt im Sinne der Verordnung auf dem Markt bereitgestellt werden. Ob ein konkretes Produkt erfasst wird, muss anhand der tatsächlichen Funktion und des Vertriebsmodells geprüft werden.

Ist jede Software vom CRA betroffen?

Nein. Software kann ein Produkt mit digitalen Elementen sein, aber nicht jede Softwarebereitstellung fällt automatisch in den Anwendungsbereich. Eine wichtige Frage ist, ob die Software auf dem EU-Markt im Rahmen einer wirtschaftlichen Tätigkeit bereitgestellt wird. Zusätzlich bestehen Sonderregeln für freie und quelloffene Software. Reine interne Software, die nicht auf dem Markt bereitgestellt wird, ist anders zu beurteilen als eine App, Desktopsoftware oder Bibliothek, die an Kunden geliefert wird.

Ist jede Hardware vom CRA betroffen?

Nein. Der CRA zielt auf Hardwareprodukte mit digitalen Elementen. Ein rein mechanisches Produkt ohne digitale Komponente fällt nicht allein deshalb unter den CRA, weil es in einem digital organisierten Unternehmen hergestellt wird. Sobald ein Produkt jedoch elektronische Informationsverarbeitung, Speicherung oder Übertragung digitaler Daten enthält, kann der Anwendungsbereich eröffnet sein.

Was bedeutet „auf dem Markt bereitstellen“?

Die Marktbereitstellung ist ein zentraler Filter. Vereinfacht geht es darum, ob ein Produkt im Rahmen einer Geschäftstätigkeit für Vertrieb oder Nutzung auf dem Unionsmarkt geliefert wird. Das kann gegen Bezahlung geschehen, aber der Herstellerbegriff des CRA erfasst auch bestimmte Formen der Monetarisierung und kann nicht allein dadurch umgangen werden, dass Software nominell kostenlos angeboten wird.

Für die Praxis sollte ein Unternehmen sein Geschäftsmodell dokumentieren: Wer erhält das Produkt? Unter welchem Namen? Gibt es Lizenzgebühren, Abonnements, Werbung, Supportverträge, Hardwareverkauf oder andere Monetarisierung? Wird das Produkt als Bestandteil eines größeren Angebots geliefert? Diese Fragen helfen bei der rechtlichen Einordnung.

Was sind Datenfernverarbeitungslösungen?

Datenfernverarbeitung ist Remote-Verarbeitung, für die eine Software vom Hersteller selbst oder unter seiner Verantwortung entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Der CRA betrachtet ein Produkt damit nicht nur als lokale Hardware oder lokal installierte Software.

Ein anschauliches Beispiel ist ein smartes Gerät, dessen mobile App zwingend auf eine vom Hersteller bereitgestellte API oder Datenbank zugreifen muss. Wenn diese Remote-Funktion für eine Produktfunktion notwendig ist, kann sie Teil des Produkts mit digitalen Elementen sein. Die Verantwortung endet dann nicht automatisch an der Gehäusekante des Geräts.

Fällt SaaS unter den CRA?

Ein allgemeiner SaaS-Dienst fällt nicht schon deshalb unter den CRA, weil er Software ist. Die Erwägungsgründe unterscheiden eigenständige Cloud- und SaaS-Dienste von Datenfernverarbeitungslösungen, die funktional zu einem Produkt mit digitalen Elementen gehören. Für Cloud-Dienste können außerdem andere EU-Regelwerke wie NIS2 relevant sein. Unternehmen müssen deshalb die konkrete Architektur statt nur die Marketingbezeichnung „SaaS“ betrachten.

Praktisch sollte die Frage lauten: Ist der Remote-Dienst ein eigenständiger Dienst oder ist er technisch und funktional so mit dem Produkt verbunden, dass das Produkt ohne ihn eine vorgesehene Funktion nicht erbringen kann?

Wer gilt als Hersteller?

Hersteller ist nach dem CRA eine natürliche oder juristische Person, die Produkte mit digitalen Elementen entwickelt oder herstellt oder sie entwickeln beziehungsweise herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet. Das gilt unabhängig davon, ob die Bereitstellung gegen Bezahlung, zur Monetarisierung oder unentgeltlich erfolgt, soweit die weiteren Voraussetzungen erfüllt sind.

Damit ist der Herstellerbegriff für digitale Geschäftsmodelle besonders wichtig. Ein Unternehmen muss keine eigene Fabrik besitzen und keinen Quellcode vollständig selbst geschrieben haben. Wer eine White-Label-Lösung unter eigener Marke verkauft oder Software durch Dienstleister entwickeln lässt und selbst vermarktet, kann Herstellerpflichten übernehmen.

Was gilt bei White Label?

Bei White-Label-Produkten sollte die Rollenverteilung sehr früh geprüft werden. Wenn ein Unternehmen ein fremdentwickeltes Produkt unter eigener Marke in Verkehr bringt, kann es im CRA-Sinn als Hersteller behandelt werden. Verträge mit dem technischen Zulieferer können Aufgaben und Nachweise organisieren, ersetzen aber nicht automatisch die regulatorische Rolle gegenüber dem Markt.

Was gilt bei kundenspezifischer Software?

Individuell entwickelte Software ist nicht automatisch außerhalb des CRA. Entscheidend sind unter anderem Marktbereitstellung, Verantwortlichkeit und die konkrete Vertrags- und Produktstruktur. Ein einmaliges Entwicklungsprojekt kann anders zu beurteilen sein als ein standardisiertes Produkt, das nur für einzelne Kunden konfiguriert wird. Unternehmen sollten nicht allein den Begriff „Individualsoftware“ als Ausschlusskriterium verwenden.

Welche Pflichten haben Importeure?

Importeure bringen Produkte aus Drittstaaten in den EU-Markt und haben eigene Prüf- und Reaktionspflichten. Vor dem Inverkehrbringen müssen sie unter anderem sicherstellen, dass der Hersteller das geeignete Konformitätsbewertungsverfahren durchgeführt hat, technische Dokumentation vorliegt, die CE-Kennzeichnung angebracht ist und die erforderlichen Nutzerinformationen und Herstellerangaben vorhanden sind.

Wenn ein Importeur Grund zur Annahme hat, dass ein Produkt oder die Herstellerprozesse nicht den Anforderungen entsprechen, darf er das Produkt nicht einfach in Verkehr bringen, bis die Konformität hergestellt ist. Für Einkaufs- und Importprozesse bedeutet das: CRA-Nachweise müssen künftig in Lieferantenfreigaben und Wareneingangsprozesse integriert werden.

Welche Pflichten haben Händler?

Händler müssen vor der Bereitstellung mit der gebotenen Sorgfalt prüfen, ob unter anderem CE-Kennzeichnung sowie bestimmte Hersteller- und Importeurpflichten erfüllt sind. Sie müssen reagieren, wenn sie von Nichtkonformität oder relevanten Schwachstellen erfahren.

Ein Händler ist also nicht für die gesamte technische Entwicklung verantwortlich, braucht aber ausreichende Informationen, um offensichtliche regulatorische Mängel zu erkennen und Produkte bei Bedarf aus dem Vertrieb zu nehmen oder Korrekturmaßnahmen zu unterstützen.

Wann wird ein Händler oder Importeur selbst zum Hersteller?

Die Rolle kann sich verändern, wenn ein Wirtschaftsakteur ein Produkt unter eigenem Namen oder eigener Marke vertreibt oder ein bereits in Verkehr gebrachtes Produkt wesentlich verändert. Deshalb sollten Unternehmen Änderungen an Firmware, Funktionen, Sicherheitsarchitektur und Branding nicht nur als technische oder marketingbezogene Entscheidungen behandeln.

Eine interne Freigaberegel sollte festlegen, wann Compliance oder Produktrecht eingebunden wird. Besonders kritisch sind Rebranding, umfangreiche Firmwareanpassungen, neue Remote-Funktionen und Änderungen, die das Cybersicherheitsrisiko beeinflussen.

Welche Produkte sind ausdrücklich ausgenommen?

Der CRA enthält mehrere Ausnahmen und Abgrenzungen zu spezialgesetzlich geregelten Produktbereichen. Dazu gehören insbesondere bestimmte Produkte, die bereits unter spezifische EU-Regeln mit Cybersicherheitsanforderungen fallen, sowie Produkte, die ausschließlich für nationale Sicherheit oder Verteidigung entwickelt oder geändert wurden, und Produkte zur Verarbeitung von Verschlusssachen.

Zu den Produktbereichen mit besonderer Abgrenzung gehören unter anderem bestimmte Medizinprodukte, In-vitro-Diagnostika, Kraftfahrzeuge sowie Produkte mit speziellen luftfahrt- oder maritimen Rechtsrahmen. Die genaue Ausnahme hängt von den einschlägigen Rechtsakten und dem konkreten Produkt ab. Ein Unternehmen sollte deshalb nicht aus einer Branchenzugehörigkeit pauschal schließen, dass der CRA nie gilt.

Wie behandelt der CRA freie und quelloffene Software?

Open Source ist nicht generell vom CRA ausgenommen. Die Europäische Kommission stellt klar, dass freie und quelloffene Software insbesondere dann in den Anwendungsbereich fällt, wenn sie auf dem Markt und damit im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Software, die nicht vom Hersteller monetarisiert wird, wird unter bestimmten Voraussetzungen anders behandelt.

Zusätzlich gibt es die Rolle des Open-Source-Software-Stewards. Gemeint sind juristische Personen, die die Entwicklung bestimmter Open-Source-Produkte systematisch und nachhaltig unterstützen und deren Lebensfähigkeit sicherstellen, ohne selbst Hersteller im klassischen Sinn zu sein. Für sie gelten besondere, leichtere Pflichten. Mehr Details stehen unter CRA und Open Source.

Wie werden Standardprodukte, wichtige und kritische Produkte unterschieden?

Wenn ein Produkt in den Anwendungsbereich fällt, folgt die nächste Frage: Welche Produktkategorie liegt vor? Der CRA unterscheidet eine große Standardkategorie sowie „wichtige“ und „kritische“ Produkte. Diese Einordnung ist vor allem für das Konformitätsbewertungsverfahren relevant.

Viele gewöhnliche digitale Produkte können grundsätzlich per Selbstbewertung bewertet werden. Bei wichtigen Produkten der in Anhang III genannten Kategorien gelten strengere Anforderungen; bei kritischen Produkten nach Anhang IV ist eine Drittbewertung vorgesehen. Die Europäische Kommission hat die technischen Beschreibungen mit der Durchführungsverordnung (EU) 2025/2392 weiter konkretisiert.

Details und Beispiele finden Sie unter CRA-Konformitätsbewertung und CE-Kennzeichnung.

Wie prüft ein Unternehmen die eigene Betroffenheit?

Ein belastbarer Betroffenheitscheck sollte nicht nur aus einer Ja/Nein-Frage bestehen. Sinnvoll ist eine Produktmatrix, die für jedes Produkt dieselben Punkte dokumentiert.

Welche typischen Praxisfälle führen zu Fehlbewertungen?

„Wir sind nur ein Softwareunternehmen“

Gerade Softwareunternehmen können Hersteller von Produkten mit digitalen Elementen sein. Die fehlende physische Hardware ist kein Ausschlussgrund.

„Unsere App ist kostenlos“

Kostenlos bedeutet nicht automatisch außerhalb einer Geschäftstätigkeit. Monetarisierung und Gesamtgeschäftsmodell müssen betrachtet werden.

„Der Hersteller sitzt außerhalb der EU“

Dann können Importeur und gegebenenfalls weitere Akteure in der EU besonders relevante Pflichten haben. Der Drittstaatssitz beseitigt die Marktanforderungen nicht.

„Wir nutzen nur Open Source“

Der Einsatz von Open-Source-Komponenten befreit ein kommerzielles Endprodukt nicht von Herstellerpflichten. Im Gegenteil verlangt der CRA Sorgfalt bei eingebundenen Drittkomponenten und ein belastbares Komponenten- und Schwachstellenmanagement.

„Das Produkt ist schon am Markt“

Bestandsprodukte müssen wegen Übergangsregeln differenziert betrachtet werden. Die Meldepflichten ab 11. September 2026 können jedoch bereits relevant sein, auch wenn die vollständigen Produktanforderungen erst später greifen.

Welche Grenzfälle sollten Unternehmen besonders dokumentieren?

Gerade bei White-Label-Produkten, OEM-Konstellationen, App-plus-Cloud-Modellen und Produkten mit ausgelagerter Entwicklung ist die Rollenverteilung häufig nicht auf den ersten Blick eindeutig. Entscheidend ist nicht nur, wer programmiert oder fertigt, sondern unter wessen Namen oder Marke das Produkt auf dem Markt erscheint und wer die Verantwortung für das Produkt übernimmt.

Was gilt bei White Label und OEM?

Wer ein bestehendes Produkt unter eigener Marke vermarktet, sollte sorgfältig prüfen, ob dadurch Herstellerpflichten ausgelöst werden. Ein Vertrag, der den technischen Lieferanten als „eigentlichen Hersteller“ bezeichnet, ändert nicht automatisch die regulatorische Rolle gegenüber dem Markt. Deshalb gehören Markenauftritt, Produktkennzeichnung, Vertragsmodell und tatsächliche Änderungsrechte gemeinsam in die Dokumentation.

Was gilt bei App und zwingender Cloud-Funktion?

Wenn eine lokale App oder ein Gerät ohne eine vom Hersteller verantwortete Remote-Komponente eine vorgesehene Funktion nicht erfüllen kann, muss diese Datenfernverarbeitung in die Produktbetrachtung einbezogen werden. Unternehmen sollten deshalb Architekturdiagramm, Verantwortlichkeit für die Remote-Funktion und deren Bedeutung für das Gesamtprodukt dokumentieren.

Was gilt bei Auftragsentwicklung?

Auch wenn ein externer Dienstleister programmiert, kann das beauftragende Unternehmen Hersteller sein, wenn das Produkt unter seinem Namen oder seiner Marke vermarktet wird. Für die CRA-Einordnung ist daher der wirtschaftliche und rechtliche Auftritt nach außen wichtiger als die Frage, welches Entwicklerteam den Code geschrieben hat.

Was folgt nach dem Betroffenheitscheck?

Wenn ein Produkt in den CRA fällt, sollte als Nächstes die eigene Rolle und die Produktkategorie verbindlich dokumentiert werden. Danach folgt die Lückenanalyse gegen die Hersteller- oder Wirtschaftsakteurspflichten. Hersteller sollten insbesondere Risikobewertung, Secure Development, SBOM, Vulnerability Handling, Supportzeitraum, technische Dokumentation und Konformitätsbewertung prüfen.

Der nächste sinnvolle Schritt ist deshalb CRA-Herstellerpflichten. Für die zeitliche Planung sollte parallel die Seite CRA-Fristen 2026–2027 genutzt werden.

Welche offizielle Quelle beschreibt den Anwendungsbereich?

Der verbindliche Ausgangspunkt ist die Verordnung (EU) 2024/2847 bei EUR-Lex, insbesondere Artikel 2 und 3 sowie die einschlägigen Erwägungsgründe. Für Grenzfälle sollte die Produkt- und Rollenbewertung dokumentiert und bei Bedarf fachkundig geprüft werden.