CRA Betroffenheitscheck: Fällt Ihr Produkt unter den Cyber Resilience Act?

Gilt der Cyber Resilience Act für Ihr Produkt? Entscheidend sind das konkrete Software- oder Hardwareprodukt, seine vorgesehenen oder vernünftigerweise vorhersehbaren Datenverbindungen, die Bereitstellung auf dem EU-Markt und mögliche Ausnahmen. Die Branche oder die Bezeichnung „SaaS“ allein beantwortet die Frage nicht. Stand: 8. September 2026.

Prüfen Sie zunächst die Produktgrenze und Ihre Rolle als Hersteller, Einführer oder Händler. Danach folgen Ausnahmeprüfung, Kernfunktion und Konformitätsweg. Zeitlich sind zwei Aufgaben zu trennen: Die Meldepflichten nach Artikel 14 beginnen am 11. September 2026; die übrigen wesentlichen Produktpflichten gelten ab 11. Dezember 2027. Auch Bestandsprodukte können von den Meldepflichten erfasst sein.

Dieser Artikel gibt Ihnen einen strukturierten Betroffenheitscheck in drei Schritten — und klärt die häufigsten Grenzfälle.

Schnellcheck: 3 Fragen für die erste Einordnung

Diese drei Fragen geben eine erste Orientierung. Dokumentieren Sie Grenzfälle als offen, bis Produktunterlagen und Vertriebsmodell geprüft sind:

Frage 1: Gehört eine direkte oder indirekte Datenverbindung zur vorgesehenen oder vernünftigerweise vorhersehbaren Verwendung? Wenn nein, ist die Verbindungsvoraussetzung des Artikels 2 Absatz 1 nicht erfüllt. Prüfen Sie zuvor auch Komponenten und Datenfernverarbeitung.

Frage 2: Wird das Produkt im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt? Auch kostenlose Abgabe kann erfasst sein. Hersteller außerhalb der EU können ebenfalls Pflichten haben; Einführer und Händler sind zusätzlich nach ihrer eigenen Rolle zu prüfen.

Frage 3: Fällt Ihr Produkt unter eine der expliziten Ausnahmen des Artikels 2? Prüfen Sie den konkreten Rechtsakt und das konkrete Produkt. Eine pauschale Ausnahme für eine gesamte Branche gibt es nicht; Open Source wird zusätzlich anhand der Geschäftstätigkeit und der Akteursrolle geprüft.

Wenn Sie alle die Fragen mit "Ja / Ja / Nein" beantwortet haben: Sie sind wahrscheinlich betroffen. Lesen Sie weiter für die genaue Einordnung.

Schritt 1: Ist es ein "Produkt mit digitalen Elementen"?

Ein Produkt mit digitalen Elementen ist nach Artikel 3 ein Software- oder Hardwareprodukt einschließlich seiner Datenfernverarbeitungslösungen; separat in Verkehr gebrachte Komponenten können ebenfalls erfasst sein. Artikel 2 verlangt außerdem eine direkte oder indirekte logische oder physische Datenverbindung im bestimmungsgemäßen Zweck oder in der vernünftigerweise vorhersehbaren Verwendung.

Beispiele die unter den CRA fallen:

Hardware: Industriesteuerungen, Firewalls, Router, Smart-Home-Geräte, IoT-Sensoren, Laptops, Smartphones, vernetzte Spielzeuge, Mikroprozessoren

Software: Betriebssysteme, Netzwerkmanagementsoftware, Passwortmanager, Antivirenprogramme, mobile Apps, Buchhaltungssoftware mit Netzwerkanbindung, VPN-Software, Firewalls

Eingebettete Software: Firmware für vernetzte Geräte, Software die direkt im Produkt läuft und nicht separat vertrieben wird

Entscheidendes Kriterium:

Eine aktive Internetverbindung ist nicht erforderlich. Auch eine vorgesehene USB-Verbindung oder lokale Bluetooth-Kommunikation kann genügen. Entscheidend ist die bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung; eine rein theoretische Anschlussmöglichkeit ersetzt diese Prüfung nicht. Dokumentieren Sie bei Serviceports, wer sie wann nutzen kann und welche Daten darüber übertragen werden.

Schritt 2: Gibt es Ausnahmen nach Artikel 2?

Selbst wenn Ihr Produkt ein PDE ist, kann es von spezifischeren EU-Regelwerken erfasst sein, die den CRA verdrängen:

Medizinprodukte und In-vitro-Diagnostika — geregelt durch MDR (EU) 2017/745 und IVDR (EU) 2017/746

Kraftfahrzeuge und Fahrzeugsysteme — geregelt durch Verordnung (EU) 2019/2144 (Typgenehmigung)

Produkte der zivilen Luftfahrt — ausgenommen, wenn nach Verordnung (EU) 2018/1139 zertifiziert

Schiffsausrüstung — geregelt durch Richtlinie 2014/90/EU

Verteidigungsgüter und nationale Sicherheit — erfasst sind die Ausnahmen für ausschließlich zu diesen Zwecken entwickelte oder geänderte Produkte sowie speziell für Verschlusssachen konzipierte Produkte

Nicht-kommerzielle Open-Source-Software — die kommerzielle Bereitstellung des konkreten Produkts und eine mögliche Rolle als Open-Source-Verwalter sind gesondert zu prüfen

Wichtig zur Open-Source-Ausnahme:

Bei freier und quelloffener Software zählt, ob das konkrete Produkt im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Ein frei zugänglicher Quellcode oder ein kostenloser Download entscheidet dies nicht allein. Separat angebotener, optionaler kostenpflichtiger Support macht die Software nach der Kommissionsleitlinie vom Juli 2026 für sich genommen noch nicht kommerziell. Anders kann es sein, wenn der Zugang zur Software oder ihrer Wartung an eine Zahlung gebunden ist. Für Open-Source-Verwalter besteht ein gesondertes Pflichtenregime nach Artikel 24; Hersteller bleiben für die Sicherheit ihres integrierten Gesamtprodukts verantwortlich.

Schritt 3: Welche Kategorie trifft auf Ihr Produkt zu?

Wenn Ihr Produkt unter den CRA fällt und keine Ausnahme greift, bestimmt die Produktklasse den Aufwand der Konformitätsbewertung. Der CRA kennt drei Kategorien, die Kategorie "Wichtige Produkte" unterscheidet zwei Klassen:

Standardprodukte: keine Kernfunktion aus Anhang III oder IV

Dies ist die Standardkategorie für alle Produkte mit digitalen Elementen, die nicht die Kernfunktionen einer Produktkategorie aus Anhang III oder IV aufweisen. Hier kann eine interne Fertigungskontrolle nach Modul A genutzt werden. Beispiele können einfache vernetzte Sensoren oder Bürosoftware sein, sofern deren Kernfunktion tatsächlich keiner gelisteten Kategorie entspricht. Die bloße Integration eines Betriebssystems oder anderer wichtiger Komponenten führt nicht automatisch zur höheren Einstufung des Gesamtprodukts.

Wichtige Produkte (Anhang III)

Diese Produkte weisen ein höheres Risiko auf, da ihre Funktionen erhebliche Auswirkungen auf die Gesundheit, Sicherheit oder die Cybersicherheit anderer Systeme haben können. Sie werden in zwei Klassen unterteilt:

• Klasse I: Maßgeblich sind die gelisteten Kernfunktionen und ihre technischen Beschreibungen, nicht ein frei vergebener Risikoscore. Beispiele:
  • Identitätsmanagementsysteme und Passwort-Manager
  • Browser sowie VPN-Software
  • Betriebssysteme, Router und Switches
  • Mikroprozessoren mit sicherheitsrelevanten Funktionen
  • Bestimmte vernetzte Spielzeuge und Gesundheits-Wearables
• Klasse II: Hierunter fallen Produkte mit einem deutlich höheren Cybersicherheitsrisiko, insbesondere solche mit zentralen Sicherheitsfunktionen. Beispiele sind:
  • Hypervisoren und Container-Runtime-Systeme
  • Firewalls, Intrusion-Detection- (IDS) und Intrusion-Prevention-Systeme (IPS)
  • Manipulationssichere Mikroprozessoren und Mikrocontroller

Bei Produkten der Klasse II sieht Artikel 32 insbesondere Verfahren mit einer notifizierten Stelle vor: Modul B plus C oder Modul H. Daneben kann ein verfügbares und anwendbares europäisches Zertifizierungsschema genutzt werden. Für freie und quelloffene Produkte aus Anhang III besteht die Sonderregel des Artikels 32 Absatz 5 bei öffentlich zugänglicher technischer Dokumentation.

Kritische Produkte (Anhang IV)

Diese Kategorie umfasst Produkte, die als kritische Abhängigkeiten für wesentliche Einrichtungen (z. B. im Rahmen der NIS-2-Richtlinie) gelten und deren Ausfall schwerwiegende Störungen in Lieferketten verursachen könnte. Hierzu zählen:

• Hardwaregeräte mit Sicherheitsboxen
• Smart-Meter-Gateways in intelligenten Messsystemen
• Chipkarten oder ähnliche Sicherheitselemente.

Für diese kritischen Produkte kann die Kommission eine obligatorische europäische Cybersicherheitszertifizierung (mindestens Vertrauenswürdigkeitsstufe „mittel“) vorschreiben, sofern ein entsprechendes Zertifizierungsschema existiert.

Was bedeutet die Klasse für Ihre Pflichten?

Die Klasse bestimmt vor allem den Weg zur CE-Kennzeichnung:

Standard-Produkte: Selbstbewertung durch den Hersteller. Eigene Prüfung gegen die Sicherheitsanforderungen des Anhang I, Erstellung der technischen Dokumentation, Konformitätserklärung, CE-Kennzeichnung.

Wichtige Produkte Klasse I (Anhang III): Modul A kommt bei ordnungsgemäßer Anwendung der einschlägigen harmonisierten Normen, gemeinsamen Spezifikationen oder qualifizierenden europäischen Zertifizierungsschemata nach Artikel 27 in Betracht. Andernfalls sind grundsätzlich Modul B plus C oder Modul H erforderlich. Zusätzlich ist die Open-Source-Sonderregel in Artikel 32 Absatz 5 zu prüfen.

Wichtige Produkte Klasse II (Anhang III): Grundsätzlich Modul B plus C oder Modul H; ein verfügbares und anwendbares europäisches Zertifizierungsschema kann eine weitere Route sein. Artikel 32 Absatz 5 eröffnet für qualifizierende freie und quelloffene Produkte aus Anhang III bei öffentlicher technischer Dokumentation weitere Verfahren, einschließlich Modul A.

Kritische Produkte (Anhang IV): Artikel 8 und Artikel 32 Absatz 4 bestimmen den Weg. Eine verpflichtende europäische Zertifizierung setzt den entsprechenden delegierten Rechtsakt voraus. Sind die Bedingungen nicht erfüllt, gelten die Verfahren aus Artikel 32 Absatz 3. Anhang IV umfasst Sicherheitsboxen, Smart-Meter-Gateways und Chipkarten oder ähnliche Geräte einschließlich sicherer Elemente nach den jeweiligen technischen Beschreibungen.

Die grundlegenden Anforderungen stehen in Anhang I. Ihre technische Umsetzung richtet sich nach der dokumentierten Cybersicherheitsrisikobewertung des Produkts. Dazu gehören sichere Entwicklung, Schwachstellenbehandlung und eine maschinenlesbare SBOM mindestens für die obersten Abhängigkeiten. Eine allgemeine Pflicht zur öffentlichen Veröffentlichung der SBOM folgt daraus nicht. Sicherheitsupdates sind grundsätzlich kostenlos bereitzustellen; für maßgeschneiderte Produkte zwischen Hersteller und gewerblichem Nutzer enthält Anhang I Teil II Nummer 8 eine vertragliche Ausnahme.

Grenzfälle: SaaS, Cloud, Updates, B2B-Software

SaaS und reine Cloud-Services

Eigenständige SaaS-Dienste sind grundsätzlich nicht als solche vom CRA erfasst. Ein Cloud-Bestandteil kann aber als Datenfernverarbeitungslösung zum Produkt gehören: Die Software muss vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt sein, und ohne die entfernte Verarbeitung könnte das Produkt eine seiner Funktionen nicht erfüllen. Das gilt für Softwareprodukte ebenso wie für Hardware. Eine NIS2-Einordnung ersetzt diesen Test nicht. Zeichnen Sie Client, App, Backend und externe Dienste getrennt auf und begründen Sie für jeden Bestandteil die Produktgrenze.

Software-Updates und Patches

Artikel 69 enthält eine Übergangsregel: Vor dem 11. Dezember 2027 in Verkehr gebrachte Produkte unterliegen den übrigen CRA-Anforderungen grundsätzlich erst bei einer wesentlichen Änderung nach diesem Datum. Die Meldepflichten nach Artikel 14 sind davon ausgenommen und gelten ab 11. September 2026 auch für erfasste Bestandsprodukte. Eine wesentliche Änderung beeinflusst die Konformität mit Anhang I Teil I oder ändert die geprüfte Zweckbestimmung. Ein Sicherheitsfix ist deshalb nicht automatisch eine wesentliche Änderung. Neue Produkteinheiten und Softwareversionen sind anhand ihres konkreten Inverkehrbringens und der Kommissionsleitlinie zu prüfen.

B2B-Software

Der CRA gilt ausdrücklich auch für B2B-Software. Wer Netzwerkmanagement-Software, SIEM-Systeme oder ERP-Lösungen mit Netzwerkanbindung an Unternehmen verkauft, ist genauso betroffen wie ein Consumer-App-Anbieter. Die häufige Annahme "Wir machen nur B2B, also gilt der CRA nicht" ist ein kostspieliger Irrtum.

Embedded Software

Software die fest in ein Hardwareprodukt eingebettet ist und nicht separat vertrieben wird, ist Teil des PDE. Die CRA-Anforderungen gelten für das Gesamtsystem. Der Hardwarehersteller ist für die Compliance des gesamten Produkts verantwortlich — einschließlich der eingebetteten Software.

Prüfergebnis zum Ausfüllen: ein Datensatz je Produkt

1. Produktgrenze: Produktname, Version, separat vertriebene Komponenten und Architekturdiagramm. Welche Funktionen hängen von App, Backend oder Cloud ab? Wer verantwortet deren Entwicklung?

2. Markt und Rolle: Wer vermarktet das Produkt unter welchem Namen? Wer stellt es wann erstmals auf dem EU-Markt bereit? Notieren Sie Hersteller, Einführer und Händler sowie Lizenz-, Zahlungs- und Vertriebsmodell. Auch Individualsoftware für einen einzigen Kunden kann erfasst sein.

3. Rechtsgrund und Klasse: Belegen Sie Datenverbindung und Verwendung, prüfen Sie produktspezifische Ausnahmen und vergleichen Sie die Kernfunktion mit Anhang III/IV sowie den technischen Beschreibungen der Durchführungsverordnung (EU) 2025/2392. Halten Sie Quelle und Fundstelle fest.

4. Entscheidung: „erfasst“, „nicht erfasst mit Begründung“ oder „offen“. Ergänzen Sie Konformitätsweg, Datum des Inverkehrbringens, mögliche wesentliche Änderungen, Artikel-14-Meldebereitschaft, verantwortliche Person und Wiedervorlagetermin. Eine offene Frage ist kein bestätigter Ausschluss.

Beispiel: Ein Bluetooth-Temperatursensor wird für die Überwachung einer Fabrik verkauft. Industrieller Einsatz allein macht ihn nicht zu Klasse II. Ist Temperaturmessung die Kernfunktion und trifft keine gelistete Kategorie zu, kommt die Standardkategorie in Betracht. Ein integriertes Betriebssystem führt für sich genommen nicht zur Einstufung des ganzen Sensors als wichtiges Produkt. Das Ergebnis bleibt von den tatsächlichen Funktionen und Ausnahmen abhängig.

Für eine konkrete Anfrage genügen zunächst Produktgruppe, Vertriebsmodell, Architektur und die wichtigste ungeklärte Frage. Daraus lässt sich klären, ob Sie eine Betroffenheitsanalyse, eine vertiefte Klassifizierung oder bereits eine technische Gap-Analyse benötigen.

Quellen und Prüfstand

Geprüft am 8. September 2026. Maßgeblich ist das verbindliche Recht; Kommissionsleitlinie und FAQ unterstützen die Auslegung und ersetzen keine fallbezogene Prüfung.

Verordnung (EU) 2024/2847: Artikel 2, 3, 7, 8, 14, 32, 69 und 71; Anhänge III und IV

Kommissionsleitlinie vom 27. Juli 2026 (C(2026) 5252)

Kommissions-FAQ, Version 1.4 vom 4. September 2026

ADVISORI Betroffenheitsanalyse: vom Produktkatalog zur begründeten Entscheidung

ADVISORI unterstützt Sie bei einer strukturierten CRA-Betroffenheitsanalyse. Ziel ist eine nachvollziehbare Einordnung je Produkt mit Rolle, Ausnahmeprüfung, Produktklasse, Konformitätsweg und nächsten Schritten. Fehlende Nachweise und rechtlich oder technisch offene Fragen werden ausdrücklich festgehalten. Umfang und Zeitplan hängen vom Portfolio und den verfügbaren Unterlagen ab.

Was die Analyse umfasst:

Produktkatalog-Review: Erfassung aller relevanten Produkte und Produktkomponenten

Klassifizierungsworkshop: Einordnung nach Anhang III/IV, Prüfung der Ausnahmetatbestände

Gap-Analyse: Abgleich des Status quo mit den CRA-Anforderungen

Compliance-Roadmap: Getrennte Maßnahmen für Artikel-14-Meldebereitschaft ab 11. September 2026 und Produktkonformität ab 11. Dezember 2027, jeweils mit Verantwortlichen und offenen Nachweisen

Mehr zum übergeordneten CRA-Kontext finden Sie in unserem Artikel Was ist der Cyber Resilience Act? Der vollständige Überblick für Unternehmen.

Die CRA-Meldepflicht ab 11. September 2026 erklären wir ausführlich in unserem Artikel CRA-Meldepflicht ab September 2026.

FAQ: Häufige Fragen zur CRA-Betroffenheit

Fällt mein Produkt unter den CRA, wenn es nur per Bluetooth verbindbar ist?

Eine vorgesehene oder vernünftigerweise vorhersehbare Bluetooth-Datenverbindung kann die Verbindungsvoraussetzung erfüllen, auch ohne Internet. Zusätzlich sind die Bereitstellung auf dem EU-Markt, die Produktgrenze und mögliche Ausnahmen zu prüfen. Bluetooth allein legt keine Produktklasse fest.

Wir entwickeln Open-Source-Software und verkaufen Supportleistungen dazu — gilt der CRA für uns?

Nicht automatisch. Nach der Kommissionsleitlinie vom 27. Juli 2026 reicht separat angebotener, optionaler kostenpflichtiger Support allein nicht aus, um freie und quelloffene Software als kommerziell bereitgestellt einzuordnen. Prüfen Sie dagegen Zahlungsvoraussetzungen für Softwarezugang oder Wartung, kostenpflichtige Produkteditionen und weitere Monetarisierung. Die Rolle als Hersteller oder Open-Source-Verwalter ist gesondert zu bestimmen.

Wir sind ein Händler — müssen wir selbst die Konformität sicherstellen?

Händler haben eigene Prüf- und Mitwirkungspflichten nach Artikel 20, etwa zu CE-Kennzeichnung, Hersteller- und Einführerangaben, erforderlichen Unterlagen und zum Umgang mit erkennbarer Nichtkonformität. Eigene Herstellerpflichten können entstehen, wenn Einführer oder Händler ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringen oder wesentlich ändern. Die Rolle muss am konkreten Vertriebsmodell geprüft werden.

Ab wann muss ich die Betroffenheitsanalyse abgeschlossen haben?

Priorisieren Sie jetzt die Artikel-14-Meldebereitschaft zum 11. September 2026: betroffene Bestandsprodukte, verantwortliches Team, Vertretung, Bewertung eines Meldeauslösers und Übermittlungsweg. Parallel ist die Produktkonformität für das Inverkehrbringen ab 11. Dezember 2027 vorzubereiten. Die notwendige Vorlaufzeit hängt von Produkt, Lücken und Konformitätsweg ab; eine pauschale Projektdauer wäre dafür keine belastbare Grundlage.

Nächster Schritt: Ihre CRA-Betroffenheit klären

Bringen Sie für das Erstgespräch eine Produktliste, ein Architekturdiagramm, das Vertriebs- und Lizenzmodell sowie geplante Markteinführungstermine mit. Benennen Sie insbesondere offene Fragen zu SaaS, Open Source, Individualsoftware oder Produktklassen. Gemeinsam lässt sich daraus der passende Umfang einer Betroffenheitsanalyse ableiten.

→ Jetzt Betroffenheitsanalyse anfragen

Weiterführend: CRA, NIS2, DORA: Welche Regulierung gilt für mein Unternehmen?

Unsicher ob Ihr Produkt betroffen ist? ADVISORI erstellt eine formale Betroffenheitsanalyse mit Klassifizierung nach Anhang III/IV — die Basis für alle weiteren Compliance-Schritte. → Jetzt Betroffenheitsanalyse anfragen