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

Montag, 9 Uhr. Ihr Produktmanager öffnet nach einem Wochenende in Berlin seinen Laptop. In seinem Posteingang: eine E-Mail vom Rechtsanwalt. Betreff: "CRA-Compliance für Ihre SaaS-Plattform — Handlungsbedarf." Gleichzeitig ruft der Fertigungsleiter an: Der neue IoT-Sensor soll Q1 2027 in Serie gehen — "Brauchen wir dafür eine CE-Kennzeichnung nach CRA?"

Diese Frage stellen sich gerade Tausende Produktverantwortliche in Deutschland. Die Antwort ist nicht immer eindeutig — aber sie ist entscheidend. Denn wer vom Cyber Resilience Act betroffen ist, braucht CE-Kennzeichnung, Schwachstellenmanagement und Meldeprozesse. Wer nicht betroffen ist, kann sich die Compliance-Investition sparen.

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

Schnellcheck: 3 Fragen die sofort Klarheit schaffen

Beantworten Sie diese drei Fragen — sie filtern die meisten Fälle:

Frage 1: Ist Ihr Produkt direkt oder indirekt mit einem Netzwerk oder einem anderen Gerät verbindbar? Wenn nein → kein Produkt mit digitalen Elementen, CRA gilt nicht.

Frage 2: Bringen Sie das Produkt auf dem EU-Markt in Verkehr? Wenn nein → CRA gilt für Sie nicht (aber für Ihren EU-Importeur, welcher das ggf. von Ihnen einfordert).

Frage 3: Fällt Ihr Produkt unter eine der expliziten Ausnahmen des Artikels 2? (Medizin, Automotive, Luftfahrt, Verteidigung, nicht-kommerzielle OSS) Wenn ja → kein CRA.

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"?

Der CRA definiert "Produkte mit digitalen Elementen" (PDE) als Software- oder Hardwareprodukte und deren Datenfernverarbeitungslösungen, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden können. Diese Definition ist bewusst weit gefasst.

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:

Es geht nicht darum, ob das Produkt hauptsächlich eine Netzwerkfunktion hat — es reicht, dass es überhaupt verbunden werden kann. Eine Industriesteuerung die normalerweise im Offline-Betrieb läuft, aber theoretisch per USB oder Ethernet verbunden werden könnte, fällt unter den CRA.

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 — geregelt durch EASA-Regulierung

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

Verteidigungsgüter und nationale Sicherheit — ausdrücklich ausgenommen

Nicht-kommerzielle Open-Source-Software — OSS ohne kommerziellen Kontext ist ausgenommen; kommerzielle OSS-Produkte fallen unter den CRA

Wichtig zur Open-Source-Ausnahme:

Die Grenze zwischen "nicht-kommerziell" und "kommerziell" ist bei Open-Source-Produkten oft fließend. Ein Unternehmen, das eine Open-Source-Bibliothek in ein kommerzielles Produkt einbettet, muss CRA-Anforderungen für das Gesamtprodukt erfüllen. Nur das reine Bereitstellen von OSS ohne jede kommerzielle Verbindung ist ausgenommen.

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:

Standard-Produkte (ca. 90 % aller betroffenen Produkte)

Dies ist die Standardkategorie für alle Produkte mit digitalen Elementen, die nicht explizit als „wichtig“ oder „kritisch“ in den Anhängen III oder IV der Verordnung aufgeführt sind. Für diese Produkte reicht in der Regel eine interne Fertigungskontrolle (Konformitätsbewertung durch den Hersteller selbst) aus, um die Einhaltung der Cybersicherheitsanforderungen nachzuweisen. Die große Mehrheit aller vernetzten Produkte fällt in diese Kategorie. Beispiele: einfache IoT-Geräte, Standard-Apps, vernetzte Haushaltsgeräte, Bürosoftware mit Netzwerkanbindung.

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: Diese Klasse umfasst Produkte mit einem mittleren Risikoprofil. Dazu gehören beispielsweise:
  • 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 ist die Einbeziehung einer notifizierten Stelle (Dritter) in das Konformitätsbewertungsverfahren zwingend vorgeschrieben.

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): Selbstbewertung möglich, wenn eine harmonisierte EU-Norm angewendet wird. Alternativ: Konformitätsbewertung durch eine notifizierte Stelle. Ohne Norm ist die Drittbewertung Pflicht.

Wichtige Produkte Klasse II (Anhang III): Konformitätsbewertung durch eine notifizierte Stelle ist immer erforderlich. Selbstbewertung reicht nicht aus.

Kritische Produkte (Anhang IV): Europäische Cybersicherheitszertifizierung nach dem EU Cybersecurity Act ist erforderlich. Aktuell sind nur Smart-Meter-Gateways und Chipkarten in diesem Anhang.

Unabhängig von der Klasse gelten für alle Produkte mit digitalen Elementen dieselben technischen Grundanforderungen aus Anhang I: Security by Design, Schwachstellenmanagement, SBOM, kostenlose Sicherheitsupdates und Meldepflichten.

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

SaaS und reine Cloud-Services

Reine Software-as-a-Service-Angebote und Cloud-Computing-Dienste sind grundsätzlich vom CRA ausgenommen, sofern sie unter die NIS2-Richtlinie oder andere spezifische Regulierungen fallen. Kritisch wird es bei hybriden Produkten: Wenn ein SaaS-Dienst ein unverzichtbarer Bestandteil eines vernetzten Hardwareprodukts ist und unter Verantwortung des Herstellers betrieben wird, kann er als integraler Teil des PDE gewertet werden und unterliegt dann dem CRA.

Software-Updates und Patches

Updates für Produkte die bereits auf dem Markt sind, lösen grundsätzlich keine neue CRA-Compliance-Pflicht aus — es sei denn, die Änderung ist so wesentlich, dass das Produkt als neu in Verkehr gebracht gilt. Die genaue Definition von "wesentlicher Änderung" ist derzeit noch Gegenstand von Konkretisierungen durch die EU-Kommission.

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.

ADVISORI Betroffenheitsanalyse: Klarheit in 5 Werktagen

ADVISORI führt für Sie eine strukturierte CRA-Betroffenheitsanalyse durch. Das Ergebnis: eine klare Aussage darüber, welche Ihrer Produkte unter den CRA fallen, in welche Klasse sie einzuordnen sind und was bis wann zu tun ist.

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: Priorisierter Maßnahmenplan mit Zeitachse bis Dezember 2027

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 die bereits ab September 2026 gilt, 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?

Ja. Bluetooth ist eine Netzwerkverbindung im Sinne des CRA. Auch Produkte die nur lokal per Bluetooth kommunizieren, sind Produkte mit digitalen Elementen und fallen unter den Geltungsbereich — sofern keine Ausnahme nach Artikel 2 greift.

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

Sehr wahrscheinlich ja. Sobald eine kommerzielle Verbindung zur Software besteht — sei es durch Support, Hosting, Abonnements oder Integration in ein kostenpflichtiges Produkt — entfällt die OSS-Ausnahme. Die Software selbst wird dann als "in Verkehr gebracht" im Sinne des CRA betrachtet.

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

Händler müssen prüfen, ob das Produkt eine CE-Kennzeichnung trägt und keine erkennbaren Mängel hat. Wer ein Produkt jedoch unter eigenem Namen vermarktet oder wesentlich verändert, wird rechtlich zum Hersteller und trägt die volle Konformitätspflicht.

Ab wann muss ich die Betroffenheitsanalyse abgeschlossen haben?

Spätestens jetzt. Für die Meldepflicht ab September 2026 brauchen Sie bereits funktionierende Prozesse. Für die CE-Kennzeichnung bis Dezember 2027 benötigen je nach Produktkomplexität 12-24 Monate Umsetzungszeit. Wer im Frühjahr 2026 noch keine Analyse hat, gerät zeitlich unter Druck.

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

Unsicherheit über die eigene CRA-Betroffenheit ist keine Strategie. ADVISORI klärt Ihnen in einem strukturierten Workshop in weniger als einer Woche, ob und wie der CRA für Ihre Produkte gilt.

→ 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