Betroffene Produkte: Welche Hardware und Software unter den CRA fällt
Der CRA gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden: vom vernetzten Sensor über die Bürosoftware bis zum Hardware-Sicherheitsmodul. Die Verordnung teilt sie in vier Stufen ein, die bestimmen, wie die Konformität nachzuweisen ist. Diese Seite erklärt die Definition, die Klassen mit Beispielen, die Ausnahmen und die Sonderregeln für Open Source.
- 4 Stufen Standard, wichtig Klasse I, wichtig Klasse II, kritisch
- Anhang III listet die wichtigen Produkte der Klassen I und II
- Anhang IV listet die kritischen Produkte
- 11.12.2027 ab dann nur noch konforme Produkte auf dem EU-Markt
Was ein Produkt mit digitalen Elementen ist
Erfasst ist jedes Software- oder Hardwareprodukt einschließlich seiner Datenfernverarbeitungslösungen, das direkt oder indirekt mit einem Gerät oder Netz verbunden werden kann und im Rahmen einer Geschäftstätigkeit bereitgestellt wird.
- Hardware
Geräte mit Software
Vernetzte Geräte jeder Art: Industriesteuerungen, Sensoren, Kameras, Drucker, Smart-Home-Produkte, Netzwerkkomponenten, Wearables. Die eingebettete Firmware ist Teil des Produkts und wird mit ihm bewertet.
- Software
Eigenständige Software
Anwendungssoftware, Betriebssysteme, Bibliotheken, mobile Apps, Firmware, die getrennt vertrieben wird. Auch Software, die als Download oder per Lizenz bereitgestellt wird, ist ein Produkt im Sinne des CRA.
- Fernverarbeitung
Zugehörige Cloud-Komponenten
Datenfernverarbeitung, die der Hersteller für das Produkt entwickelt hat und ohne die eine Funktion des Produkts nicht erfüllt werden könnte, etwa das Backend einer Geräte-App. Reine Cloud-Dienste ohne Produktbezug bleiben bei NIS2.
Kommerzielle Bereitstellung ist der Schlüssel: Der CRA greift, wenn ein Produkt im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird, entgeltlich oder unentgeltlich. Ausschließlich intern genutzte Eigenentwicklungen sind nicht erfasst. Wird dieselbe Software an Kunden abgegeben, ändert sich das.
Standard, wichtig, kritisch: Die Einordnung nach Anhang III und IV
Die Verordnung ordnet Produkte nach dem Cybersicherheitsrisiko ihrer Kategorie ein. Maßgeblich ist die Kernfunktionalität des Produkts, nicht eine beliebige Nebenfunktion.
| Klasse | Beispiele | Was das bedeutet |
|---|---|---|
| Standardprodukte | Die große Mehrheit: Anwendungssoftware ohne sicherheitskritische Kernfunktion, vernetzte Geräte ohne Sicherheitsrolle, Textverarbeitung, Bildbearbeitung, Spiele, Sensoren, Drucker, die meisten Apps | Grundlegende Anforderungen nach Anhang I gelten voll. Konformitätsbewertung durch interne Kontrolle des Herstellers. |
| Wichtige Produkte, Klasse I (Anhang III) | Identitätsmanagement und Zugriffsverwaltung, Passwortmanager, Browser, Virenschutz, VPN-Produkte, Netzwerkmanagement, SIEM-Systeme, Boot-Manager, PKI-Software, Betriebssysteme, Router, Modems, Switches, Mikroprozessoren und Mikrocontroller mit Sicherheitsfunktionen, Smart-Home-Assistenten, smarte Türschlösser, Sicherheitskameras, Babyphones, Alarmanlagen, vernetztes Spielzeug mit Standort- oder Interaktionsfunktion, Wearables zur Gesundheitsüberwachung | Selbstbewertung nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema vollständig angewendet werden. Sonst Prüfung durch eine notifizierte Stelle. |
| Wichtige Produkte, Klasse II (Anhang III) | Hypervisoren und Container-Laufzeitumgebungen, Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme, manipulationssichere Mikroprozessoren und Mikrocontroller | Konformitätsbewertung durch eine notifizierte Stelle: EU-Baumusterprüfung oder umfassende Qualitätssicherung, alternativ ein europäisches Cybersicherheitszertifikat. |
| Kritische Produkte (Anhang IV) | Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways in intelligenten Messsystemen und andere Geräte für erweiterte Sicherheitszwecke wie sichere Kryptoverarbeitung, Smartcards und ähnliche Geräte einschließlich sicherer Elemente | Wie Klasse II. Die Kommission kann zusätzlich ein europäisches Cybersicherheitszertifikat verpflichtend vorschreiben. |
Kernfunktion entscheidet: Ein Produkt ist wichtig oder kritisch, wenn seine Kernfunktionalität einer der genannten Kategorien entspricht. Ein Industriegerät, das ein Netzwerkmodul enthält, ist kein Router; eine Anwendung mit Login-Maske ist kein Identitätsmanagementsystem. Die Begründung gehört in die technische Dokumentation. Wie sich die Klasse auf den Prüfweg auswirkt, erklärt die Seite CRA-Konformitätsbewertung.
Wer nicht unter den CRA fällt
Produkte, für die bereits sektorspezifische Cybersicherheitsanforderungen gelten, sind vom Anwendungsbereich ausgenommen. Die Ausnahme gilt für das regulierte Produkt, nicht für alles, was der Hersteller sonst noch verkauft.
-
Medizinprodukte
Produkte, die unter die Medizinprodukteverordnung (EU) 2017/745 oder die Verordnung über In-vitro-Diagnostika (EU) 2017/746 fallen. Dort gelten eigene Anforderungen an Software und Cybersicherheit; der CRA tritt zurück.
-
Kraftfahrzeuge
Fahrzeuge, Systeme und Bauteile, die der Typgenehmigung nach der Verordnung (EU) 2019/2144 unterliegen. Die Cybersicherheit wird dort über die UNECE-Regelungen zur Typgenehmigung abgedeckt.
-
Luftfahrt
Produkte im Anwendungsbereich der Verordnung (EU) 2018/1139 über die Zivilluftfahrt. Auch hier greift ein eigener Rechtsrahmen mit Zertifizierung durch die Luftfahrtbehörden.
Weitere Ausnahmen: Schiffsausrüstung nach der Richtlinie 2014/90/EU, Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt wurden, sowie Ersatzteile, die ein identisches Bauteil ersetzen. Wer neben einem ausgenommenen Produkt auch Zubehör, Software oder Geräte für den allgemeinen Markt vertreibt, unterliegt für diese dem CRA.
Freie Software und Open-Source-Stewards
Der CRA unterscheidet zwischen der nichtkommerziellen Entwicklung freier Software, ihrer organisierten Unterstützung und ihrer kommerziellen Verwendung in Produkten.
- Ausgenommen
Nichtkommerzielle Bereitstellung
Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt und bereitgestellt wird, fällt nicht unter die Herstellerpflichten. Spenden ohne Gewinnabsicht oder die Entwicklung durch gemeinnützige Organisationen ändern daran nichts.
- Leichter Pflichtenkatalog
Open-Source-Steward
Stiftungen und Organisationen, die die Entwicklung von Open-Source-Produkten für den kommerziellen Einsatz dauerhaft unterstützen, unterliegen einem eigenen Regime: eine Cybersicherheitsstrategie für das Projekt, Zusammenarbeit mit der Marktüberwachung und Mitwirkung bei Schwachstellenmeldungen. Keine CE-Kennzeichnung, keine Konformitätsbewertung.
- Volle Pflichten
Kommerzielle Verwendung
Wer Open-Source-Komponenten in ein kommerzielles Produkt integriert oder Open-Source-Software gegen Entgelt oder mit kommerzieller Absicht bereitstellt, ist Hersteller. Die Komponenten sind in der Software-Stückliste zu führen, ihre Schwachstellen zu verfolgen und zu beheben.
Produktinventar und Klassifizierung in vier Schritten
Ergebnis ist eine schriftliche Einordnung je Produkt, die vor der Marktüberwachung und vor Ihren Kunden standhält.
-
Inventar aller Produkte und Softwarekomponenten
Welche Produkte, Varianten, Firmware-Stände und begleitenden Cloud-Komponenten bringen Sie in der EU in Verkehr? Einschließlich White-Label-Ware, Zukaufteile unter eigener Marke und Software, die Kunden als Teil einer Dienstleistung erhalten.
-
Anwendungsbereich und Ausnahmen prüfen
Je Produkt: Ist es ein Produkt mit digitalen Elementen? Greift eine sektorale Ausnahme? Liegt eine nichtkommerzielle Bereitstellung vor? Das Ergebnis wird mit Begründung dokumentiert, auch ein begründetes „nicht erfasst“.
-
Klasse nach Kernfunktionalität bestimmen
Abgleich der Kernfunktion mit den Kategorien in Anhang III und IV. Bei Grenzfällen bewerten wir Funktionsbeschreibung, Marketingaussagen und technische Architektur gemeinsam, denn die Marktüberwachung wird alle drei heranziehen.
- Rolle je Produkt: Hersteller, Importeur oder Händler
- Supportzeitraum je Produkt festlegen
-
Prüfweg und Fahrplan ableiten
Aus Klasse und Rolle ergibt sich der Weg zur Konformität: interne Kontrolle, harmonisierte Normen oder notifizierte Stelle. Wir priorisieren nach Umsatzanteil, Klasse und Aufwand bis zum 11. Dezember 2027.
Eine erste Einschätzung erhalten Sie mit dem CRA-Check auf jamorie.eu.
Vertiefung zum Cyber Resilience Act
-
CRA-Übersicht
Wen der CRA verpflichtet, was Hersteller, Importeure und Händler tun müssen, und wie der Zeitplan bis Dezember 2027 aussieht.
-
Konformitätsbewertung
Interne Kontrolle, harmonisierte Normen oder notifizierte Stelle: Welcher Prüfweg für welche Klasse gilt und was technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung verlangen.
-
Meldepflicht
Seit 11. September 2026: aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle in 24 Stunden, 72 Stunden und mit Abschlussmeldung über die ENISA-Plattform melden.
Betroffene Produkte kurz beantwortet
Unsere Software läuft nur intern und wird nicht verkauft. Ist sie ein Produkt mit digitalen Elementen?
Der CRA erfasst Produkte, die auf dem EU-Markt bereitgestellt werden, also im Rahmen einer Geschäftstätigkeit an Dritte abgegeben werden. Software, die Sie ausschließlich selbst entwickeln und selbst nutzen, wird nicht in Verkehr gebracht und fällt nicht unter die Herstellerpflichten. Sobald Sie dieselbe Software Kunden bereitstellen, auch als Bestandteil einer Dienstleistung oder eines Geräts, ändert sich das.
Ist Software as a Service ein Produkt mit digitalen Elementen?
Reine Cloud-Dienste ohne Produktbezug sind kein Produkt mit digitalen Elementen; für sie gilt NIS2. Der CRA erfasst jedoch Datenfernverarbeitungslösungen, die der Hersteller für ein Produkt entwickelt hat und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte, etwa die Cloud-Anbindung einer Alarmanlage oder das Backend einer App zu einem Gerät. Diese Komponenten werden mit dem Produkt bewertet.
Unser Gerät enthält einen Router-Chip. Sind wir damit ein wichtiges Produkt der Klasse I?
Nicht automatisch. Maßgeblich ist die Kernfunktion Ihres Produkts. Ein Produkt gilt als wichtig, wenn seine Kernfunktionalität einer der Kategorien in Anhang III entspricht. Ein Industriegerät, das nebenbei ein Netzwerkmodul enthält, ist kein Router. Die Einordnung muss aber begründet und dokumentiert werden, denn die Marktüberwachung wird genau danach fragen.
Wir bauen Open-Source-Komponenten in unser Produkt ein. Wer ist verantwortlich?
Sie. Die Ausnahme für Open-Source-Software gilt für die nichtkommerzielle Bereitstellung durch die Entwickler, nicht für die kommerzielle Verwendung der Komponente in Ihrem Produkt. Als Hersteller müssen Sie die eingesetzten Komponenten kennen, ihre Schwachstellen verfolgen und Updates bereitstellen. Eine Software-Stückliste ist dafür die Grundlage.
Was gilt für Produkte, die schon vor Dezember 2027 im Markt sind?
Für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gelten die grundlegenden Anforderungen nicht nachträglich, solange sie danach nicht wesentlich verändert werden. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten jedoch seit dem 11. September 2026 auch für diese Produkte. Ein größeres Firmware-Update mit neuen Funktionen kann eine wesentliche Veränderung sein.
Marcel Rieger
Lassen Sie Ihr Produktportfolio einordnen
Im kostenlosen Erstgespräch gehen wir Ihre Produkte durch, prüfen Anwendungsbereich, Ausnahmen und Klasse und benennen den Prüfweg, der daraus folgt.
- Einordnung Ihrer Produkte nach Anhang III und IV
- Klärung von Ausnahmen und Open-Source-Fragen
- Priorisierung bis zum 11. Dezember 2027
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen