Kapitel I - ALLGEMEINE BESTIMMUNGEN
2

Artikel 2

Anwendungsbereich

Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026

(1)

Diese Verordnung gilt für auf dem Markt bereitgestellte Produkte mit digitalen Elementen, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

(2)

Diese Verordnung gilt nicht für Produkte mit digitalen Elementen, auf die folgende Rechtsakte der Union Anwendung finden:

(3)

Diese Verordnung gilt nicht für Produkte mit digitalen Elementen, die nach der Verordnung (EU) 2018/1139 zertifiziert worden sind.

(4)

Diese Verordnung gilt nicht für Geräte, die in den Anwendungsbereich der Richtlinie 2014/90/EU des Europäischen Parlaments und des Rates (36) fallen.

(5)

Die Anwendung dieser Verordnung auf Produkte mit digitalen Elementen, die unter andere Rechtsvorschriften der Union mit Anforderungen für alle oder einige der von den grundlegenden Cybersicherheitsanforderungen in Anhang I abgedeckten Risiken fallen, kann eingeschränkt oder ausgeschlossen werden, wenn

a)

eine solche Einschränkung oder ein solcher Ausschluss mit dem für diese Produkte geltenden allgemeinen Rechtsrahmen vereinbar ist und

b)

mit den sektorspezifischen Vorschriften dasselbe Schutzniveau erreicht wird, wie es diese Verordnung gewährleistet, oder ein höheres. Der Kommission wird die Befugnis übertragen, gemäß Artikel 61 zur Ergänzung dieser Verordnung delegierte Rechtsakte zu erlassen, in denen sie die Notwendigkeit einer solchen Einschränkung oder eines solchen Ausschlusses feststellt und gegebenenfalls die betreffenden Produkte und Vorschriften sowie den Umfang der Einschränkung festlegt.

(6)

Diese Verordnung gilt nicht für Ersatzteile, die auf dem Markt bereitgestellt werden, um identische Komponenten in Produkten mit digitalen Elementen zu ersetzen, und die nach denselben Spezifikationen hergestellt werden wie die Bauteile, die sie ersetzen sollen.

(7)

Diese Verordnung gilt nicht für Produkte mit digitalen Elementen, die ausschließlich für Zwecke der nationalen Sicherheit oder für Verteidigungszwecke entwickelt oder geändert wurden, und auch nicht für Produkte, die speziell für die Verarbeitung von Verschlusssachen konzipiert sind.

(8)

Die in dieser Verordnung festgelegten Verpflichtungen umfassen nicht die Bereitstellung von Informationen, deren Offenlegung wesentlichen Interessen der Mitgliedstaaten im Bereich der nationalen Sicherheit, der öffentlichen Sicherheit oder der Verteidigung zuwiderlaufen würde.

Auslegung der EU-Kommission

Guidance vom 27. Juli 2026

Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.

Abschnitt 2.1Inverkehrbringen von Standalone-Software

Standalone-Software gilt als in Verkehr gebracht, sobald die Herstellungsphase abgeschlossen ist und die Software erstmals zum Vertrieb oder zur Nutzung auf dem EU-Markt angeboten wird. Alle Kopien derselben Version gelten als zum selben Zeitpunkt in Verkehr gebracht — unabhängig davon, wann einzelne Nutzer sie herunterladen.

Kernaussagen

  • Der Zeitpunkt des ersten Angebots zählt für alle Kopien einer Version — spätere Downloads sind nur ein „Bereitstellen auf dem Markt“ derselben Produkte.
  • Iterationen ohne wesentliche Änderung verschieben das Datum des Inverkehrbringens nicht; erst eine wesentliche Änderung gilt als neues Inverkehrbringen (vgl. Kapitel 4 der Leitlinien).
  • Varianten mit unterschiedlichen Komponenten, Konfigurationen oder Funktionsumfängen (z. B. Builds je Betriebssystem, unterschiedliche Feature-Bundles) sind eigenständige Produkte.

Beispiel aus der Guidance

Version 1.0.0 wird am 1. Januar 2028 erstmals über die Website angeboten. Kunde 1 kauft am selben Tag, Kunde 2 am 15. Januar. Beide Kopien gelten als am 1. Januar 2028 in Verkehr gebracht (Beispiel 1 der Leitlinien).

Für die Praxis

Halten Sie pro Software-Version das Datum des ersten Angebots fest — es bestimmt, ab wann die CRA-Pflichten für alle Kopien dieser Version laufen. Führen Sie außerdem eine Liste Ihrer Varianten (Builds je Betriebssystem, Feature-Bundles): Jede Variante ist ein eigenes Produkt mit eigenem Datum.

Abschnitt im Guidance-Überblick
Abschnitt 2.2Software als Produkt — Web-Apps und Websites

Software ist nur dann ein Produkt mit digitalen Elementen, wenn sie dem Nutzer bereitgestellt und auf dessen System ausgeführt wird. Web-Apps, die ausschließlich über den Browser genutzt werden, und reine Informations-Websites sind selbst keine Produkte — sie fallen nur als Remote Data Processing in den Scope, wenn sie eine Funktion eines Produkts unterstützen.

Kernaussagen

  • Lokal installierte Anwendungen sind Produkte — auch Browser-Extensions und mit Web-Technologien gebaute Desktop-Apps, die lokal ausgeführt werden.
  • Web-Apps und Progressive Web Apps, die nur im Browser laufen, sind keine Produkte mit digitalen Elementen (Erwägungsgründe 11 und 12).
  • Ein lokal installierter Client plus die Datenverarbeitung „at a distance“, auf die er für seine Funktionen angewiesen ist, bilden zusammen das Produkt.

Für die Praxis

Sortieren Sie Ihr Portfolio in drei Körbe: (1) läuft lokal beim Nutzer (App, Desktop-Client, Browser-Extension) → Produkt im CRA-Sinn; (2) reine Browser-Anwendung oder Info-Website → kein Produkt; (3) Backend, das eine Produktfunktion trägt → als Remote Data Processing prüfen (Kapitel 8 der Leitlinien).

Abschnitt im Guidance-Überblick
Abschnitt 2.5Datenverbindung — Abgrenzung zu bloßer Elektronik

Der CRA-Scope knüpft an eine Datenverbindung an, nicht an das bloße Vorhandensein von Elektronik. Eine Datenverbindung setzt voraus, dass binäre Zustände von einem Sender bewusst als Information codiert und vom Empfänger als Daten decodiert werden können. Elektrische Signale, die nur eine Funktion auslösen oder mit Strom versorgen, begründen keinen CRA-Scope.

Kernaussagen

  • Bloßes Ein-/Ausschalten eines Ausgangs (0/1) ist keine Datenverbindung, wenn die Zustände keine Information repräsentieren sollen.
  • Erforderlich: ein Sender, der digitale Symbole nach einem definierten Schema erzeugt, und ein Empfänger, der sie als Daten interpretieren kann.
  • Die Grenze trennt Produkte, die an digitaler Kommunikation teilnehmen (und Cyberrisiken ausgesetzt sind), von rein elektrisch angesteuerten Produkten.

Für die Praxis

Stellen Sie je Produkt eine einzige Frage: Sendet oder empfängt es bewusst codierte Daten (Protokoll, Bus, Funk, serielle Schnittstelle)? Nur dann ist es im CRA-Scope. Produkte, die Signale nur schalten oder Strom führen, können Sie mit dieser Begründung dokumentiert aussteuern.

Abschnitt im Guidance-Überblick
Abschnitt 3.1 – 3.2Open Source: Wann ist FOSS „in Verkehr gebracht“?

Entscheidend ist die Monetarisierung durch den Verantwortlichen (Maintainer), nicht die Finanzierung der Entwicklung: Preis für Binaries, Monetarisierung anderer Dienste über die Software, verpflichtende Datenverarbeitung oder kostenpflichtige Versionen mit Support-Vorteilen bedeuten Inverkehrbringen. Freiwillige Donations, optionale Beratung und Dritt-Sponsoring lösen für sich genommen keinen CRA-Scope aus.

Kernaussagen

  • FOSS-Definition (Art. 3 Nr. 48) verlangt kumulativ eine FOSS-Lizenz mit allen Rechten und öffentlich geteilten Quellcode — Code nur für zahlende Kunden ist kein FOSS.
  • Verantwortlich ist, wer Releases, Roadmap und Distribution kontrolliert; Contributors ohne diese Kontrolle unterliegen dem CRA nicht, selbst mit Commit-Rechten (Beispiel 13).
  • Community-Version und kostenpflichtige (Open-Core-)Version sind zwei verschiedene Produkte — die kostenlose Version bleibt außerhalb des Markts.
  • Optionale bezahlte Services (Consulting, Training, Deployment-Hilfe) sind unschädlich; kostenpflichtiger Zugang zu einer Version mit technischem Support ist dagegen Monetarisierung (Beispiele 17/18).
  • Donations sind erst kritisch, wenn sie de facto Zugangsbedingung sind — etwa Releases oder Security-Fixes nur für Spender (Beispiele 21/22); Kostendeckung inkl. angemessener Lebenshaltungskosten ist zulässig.
  • Dritt-Finanzierung (Grants, Bug Bounties, bezahlte Feature-Entwicklung) macht FOSS nicht kommerziell (Erwägungsgrund 18, Beispiel 23).

Für die Praxis

Gehen Sie Ihre Open-Source-Projekte einzeln durch und beantworten Sie zwei Fragen: Kontrollieren wir Releases und Distribution? Und verdienen wir an genau dieser Version (Preis, Monetarisierung über die Software, Pflicht-Datenverarbeitung, Bezahlversion mit Support)? Nur bei zweimal Ja sind Sie Hersteller. Donations-Link, Sponsoring und optionale Beratung ändern daran nichts.

Abschnitt im Guidance-Überblick
Abschnitt 4.1 – 4.2Reparaturen und Ersatzteile

Reparatur, Refurbishment und Wartung sind in der Regel keine wesentliche Änderung, solange Zweckbestimmung und Risikoniveau unverändert bleiben. Die Ersatzteil-Ausnahme (Art. 2 Abs. 6) greift nur, wenn das Teil erkennbar zur Reparatur eines bestehenden Produkts geliefert wird; „identisch“ bemisst sich an den sicherheitsrelevanten Eigenschaften, nicht an Bauteilgleichheit.

Kernaussagen

  • Austausch eines defekten Teils gegen ein besser performendes ist für sich keine wesentliche Änderung (Beispiel 35: schnellerer RAM im Server).
  • Neuer Chipsatz mit gleichen Protokollen und Sicherheitsmechanismen kann „identisch“ sein (Beispiel 38); geänderte Krypto-Implementierung oder Secure-Boot-Mechanismus dagegen nicht (Beispiel 37).
  • Der Reparaturzweck muss aus dem Lieferkontext hervorgehen (Produktbezug in Bestellung/Angebot, After-Sales-Kanal) — Nachweise für die Marktüberwachung vorhalten.
  • Die Ausnahme gilt auch für den Austausch ganzer Module oder Teilprodukte innerhalb größerer Systeme (Beispiel 39: CPU-Einheit oder komplette SPS).

Für die Praxis

Dokumentieren Sie bei jedem Ersatzteil den Reparaturbezug (Produkt in Bestellung/Angebot benannt, Lieferung über After-Sales-Kanal) und vergleichen Sie sicherheitsrelevante Eigenschaften — Krypto, Protokolle, Secure Boot, Zugriffskontrollen — statt Bauteilnummern. Nur so können Sie die Art.-2-Abs.-6-Ausnahme gegenüber der Marktüberwachung belegen.

Abschnitt im Guidance-Überblick
Abschnitt 8.1Was zählt als Remote Data Processing Solution (RDPS)?

Remote-Datenverarbeitung ist Teil des Produkts, wenn drei Kriterien kumulativ erfüllt sind: Verarbeitung „at a distance“, Funktionsnotwendigkeit (ohne sie könnte das Produkt eine Funktion nicht erfüllen) und Entwicklung durch den Hersteller oder unter seiner Verantwortung. Die Leitlinien übersetzen das in zwei Prüffragen mit Entscheidungsbaum.

