Cluster A · Grundverständnis

Bin ich vom CRA betroffen? Anwendungsbereich prüfen

Verfasst am
Lesezeit
6 Min. Lesezeit
Autor
Andrej Radkov · CRA-Compliance-Analyst
Hinweis: Diese Information ist eine indikative Einschätzung auf Basis der EU-Verordnung 2024/2847 und ersetzt keine Rechtsberatung. Bei rechtlichen Fragen wenden Sie sich bitte an einen spezialisierten Anwalt.

Was Sie wissen müssen

Finden Sie heraus, ob Ihr Produkt unter den CRA fällt. Entscheidungsbaum, Ausnahmen, Grenzfälle SaaS/Open Source — mit Quellenangaben zur EU-Verordnung.

Inhaltsverzeichnis
  1. Was ist ein „Produkt mit digitalen Elementen”?
  2. Entscheidungsbaum: Bin ich betroffen?
  3. Explizit ausgenommene Produktkategorien
  4. Grenzfälle: SaaS, reine Software, Open Source, B2B
  5. Reine Software-Anwendungen
  6. Software-as-a-Service (SaaS)
  7. Open-Source-Software
  8. B2B-Only-Produkte
  9. Produkte für den internen Eigengebrauch
  10. Häufige Missverständnisse
  11. Erster Schritt: Produktinventar
  12. Quellen

Was ist ein „Produkt mit digitalen Elementen”?

Geregelt wird das alles durch den Cyber Resilience Act (EU-Verordnung 2024/2847) — und der gilt für Produkte mit digitalen Elementen. Dieser Begriff ist zentral. Und bewusst weit gefasst.

Artikel 3 Nummer 1 der Verordnung definiert ein Produkt mit digitalen Elementen als:¹

„ein Software- oder Hardwareprodukt und seine Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die gesondert in Verkehr gebracht werden sollen, deren bestimmungsgemäße Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.”

Kurz gesagt: Vernetzt ist betroffen. Entscheidend ist nicht, ob Ihr Produkt technisch vernetzbar wäre — entscheidend ist, ob die Netzwerkverbindung zum bestimmungsgemäßen Einsatzzweck gehört. Was hier viele übersehen: Ein Produkt kann bewusst simpel wirken und trotzdem vollständig unter den CRA fallen.


Entscheidungsbaum: Bin ich betroffen?

Der folgende Entscheidungsbaum gibt eine erste Orientierung. Er ersetzt keine rechtliche Prüfung, eignet sich aber als schnellen Filter:

Frage 1: Hat Ihr Produkt eine digitale Komponente (Software, Firmware, Mikrocontroller) und kommuniziert es als Teil seiner bestimmungsgemäßen Verwendung mit einem Netzwerk, einem anderen Gerät oder dem Internet?

  • Nein → Wahrscheinlich nicht CRA-betroffen. (Analoges Produkt ohne Netzanbindung fällt nicht darunter.)
  • Unsicher → Weiter zu Frage 2.
  • Ja → Weiter zu Frage 2.

Frage 2: Bringen Sie dieses Produkt in der EU in Verkehr — also verkaufen, einführen oder bereitstellen Sie es auf dem EU-Markt?

  • Nein (ausschließlich außerhalb der EU) → Nicht CRA-betroffen.
  • Ja oder auch in der EU → Weiter zu Frage 3.

Frage 3: Fällt Ihr Produkt unter eine der expliziten Ausnahmen (Medizinprodukte, Fahrzeuge, Luftfahrt, reine nicht-kommerzielle Open-Source-Software)?

  • Ja → Sektorspezifisches Recht gilt statt CRA. Ausnahme prüfen.
  • Nein → CRA gilt für Ihr Produkt.

Explizit ausgenommene Produktkategorien

Artikel 2 Absatz 2 und 3 enthält eine abschließende Liste von Ausnahmen:¹

AusnahmeRegelwerkBegründung
MedizinprodukteEU-Verordnung 2017/745 (MDR), EU-Verordnung 2017/746 (IVDR)Eigene sektorspezifische Cybersicherheitsanforderungen
Kraftfahrzeuge und KomponentenUN-R 155 (Cybersicherheit), UN-R 156 (Software-Updates)Eigene internationale Regelung
Zivile LuftfahrtEU-Verordnung 2018/1139Eigenes Sicherheitsregime
Marine EquipmentRichtlinie 2014/90/EUEigenes sektorales Recht
Militär und nationale SicherheitStaatliche Hoheitsbereiche
Nicht-kommerzielle Open-Source-SoftwareKein Inverkehrbringen im rechtlichen Sinne

Wichtig: Diese Ausnahmen sind eng auszulegen. In der Praxis berufen sich Unternehmen immer wieder auf Sektorausnahmen, die schlicht nicht greifen. Eine bloße Verbindung zu einem der genannten Sektoren reicht nicht — das Produkt muss selbst unter das jeweilige Regelwerk fallen. Ein Softwareanbieter, der eine Monitoring-Lösung für Krankenhäuser verkauft, aber kein Medizinprodukt im Sinne der MDR ist, fällt nicht unter diese Ausnahme und bleibt CRA-pflichtig.


Grenzfälle: SaaS, reine Software, Open Source, B2B

Reine Software-Anwendungen

Auch reine Software — lokal installiert, kein Hardware-Anteil — kann unter den CRA fallen, sofern sie eigenständig in Verkehr gebracht wird und bestimmungsgemäß eine Netzwerkverbindung nutzt. Artikel 2 Absatz 1 der Verordnung nennt Software-Produkte ausdrücklich. Die Verbindung zum Netzwerk muss bestimmungsgemäß sein: Ein Texteditor ohne Netzwerkfunktion wäre nicht betroffen. Eine Projektmanagement-Software, die Cloud-Backups anlegt, Echtzeit-Kollaboration über das Netz ermöglicht oder Online-Updates lädt, dagegen schon.¹

Software-as-a-Service (SaaS)

SaaS ist der am stärksten diskutierte Grenzfall. Was viele CRA-Berater nicht sagen: Die Frage ist nicht „SaaS oder nicht SaaS”, sondern ob eine eigenständige Software-Komponente auf dem Endgerät des Nutzers existiert. In Erwägungsgrund 12 und 13 hat die Europäische Kommission klargestellt, dass Dienste, die ausschließlich in der Cloud laufen und keine eigenständige Software-Komponente auf dem Endgerät des Nutzers haben, vom CRA in der Regel nicht erfasst werden — sofern keine eigenständige Fernverarbeitungslösung vorliegt.

Aber: Umfasst eine SaaS-Lösung eine lokal installierte Client-Komponente (App, Agent, Plugin), die ihrerseits mit dem Netz kommuniziert, fällt diese Komponente unter den CRA. Ein Hersteller von industriellen MQTT-Gateways, die Sensordaten in die Cloud übertragen, fällt mit hoher Wahrscheinlichkeit unter Important Class I — unabhängig davon, wie klein das Unternehmen ist. Viele hybride Produkte (SaaS + lokaler Agent) sind damit betroffen.¹

Open-Source-Software

Was hier viele falsch verstehen: Die Open-Source-Ausnahme gilt nicht für Open Source allgemein, sondern nur für nicht-kommerzielle Entwicklung. Wer Open-Source-Software verkauft, Support dafür anbietet, als Cloud-Service betreibt oder in kommerzielle Produkte integriert, gilt als kommerzieller Akteur und unterliegt dem CRA.¹

Für Open-Source-Stewards (gemeinnützige Stiftungen und ähnliche Organisationen, die Open Source verwalten) sieht der CRA in Artikel 20 erleichterte Pflichten vor — aber keine vollständige Ausnahme.

B2B-Only-Produkte

Der CRA unterscheidet nicht zwischen B2B und B2C. Wer ausschließlich an Unternehmen verkauft, ist genauso betroffen wie wer an Verbraucher verkauft. Artikel 2 Absatz 1 spricht vom „Inverkehrbringen” auf dem EU-Markt — ohne Einschränkung auf die Art des Abnehmers.¹ Ein Maschinenbauunternehmen, das embedded Software für Heizungssteuerungen nur an Installationsbetriebe liefert, ist damit genauso in der Pflicht wie ein Consumer-IoT-Hersteller.

Produkte für den internen Eigengebrauch

Entwickelt ein Unternehmen ein vernetztes Produkt ausschließlich für den eigenen internen Gebrauch und bringt es nicht in Verkehr, fällt es nicht unter den CRA. Sobald es jedoch an Dritte — auch unentgeltlich — weitergegeben wird, gilt das Regelwerk.


Häufige Missverständnisse

Die meisten Missverständnisse entstehen nicht aus Unwissenheit, sondern aus Wunschdenken. Hier sind die häufigsten.

1. „Wir sind zu klein für den CRA”

Falsch. Der CRA kennt keine Größenschwelle. Auch ein Ein-Personen-Startup, das eine IoT-App verkauft, unterliegt dem Regelwerk. Kleinstunternehmen (unter 10 Mitarbeitende, unter 2 Mio. Euro Umsatz) können lediglich bei der technischen Dokumentation gewisse Vereinfachungen erhalten (Artikel 13 Absatz 14).¹ Das klingt nach wenig Entlastung. Ist es auch.

2. „Wir verkaufen nur an Unternehmen, nicht an Verbraucher”

Irrelevant. Der CRA gilt für alle Inverkehrbringer von Produkten mit digitalen Elementen — unabhängig vom Abnehmer. B2B schützt nicht vor dem CRA.

3. „Unser Produkt hat nur WLAN/Bluetooth — das ist kaum digital”

Doch. Jede logische oder physische Netzwerkverbindung reicht aus. Ein vernetzter Temperatursensor mit Bluetooth-Übertragung, der Messdaten an eine Smartphone-App überträgt, fällt genauso unter den CRA wie eine komplexe Firewall-Software. Die Einfachheit des Produkts schützt nicht vor der Pflicht.

4. „ISO 27001 erfüllt den CRA”

Nein. ISO 27001 ist ein Informationssicherheits-Managementsystem — es betrifft die Organisation, nicht das Produkt. Der CRA fordert produktspezifische Sicherheitsnachweise (Anhang I, Anhang VII). Mehr dazu unter CRA-Pflichten für Hersteller.

5. „Wir haben bereits CE — das reicht”

Nein. Bisherige CE-Kennzeichnungen (z. B. nach RED, Maschinenrichtlinie, LVD) decken keine CRA-Anforderungen ab. Der CRA erweitert das CE-System um Cybersicherheitsanforderungen — sie müssen zusätzlich nachgewiesen werden.

6. „Open Source ist sicher ausgenommen”

Nur nicht-kommerzielle Open-Source-Software ohne kommerziellen Kontext. Wer Open Source kommerziell vertreibt, supported oder in Produkte integriert, ist betroffen.


Erster Schritt: Produktinventar

Wer noch kein Produktinventar hat, weiß schlicht nicht, wie groß der tatsächliche Handlungsbedarf ist. Hersteller mit mehreren Produkten — etwa Industrie-4.0-Anbieter mit einer ganzen Familie vernetzter Steuerungskomponenten — sollten das jetzt angehen:

  1. Liste aller Produkte mit Netzwerkfunktion
  2. Je Produkt: Klärung ob EU-Markt betroffen
  3. Je Produkt: Klärung ob Ausnahme greift
  4. Je Produkt: Vorläufige Risikoklassifizierung

Diese Bestandsaufnahme ist Grundlage für alle weiteren Compliance-Maßnahmen. Bis Dezember 2027 klingt nach viel Zeit. Ist es nicht — besonders für IoT-Startups oder Industrie-4.0-Anbieter, die ihre Produktentwicklungsprozesse grundlegend anpassen müssen.

Die CRA-Fristen und weiteren Anforderungen finden Sie unter CRA-Fristen 2026 und 2027.

Starten Sie jetzt den kostenlosen CRA-Check — er führt Sie in wenigen Minuten durch die Kernfragen und gibt eine indikative Einschätzung, ob und in welche Klasse Ihr Produkt fällt.


Quellen

  1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Artikel 3, Artikel 13, Artikel 20, Erwägungsgründe 12, 13: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
  2. BSI — Cyber Resilience Act: Anwendungsbereich und Ausnahmen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
  3. EU-Kommission — CRA Factsheet: https://digital-strategy.ec.europa.eu/de/policies/cyber-resilience-act
  4. ENISA — CRA Guidance Documents: https://www.enisa.europa.eu/topics/cyber-resilience-act

Weiterlernen

Nächster Schritt

Wissen allein schützt nicht. Prüfen Sie jetzt, welche CRA-Klasse Ihr Produkt betrifft — kostenlos, in unter 3 Minuten.

Quellen-Hinweis: Dieser Artikel basiert auf der EU-Verordnung 2024/2847 (Cyber Resilience Act), veröffentlicht im Amtsblatt der Europäischen Union am 20. November 2024. Bei regulatorischen Aussagen wird jeweils der einschlägige Artikel angegeben. Stand der Informationen: 20. Mai 2026.

Kein Rechtsrat: Dieser Artikel stellt keine Rechtsberatung dar. Für verbindliche Einschätzungen konsultieren Sie bitte einen Fachanwalt für IT-Recht oder eine notifizierte Stelle.