Kernaussagen

  • „Wer betreibt“ ist unerheblich: On-Premises- oder Private-Cloud-Lösungen können genauso RDPS sein wie Public-Cloud-Lösungen.
  • „Funktionen“ meint mehr als Kernfunktionalität: auch Onboarding, Datei-Sync, Konfiguration, automatische Update-Verteilung und Identity/Access Management zählen.
  • Telemetrie rein für Statistik oder Produktentwicklung ist kein RDPS — die Risiken solcher Remote-Komponenten gehören aber trotzdem in die Risikobewertung.
  • IaaS/PaaS: Läuft die eigene (oder beauftragte) Software auf fremder Infrastruktur, kann sie RDPS sein; Standard-SaaS von Dritten ist kein RDPS, wird aber wie eine Dritt-Komponente behandelt (Risiken mitigieren + Due Diligence).
  • „Unter Verantwortung des Herstellers“ = maßgeschneidert für den Hersteller nach dessen Designs/Spezifikationen — nicht das bloße Lizenzieren eines bestehenden Dienstes.
  • Interne Systeme (HR, CRM, CI/CD-Pipelines, Update-Verteilung an Edge-Standorte, Pentest-/Red-Team-Infrastruktur) sind kein RDPS.
  • Websites nur bei Funktionsbeitrag: ein Auth-Portal, das Tokens für das Produkt ausstellt, kann RDPS sein — eine Info-Website nicht, selbst wenn das Produkt auf sie verlinkt.

Für die Praxis

Beantworten Sie je Cloud-/Backend-Dienst zwei Fragen: (1) Fällt ohne ihn eine Produktfunktion aus (auch Onboarding, Sync, Updates, Login)? (2) Wurde die Software von uns oder nach unseren Vorgaben entwickelt? Zweimal Ja → Teil Ihres Produkts, gehört in Risikobewertung und Konformitätsbewertung. Nur Frage 1 Ja (z. B. Standard-SaaS) → wie Dritt-Komponente behandeln: Risiken mitigieren plus Due Diligence.

Abschnitt im Guidance-Überblick
Abschnitt 9.3Zusammenspiel mit anderem EU-Recht: Fahrzeuge, RED, Maschinenverordnung

Fahrzeug-Komponenten (VO (EU) 2019/2144, VO (EU) Nr. 168/2013) sind vom CRA ausgenommen, wenn sie ausschließlich für die Integration in solche Fahrzeuge bestimmt und geeignet sind — generische Komponenten über offene Vertriebskanäle fallen in den CRA, unabhängig von Intended-Use-Erklärungen. EU-Baumusterprüfbescheinigungen zu Cybersicherheitsanforderungen (z. B. RED Delegated Act, Maschinenverordnung) bleiben bis längstens 11. Juni 2028 als Konformitätsnachweis für die abgedeckten Risiken nutzbar.

Kernaussagen

  • Maßgeblich sind die objektiven Vertriebsbedingungen: Verkauf über allgemeine Retail-/Online-Kanäle an die Öffentlichkeit spricht gegen die Fahrzeug-Ausnahme; geschlossene B2B-Kanäle der Automobil-Lieferkette dafür.
  • Bestehende Zertifikate (RED DA, Maschinenverordnung Anhang III 1.1.9/1.2.1) ersetzen die CRA-Risikobewertung nicht — sie dienen nur als Nachweis für die dort abgedeckten Risiken.
  • Vom Zertifikat nicht abgedeckte CRA-Risiken (z. B. Schwachstellenbehandlungsprozesse, Datenminimierung, Angriffsflächenreduktion) sind zusätzlich zu adressieren.

Für die Praxis

Prüfen Sie Ihre Vertriebskanäle: Komponenten, die auch außerhalb der Automobil-Lieferkette verkauft werden (Retail, offener Online-Shop), fallen in den CRA — unabhängig davon, was im Datenblatt zur Zweckbestimmung steht. Inventarisieren Sie außerdem Ihre RED-/Maschinenverordnungs-Zertifikate: Sie gelten als CRA-Nachweis nur für die abgedeckten Risiken und längstens bis 11. Juni 2028 — planen Sie die Lückenschließung jetzt.

Abschnitt im Guidance-Überblick
Alle Guidance-Kapitel im Überblick

EU-Kommissions-Guidance (C(2026) 5252 final)Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.

Verwandte Erwägungsgründe

(14)

CRA-Updates per E-Mail

Fristen, Guidance und Mythos-Faktenchecks rund um den Cyber Resilience Act — kompakt im Newsletter.

Newsletter ansehen

Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex