Question 1

Fällt mein Produkt unter den CRA?

Accepted Answer

Der CRA gilt für nahezu alle Produkte mit digitalen Elementen, deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt. Ausgenommen sind Sektoren, für die bereits gleichwertige Cybersicherheitsregeln existieren:

• Medizinprodukte (Verordnung (EU) 2017/745 und 2017/746)
• Kraftfahrzeuge (Verordnung (EU) 2019/2144)
• Zivilluftfahrt (Verordnung (EU) 2018/1139)
• Schiffsausrüstung (Richtlinie 2014/90/EU)

Wichtig: Generische Komponenten, die sowohl in ausgenommenen als auch nicht-ausgenommenen Produkten eingesetzt werden können, unterliegen dennoch dem CRA.

(Art. 2(1), Art. 2(2))

Question 2

Ab wann müssen die CRA-Anforderungen erfüllt sein?

Accepted Answer

Die CRA-Anforderungen treten in zwei Stufen in Kraft:

1. Ab 11. September 2026: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten für alle Produkte, die sich bereits auf dem Markt befinden (Art. 14).
2. Ab 11. Dezember 2027: Die Verordnung wird vollständig anwendbar. Alle Produkte, die ab diesem Datum erstmals in Verkehr gebracht werden, müssen die gesamten CRA-Anforderungen erfüllen.

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen grundsätzlich nicht den Anforderungen — sofern keine wesentliche Veränderung vorgenommen wird.

(Art. 69, Art. 71(2), Art. 14)

Question 3

Ab wann gilt mein Softwareprodukt als „in Verkehr gebracht“ unter dem CRA?

Accepted Answer

Ein Softwareprodukt wird in den Verkehr gebracht, wenn seine Herstellungsphase abgeschlossen ist und es erstmals zur Verteilung oder Verwendung auf dem EU-Markt bereitgestellt wird. Der Hersteller bringt dabei eine praktisch unendliche Anzahl von Kopien gleichzeitig in den Verkehr. Nachfolgende Downloads derselben Version sind "Bereitstellen" - kein neues Inverkehrbringen.

Praxisbeispiel: Am 1. Januar 2028 stellt Unternehmen A Version 1.0.0 seiner Software bereit. Am 15. Januar wird Version 1.0.1 veröffentlicht (kein wesentliches Update). Beide Versionen gelten als am 1. Januar 2028 in den Verkehr gebracht - denn 1.0.1 war keine wesentliche Veränderung.

(Art. 3(21), Art. 3(22), Art. 3(30))

Question 4

Unterliegen Hardware und Software zusammen einer gemeinsamen CRA-Bewertung?

Accepted Answer

Ob Software Teil eines Produkts ist, wird nicht durch die Bereitstellungsart bestimmt, sondern ob sie für die beabsichtigte Funktion notwendig ist. Wenn Hardware mit spezifischer Software entworfen wurde, bilden sie ein einzelnes Produkt mit digitalen Elementen - auch wenn Treiber, Apps oder Firmware über verschiedene Kanäle bereitgestellt werden.

Praxisbeispiel: Ein Fitness-Wearable misst Herzfrequenz und Aktivität. Die zugehörige Smartphone-App zeigt Messwerte an und konfiguriert das Gerät. Obwohl die App separat aus dem App Store heruntergeladen wird, bilden Wearable und App ein einzelnes Produkt.

(Art. 3(1))

Question 5

Unterliegt Quellcode dem Anwendungsbereich der CRA?

Accepted Answer

Ob Code unkompiliert, kompiliert oder interpretiert ist, ist irrelevant. Wenn ein Hersteller Computercode als Teil seiner Geschäftstätigkeit bereitstellt, wird er als in den Verkehr gebracht betrachtet. Code in öffentlichen FOSS-Repositories, unvollendeter Entwicklungscode oder Demo-/Tutorial-Code gilt jedoch nicht als in den Verkehr gebracht.

Praxisbeispiel: Unternehmen A lizenziert Quellcode an Unternehmen B für eine interne Plattform. Unternehmen A ist verantwortlich für den lizenzierten Code. Spätere Anpassungen durch Unternehmen B liegen in dessen Verantwortung.

(Art. 3(4))

Question 6

Was stellt eine "Datenverbindung" gemäß CRA dar?

Accepted Answer

Eine Datenverbindung erfordert einen Sender, der absichtlich digitale Symbole erzeugt, und einen Empfänger, der diese als Daten interpretiert. Das bloße Ein-/Ausschalten einer Funktion ist keine Datenverbindung, wenn die Zustände nicht zur Darstellung von Daten vorgesehen sind.

Praxisbeispiel: Ein einfaches Thermostat mit bimetallischem Streifen hat keine Datenverbindung. Ein programmierbares Thermostat, das Temperaturvorgaben über ein digitales Busprotokoll (z.B. Modbus) an ein Gebäudeleitsystem kommuniziert, hat eine Datenverbindung und fällt unter den CRA.

(Art. 2(1))

Question 7

Wie wird die CRA auf komplexe Systeme mit mehreren Komponenten angewendet?

Accepted Answer

Komplexe Systeme aus mehreren Hardware- und Softwareelementen fallen unter den CRA, wenn sie als einzelnes Produkt in den Verkehr gebracht werden. Der risikobasierte Ansatz ermöglicht verschiedene Nachweismethoden. Wenn bestimmte Anforderungen nicht vollständig erfüllt werden können (z.B. Interoperabilität mit älteren Protokollen), müssen Hersteller Einschränkungen dokumentieren und Ausgleichsmaßnahmen implementieren.

Praxisbeispiel: Ein industrielles Gateway verbindet ältere OT-Netzwerke (Modbus TCP) mit modernen IT-Netzwerken. Das ältere Protokoll hat keine Verschlüsselung. Der Hersteller dokumentiert dies und implementiert Netzwerksegmentierung und Zugriffskontrolle als Ausgleichsmaßnahmen.

(Art. 13(2), Art. 13(3), Erwägungsgrund 55)

Question 8

Welche Rolle spielt die Zweckbestimmung (intended purpose) im CRA?

Accepted Answer

Die Zweckbestimmung ist eines der zentralen Konzepte des CRA und beeinflusst nahezu jede Compliance-Entscheidung:

• Anwendungsbereich: Ob ein Produkt unter den CRA fällt, hängt davon ab, ob seine Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung einschließt (Art. 2(1)).
• Risikobewertung: Die Cybersicherheits-Risikobewertung muss die Risiken unter Berücksichtigung der Zweckbestimmung und der vorhersehbaren Nutzungsbedingungen analysieren (Art. 13(2), Art. 13(3)).
• Produktklassifizierung: Ob ein Produkt als Standard, Wichtig oder Kritisch eingestuft wird, richtet sich nach der Kernfunktionalität — also dem, was das Produkt gemäß seiner Zweckbestimmung leistet (Art. 7(1)).
• Unterstützungszeitraum: Der Hersteller bestimmt den Unterstützungszeitraum anhand der erwarteten Nutzungsdauer, die sich aus der Zweckbestimmung ergibt (Art. 13(8)).
• Wesentliche Veränderung: Eine Änderung der Zweckbestimmung nach Inverkehrbringen gilt als wesentliche Veränderung und macht den Ändernden zum neuen Hersteller (Art. 3(30)).
• Datenminimierung: Das Produkt darf nur Daten verarbeiten, die für die Zweckbestimmung erforderlich sind (Anhang I Teil I Nr. 3(e)).

Die Zweckbestimmung muss in der technischen Dokumentation eindeutig definiert werden und durchzieht den gesamten Compliance-Prozess.

(Art. 2(1), Art. 3(30), Art. 7(1), Art. 13(2), Art. 13(8), Anhang I Teil I)

Question 9

Müssen ältere Produkte, die vor der CRA entworfen wurden, neu entworfen werden?

Accepted Answer

Nicht unbedingt. Der Hersteller muss eine Cybersecurity-Risikobewertung durchführen und nachweisen, dass das Produkt bereits angemessene Sicherheitsmaßnahmen einbezieht. Er muss jedoch die Konformitätsbewertung abschließen, die EU-Konformitätserklärung ausarbeiten, die CE-Kennzeichnung anbringen und die Anforderungen für den Umgang mit Schwachstellen erfüllen.

Praxisbeispiel: Ein 2024 entworfener Mikrocontroller zeigt in der Risikobewertung, dass er bereits sicheres Starten, verschlüsselte Firmware-Updates und rollenbasierte Zugriffskontrolle einschließt. Keine Neuentwicklung nötig - nur Dokumentation und Schwachstellenmanagement.

(Art. 13(2), Art. 13(3), Annex I)

Question 10

Wann wird FOSS unter der CRA als "in den Verkehr gebracht" betrachtet?

Accepted Answer

FOSS wird in den Verkehr gebracht, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Die CRA erkennt an, dass nicht-monetarisierte FOSS nicht als Geschäftstätigkeit gilt. Entscheidend ist, ob der Herausgeber: (a) einen Preis berechnet, (b) andere Dienste darüber monetarisiert, (c) Verarbeitung personenbezogener Daten über Sicherheitszwecke hinaus erfordert, oder (d) Spenden als Zugangsbedingung erhält.

Schlüsselkriterien: Quellcode muss offen geteilt sein (öffentlich verfügbar) und unter einer freien Open-Source-Lizenz stehen.

(Art. 3(48), Erwägungsgrund 15)

Question 11

Macht die Berechnung eines Preises FOSS zu einem CRA-Produkt?

Accepted Answer

Ja. Wenn der Anbieter einen Preis für die FOSS berechnet, bringt er ein Produkt in den Verkehr und ist Hersteller unter der CRA. Bezahlte und Community-Versionen sind unterschiedliche Produkte - die bezahlte Version wird in den Verkehr gebracht, die Community-Version nicht (sofern nicht anderweitig monetarisiert).

Praxisbeispiel: Ein Unternehmen bietet eine kostenlose Community-Edition und eine bezahlte Enterprise-Edition einer Open-Source-Datenbank an. Nur die Enterprise-Edition gilt als in den Verkehr gebracht.

(Art. 3(14), Art. 3(22), Erwägungsgrund 15)

Question 12

Löst die Monetarisierung anderer Dienste CRA-Verpflichtungen aus?

Accepted Answer

Ja. Eine FOSS gilt als in den Verkehr gebracht, wenn sie als Plattform dient, über die der Herausgeber andere Produkte oder Dienstleistungen monetarisiert, oder wenn die Nutzung die Verarbeitung personenbezogener Daten über Sicherheitszwecke hinaus voraussetzt.

Praxisbeispiel: Ein kostenloses Open-Source-VPN ermöglicht Benutzern, für zusätzliche Server oder dedizierte IPs zu bezahlen. Da die App andere Dienste monetarisiert, wird sie als im Rahmen einer Geschäftstätigkeit in den Verkehr gebracht betrachtet.

(Erwägungsgrund 15)

Question 13

Lösen Support-Dienstleistungen CRA-Verpflichtungen für FOSS aus?

Accepted Answer

Das bloße Anbieten optionaler Support-Dienste für frei verfügbare FOSS macht diese nicht zu einem CRA-Produkt. Entscheidend ist, ob der Zugang zur FOSS selbst an eine Vergütung geknüpft ist. Wenn die FOSS frei herunterladbar ist und Support separat gekauft werden kann, gilt sie nicht als in den Verkehr gebracht.

Praxisbeispiel: Ein kostenloses CLI-Tool mit optionalen Beratungsdiensten fällt nicht unter die CRA. Ein Betriebssystem mit kostenpflichtiger Version inklusive Support jedoch schon.

(Erwägungsgrund 15, Erwägungsgrund 18)

Question 14

Lösen Spenden CRA-Verpflichtungen für FOSS aus?

Accepted Answer

Freiwillige Spenden machen FOSS in der Regel nicht zu einem CRA-Produkt. Allerdings gilt FOSS als in den Verkehr gebracht, wenn Spenden de facto einem Preis entsprechen - z.B. wenn der Zugang an eine Spende geknüpft ist oder Spenden mit vertraglichen Vorteilen verbunden sind.

Praxisbeispiel: Ein FOSS-Tool mit "Buy me a coffee"-Link, bei dem alle Updates frei verfügbar sind, fällt nicht unter die CRA. Wenn jedoch herunterladbare Releases und Sicherheitsupdates nur für Spender verfügbar sind, gilt dies als Preisberechnung.

(Erwägungsgrund 15)

Question 15

Wie werden gemeinnützige Einrichtungen unter der CRA behandelt?

Accepted Answer

Wenn eine gemeinnützige Organisation alle Einnahmen nach Kosten für gemeinnützige Ziele verwendet, wird die FOSS, die sie veröffentlicht, nicht als in den Verkehr gebracht betrachtet - auch wenn sie monetarisiert wird. Erfüllt die Einrichtung die Definition eines Stewards, unterliegt sie Steward-Verpflichtungen gemäß Art. 24.

Praxisbeispiel: Eine Stiftung veröffentlicht einen Open-Source-Browser, der durch Suchmaschinen-Partnerschaften monetarisiert wird. Da alle Einnahmen für gemeinnützige Ziele verwendet werden, gilt der Browser nicht als in den Verkehr gebracht.

(Erwägungsgrund 18, Art. 3(14), Art. 24)

Question 16

Was ist ein Open-Source-Software-Verwalter (Steward)?

Accepted Answer

Ein Steward ist eine juristische Person (keine natürliche Person, kein Hersteller), die den Zweck hat, systematisch fortgesetzte Unterstützung für FOSS bereitzustellen, die für Geschäftsaktivitäten vorgesehen ist. Stewards unterliegen Verpflichtungen gemäß Art. 24. Eine juristische Person kann sowohl Hersteller für eine FOSS als auch Steward für eine andere sein.

Praxisbeispiel: Ein Technologieunternehmen veröffentlicht ein Open-Source-ML-Framework kostenlos und nutzt es intern. Andere Unternehmen integrieren es. Das Framework wird nicht als in den Verkehr gebracht betrachtet - das Unternehmen ist sein Steward.

(Art. 3(14), Art. 24)

Question 17

Wie behandelt die CRA integrierte FOSS-Komponenten (z.B. Embedded Linux)?

Accepted Answer

Wenn ein Hersteller FOSS-Komponenten in sein Produkt integriert (z.B. Embedded Linux), muss er Sorgfaltspflicht gemäß Art. 13(5) ausüben: integrierte FOSS-Komponenten identifizieren, deren Cybersecurity-Anforderungen bewerten und SBOMs (Software Bill of Materials) für alle integrierten Komponenten führen.

Praxisbeispiel: Ein industrielles Gateway nutzt eine Yocto-basierte Linux-Distribution. Der Linux-Kernel ist FOSS und nicht vom Hersteller als Produkt auf dem Markt gebracht. Der Hersteller muss dennoch alle FOSS-Komponenten identifizieren und bewerten.

(Art. 13(5))

Question 18

Was ist eine "wesentliche Veränderung" unter der CRA?

Accepted Answer

Eine wesentliche Veränderung ist eine Änderung an einem Produkt nach seinem Inverkehrbringen, die entweder: (a) die Einhaltung wesentlicher Cybersicherheitsanforderungen beeinflusst, oder (b) eine Änderung des beabsichtigten Zwecks ergibt. Die Person, die eine wesentliche Veränderung durchführt, wird zum Hersteller des geänderten Produkts.

(Art. 3(30), Erwägungsgrund 39)

Question 19

Stellen physikalische Reparaturen und Wartungen wesentliche Veränderungen dar?

Accepted Answer

Nicht unbedingt - eine Einzelfallbewertung ist notwendig. Das Ersetzen defekter Teile durch leistungsfähigere löst an sich keine wesentliche Veränderung aus. Nur wenn die Änderung die Einhaltung wesentlicher Anforderungen beeinflusst oder den beabsichtigten Zweck ändert.

Praxisbeispiel: Ein Server erhält neuen, leistungsfähigeren RAM als Ersatz. Der Server funktioniert besser, bleibt aber im beabsichtigten Nutzungsrahmen. Keine wesentliche Veränderung. Wenn der Austausch jedoch eine signifikante Verhaltensänderung bewirkt, die in der ursprünglichen Risikobewertung nicht berücksichtigt wurde, ist es eine wesentliche Veränderung.

(Art. 3(30), Erwägungsgrund 42)

Question 20

Wie werden Ersatzteile unter der CRA behandelt?

Accepted Answer

Identische Ersatzteile (gleiche Spezifikationen) sind von der CRA ausgenommen. Nicht-identische Ersatzteile sind eigenständige Produkte und unterliegen der CRA. Die Reparatur selbst stellt jedoch keine wesentliche Veränderung dar, wenn der beabsichtigte Zweck unverändert bleibt.

Praxisbeispiel: Ein Kommunikationsmodul eines industriellen Controllers fällt aus. Ein identisches Ersatzmodul ist gemäß Art. 2(6) ausgenommen. Ein neuerer Chip mit äquivalenter Funktionalität, aber anderer Gestaltung, ist jedoch ein separates CRA-Produkt - die Reparatur bleibt trotzdem keine wesentliche Veränderung.

(Art. 2(6))

Question 21

Wann stellen Software-Updates wesentliche Veränderungen dar?

Accepted Answer

Ob ein Software-Update eine wesentliche Veränderung ist, hängt davon ab, ob es die Einhaltung von Cybersicherheitsanforderungen beeinflusst oder den beabsichtigten Zweck ändert.

Beispiele FÜR wesentliche Veränderungen:
• Dashboard von schreibgeschützt zu operativer Kontrolle
• Informationsorganisierung zu automatisierter Entscheidungsfindung
• Hinzufügen von persistentem Login mit lokalen Tokens (neue Risiken)
• Entfernen lokaler Verschlüsselung zugunsten eines Remote-Dienstes
• Hinzufügen von Cloud-Synchronisierung (neue Angriffsfläche)

Beispiele OHNE wesentliche Veränderung:
• Gruppenchat, der bereits in der Risikobewertung geplant war
• Aktivierung vorher bewerteter, aber deaktivierter Funktionen
• Sicherheits-Patches und Bug-Fixes
• Verstärken bestehender Sicherheitskonfigurationen
• Aktualisierung eines Verschlüsselungsalgorithmus innerhalb eines konfigurierbaren Frameworks

(Art. 3(30), Erwägungsgrund 39)

Question 22

Wie lange muss ich Unterstützung für mein Produkt bereitstellen?

Accepted Answer

Mindestens 5 Jahre - es sei denn, das Produkt wird voraussichtlich weniger als 5 Jahre genutzt. Wichtig: 5 Jahre ist nicht der Standard. Produkte mit längerer erwarteter Nutzungsdauer müssen längere Unterstützungszeiträume haben. Das Enddatum (Monat/Jahr) muss zum Zeitpunkt des Kaufs angegeben werden.

Praxisbeispiel: Verbundene Industriesensoren mit erwarteter Lebensdauer von 10 Jahren in Fabrikumgebungen müssen einen 10-Jahres-Unterstützungszeitraum haben. Der Hersteller kann sich auf die neueste Firmware-Version konzentrieren, muss aber koordinierte Offenlegung für alle Versionen über den gesamten Zeitraum beibehalten.

(Art. 13(8), Art. 13(10), Annex I Part II)

Question 23

Was bestimmt, ob mein Produkt "wichtig" oder "kritisch" ist?

Accepted Answer

Die Klassifizierung hängt von der "Kernfunktionalität" ab - den Hauptmerkmalen, ohne die das Produkt seinen beabsichtigten Zweck nicht erfüllt. Wenn die Kernfunktionalität einer Kategorie in Annex III (wichtig) oder Annex IV (kritisch) entspricht, wird das Produkt entsprechend klassifiziert. Die bloße Integration einer wichtigen/kritischen Komponente macht das integrierende Produkt nicht automatisch wichtig/kritisch.

Praxisbeispiel: Ein Smartphone integriert ein Betriebssystem (wichtige Klasse). Die Kernfunktionalität des Smartphones ist jedoch Kommunikation und das Ausführen von Apps - nicht OS-Funktionalität. Das Smartphone wird nicht als "wichtig" klassifiziert, nur weil es ein OS enthält.

(Art. 7(1), Durchführungsverordnung (EU) 2025/2392)

Question 24

Wie funktioniert die Konformitätsbewertung für wichtige und kritische Produkte?

Accepted Answer

Standard-Produkte: Immer Selbstbewertung (Modul A) möglich.

Wichtige Klasse I: Drittpartei-Bewertung erforderlich, ES SEI DENN, vollständig relevante harmonisierte Standards angewendet wurden (im OJEU veröffentlicht), die mindestens die Kernfunktionalität abdecken.

Wichtige Klasse II & Kritisch: Obligatorische Drittpartei-Bewertung.

Ausnahme: FOSS-Produkte jeder Klasse können Standard-Kategorie-Verfahren folgen.

Praxisbeispiel: Ein Antivirus-Produkt wendet einen harmonisierten Standard an, der Kernfunktionalität und Zusatzfunktionen abdeckt - Selbstbewertung erlaubt. Ein Router mit harmonisiertem Standard für Router- und Firewall-Funktionalität - ebenfalls Selbstbewertung erlaubt.

(Art. 32, Durchführungsverordnung (EU) 2025/2392)

Question 25

Darf der Hersteller die Konformität selbst erklären?

Accepted Answer

Das hängt von der Produktkategorie ab:

• Standard-Produkte: Der Hersteller kann ein internes Kontrollverfahren (Modul A) durchführen und die Konformität selbst erklären.
• Wichtige Produkte (Klasse I): Selbstbewertung ist nur zulässig, wenn harmonisierte Normen oder europäische Zertifizierungsschemata vollumfänglich angewendet werden. Andernfalls ist eine Prüfung durch eine benannte Stelle (Notified Body) zwingend.
• Wichtige Produkte (Klasse II) und kritische Produkte: Eine Prüfung durch einen Notified Body ist immer verpflichtend.

Praxisbeispiel: Eine Smart-Home-Steckdose ohne Sicherheitsfunktion (Standard) kann per Selbstbewertung konform erklärt werden. Eine Firewall (Klasse II) erfordert zwingend einen Notified Body.

(Art. 32, Anhang VIII)

Question 26

Wie sollte ich eine Cybersecurity-Risikobewertung durchführen?

Accepted Answer

Unter der CRA wird Restrisiko gegen einen regulatorischen Schwellwert bewertet - nicht die interne Risikobereitschaft. Das Produkt muss ein angemessenes Cybersecurity-Niveau basierend auf Risiken gewährleisten, unter Berücksichtigung des beabsichtigten Zwecks und der vernünftigerweise vorhersehbaren Nutzung. Kostenüberlegungen oder kommerzielle Strategie sind dabei nicht relevant. Die CRA erlaubt keine Übertragung von Cybersecurity-Risiken an Benutzer.

(Art. 13(2), Art. 13(3), Annex I Part I)

Question 27

Wie wird Sorgfaltspflicht auf integrierte Komponenten angewendet?

Accepted Answer

Die CRA etabliert zwei ergänzende Verpflichtungen: (1) Cybersecurity-Risikobewertung für das Produkt selbst, und (2) Sorgfaltspflicht für integrierte Drittpartei-Komponenten. Der Hersteller muss identifizieren, was das Produkt von seinen Komponenten verlangt, überprüfen, dass Komponenten diese Anforderungen erfüllen, und sicherstellen, dass Komponenten die Einhaltung nicht untergraben.

Evidenz kann Komponenten-Dokumentation, Sicherheits-Spezifikationen oder Konformitäts-Dokumentation umfassen.

(Art. 13(5), Annex I Part I)

Question 28

Können wir eine Risikobewertung für mehrere Produktvarianten verwenden?

Accepted Answer

Ja. Wenn Produktvarianten dieselbe Architektur, sicherheitsrelevante Gestaltung und denselben beabsichtigten Zweck aufweisen, kann eine einzelne Risikobewertung verwendet werden. Variationen ohne Cybersecurity-Einfluss (Farbe, Form) erfordern keine separaten Bewertungen. Variationen mit Cybersecurity-Einfluss (verschiedene Schnittstellen, Update-Mechanismen) müssen dokumentiert werden.

(Art. 13(2), Annex I Part I)

Question 29

Was qualifiziert sich als Lösung zur Fernverarbeitung von Daten (RDPS)?

Accepted Answer

RDPS ist die Software-Komponente der Datenfernverarbeitung, die: (1) vom Hersteller entworfen und entwickelt oder unter dessen Verantwortung entwickelt wird, und (2) ohne die das Produkt eine seiner Funktionen nicht ausführen kann. RDPS umfasst nicht die zugrunde liegende Hardware-Infrastruktur. Interne Systeme (HR, CRM) sind keine RDPS.

Entscheidungsfragen: Ist die Verarbeitung entfernt? Würde das Produkt ohne sie eine Funktion verlieren? Wurde die Software vom Hersteller entwickelt? Wenn alle ja: RDPS.

(Art. 3(2), Art. 13(2))

Question 30

Wie beziehen sich Cloud-Service-Modelle auf RDPS?

Accepted Answer

IaaS: Die Software des Herstellers auf Drittpartei-Infrastruktur - Software kann RDPS sein, Infrastruktur nicht.

PaaS: Die Anwendung des Herstellers mit Drittpartei-Ausführungsumgebung - Anwendung kann RDPS sein, Plattform nicht.

SaaS: Vollständig von Drittpartei entwickelte Anwendung - NICHT RDPS (nicht vom Hersteller entworfen). Sollte als Drittpartei-Komponente behandelt werden; Sorgfaltspflicht erforderlich.

(Art. 3(2), Art. 13(2), Art. 13(5))

Question 31

Welche Praxisbeispiele gibt es zur Fernverarbeitung von Daten?

Accepted Answer

Banking-Anwendung: Banking API-Schicht (selbst gehostet, vom Finanzunternehmen entwickelt) - IST RDPS. Drittpartei-SaaS-Kundensupport-Chat - NICHT RDPS.

Smart Thermostat: Datenfernverarbeitung (vom Hersteller entwickelt, auf Drittpartei-IaaS) für Mobile App - IST RDPS.

e-Reader: Drittpartei-SaaS-Speicherdienst für Bücher - NICHT RDPS (nicht vom Hersteller entwickelt).

Industrieller Roboter: Kamera-Feed-Analyse auf Remote-Server (vom Hersteller entwickelt) - IST RDPS.

5G-Mobilfunknetz: Nur Kommunikationskanal - NICHT RDPS.

(EU-Kommission Guidance, Sections 8.3.1-8.3.5)

Question 32

Wann muss ich Schwachstellen und Vorfälle melden?

Accepted Answer

Ein Hersteller muss melden, wenn er nach einer initialen Bewertung angemessene Gewissheit hat, dass eine Schwachstelle aktiv ausgenutzt wird oder ein schwerwiegender Vorfall aufgetreten ist.

Meldungszeitplan:
• Frühwarnung: innerhalb von 24 Stunden
• 72-Stunden-Benachrichtigung: innerhalb von 72 Stunden
• Vollständiger Bericht: innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur (Schwachstellen) oder 1 Monat nach der 72-Stunden-Meldung (Vorfälle)

(Art. 14(1), Art. 14(3))

Question 33

Was sind die Verpflichtungen zum vorgelagerten Berichten von Schwachstellen?

Accepted Answer

Hersteller müssen Schwachstellen in integrierten Komponenten dem Komponenten-Hersteller oder -Wartungsperson berichten (vorgelagerter Bericht, Art. 13(6)). Dies gilt nur für die integrierte Version der Komponente. Hersteller müssen auch Sicherheits-Fixes in maschinenlesbarem Format teilen, kompatibel mit der Komponentenlizenz. Es gibt keine Verpflichtung, dass Fixes vom Wartungsperson akzeptiert werden.

(Art. 13(6))

Question 34

Was sind "bekannte ausnutzbare Schwachstellen"?

Accepted Answer

Eine ausnutzbare Schwachstelle hat das Potenzial, von einem Gegner unter praktischen Bedingungen effektiv ausgenutzt zu werden. Produkte müssen ohne bekannte ausnutzbare Schwachstellen in den Verkehr gebracht werden.

Eine Schwachstelle ist "bekannt", wenn sie:
• In öffentlichen Datenbanken gelistet ist (CVE, Europäische Schwachstellendatenbank)
• Dem Hersteller durch koordinierte Offenlegung mitgeteilt wurde
• In zuverlässigen Medien öffentlich berichtet wird

(Art. 3(37), Annex I Part II)

Question 35

Wer ist vom CRA betroffen (personeller Anwendungsbereich)?

Accepted Answer

Der CRA richtet sich an drei Gruppen von Wirtschaftsakteuren:

• Hersteller: Tragen die Hauptverantwortung für Design, Entwicklung, Produktion und Konformität des Produkts. Sie müssen die wesentlichen Cybersecurity-Anforderungen einhalten.
• Importeure: Müssen sicherstellen, dass nur konforme Produkte auf den EU-Markt gelangen. Sie prüfen, ob der Hersteller das Konformitätsbewertungsverfahren durchgeführt hat.
• Händler: Müssen mit angemessener Sorgfalt prüfen, ob CE-Kennzeichnung und Dokumentation vorliegen, bevor sie Produkte auf dem Markt bereitstellen.

(Art. 13, Art. 19, Art. 20, Art. 21)

Question 36

Was sind die wichtigsten Pflichten der Hersteller?

Accepted Answer

Hersteller müssen:

• Cybersecurity-Risikobewertung durchführen und dokumentieren (Art. 13(2))
• Produkt gemäß den wesentlichen Anforderungen in Anhang I entwerfen und entwickeln (Security by Design)
• Technische Dokumentation erstellen inkl. SBOM (Software Bill of Materials)
• Konformitätsbewertungsverfahren durchführen (Selbstbewertung oder Drittprüfung je nach Produktkategorie)
• EU-Konformitätserklärung erstellen und CE-Kennzeichnung anbringen
• Schwachstellen aktiv handhaben und Sicherheitsupdates bereitstellen (mindestens 5 Jahre)
• Aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA melden

(Art. 13, Anhang I, Anhang VII)

Question 37

Was sind die Pflichten der Importeure?

Accepted Answer

Importeure müssen vor dem Inverkehrbringen sicherstellen, dass:

• Der Hersteller das Konformitätsbewertungsverfahren durchgeführt hat
• Die technische Dokumentation erstellt wurde
• Das Produkt CE-gekennzeichnet ist
• Die EU-Konformitätserklärung vorliegt
• Kontaktdaten des Importeurs auf dem Produkt oder der Verpackung angegeben sind

Bei Verdacht auf Nichtkonformität dürfen Importeure das Produkt nicht in Verkehr bringen und müssen den Hersteller sowie die Marktüberwachungsbehörden informieren.

(Art. 19)

Question 38

Was sind die Pflichten der Händler?

Accepted Answer

Händler müssen mit angemessener Sorgfalt prüfen:

• Vorliegen der CE-Kennzeichnung
• Vorhandensein der EU-Konformitätserklärung
• Korrekte Angabe von Hersteller- und Importeurdaten
• Beachtung der Lagerungs- und Transportbedingungen

Bei Verdacht auf Nichtkonformität darf der Händler das Produkt nicht bereitstellen und muss die Marktüberwachungsbehörde informieren. Händler, die ein Produkt unter eigenem Namen in Verkehr bringen, gelten als Hersteller.

(Art. 20, Art. 21)

Question 39

Gilt der CRA bereits beim Einkauf von Komponenten oder erst beim Inverkehrbringen?

Accepted Answer

Entscheidend ist der Zeitpunkt, zu dem das fertige Produkt erstmals in Verkehr gebracht wird (Art. 3(21)) – nicht, wann einzelne Komponenten eingekauft wurden. Werden heute Komponenten mit digitalen Elementen beschafft, die in Produkte verbaut werden, die erst ab dem 11. Dezember 2027 in Verkehr gebracht werden, müssen diese Produkte bei Markteinführung CRA-konform sein.

Wichtig: CRA-Anforderungen sollten frühzeitig in den Einkaufsprozess integriert werden. Von Zulieferern sollten die nötigen Nachweise eingefordert werden – Informationen zum Vulnerability Handling (Anhang I Teil II), Sicherheitsupdates und Software-Stücklisten (SBOMs). Liefert ein Zulieferer diese Nachweise nicht, muss die Compliance eigenständig geprüft werden, was den Aufwand deutlich erhöht.

(Art. 13(1), Art. 71(2), Anhang I Teil II)

Question 40

Welche Sorgfaltspflichten gelten bei der Integration nicht CRA-konformer Drittkomponenten?

Accepted Answer

Werden Komponenten verbaut, für die kein CRA-Nachweis des Zulieferers vorliegt, verlagert sich die Prüfverantwortung vollständig auf den Hersteller des Endprodukts. Dabei gelten folgende Regeln:

• Gesamtverantwortung: Der Hersteller trägt die alleinige Verantwortung dafür, dass das Endprodukt in seiner Gesamtheit die grundlegenden Cybersicherheitsanforderungen erfüllt (Art. 13(1)).
• Sorgfaltspflicht (Due Diligence): Bei der Integration von Drittkomponenten muss die gebotene Sorgfalt walten. Wie in Erwägungsgrund 35 erläutert, gilt dies insbesondere für Komponenten, die vor dem Geltungsbeginn der Verordnung produziert wurden (Art. 13(5)).
• Dokumentation: Die Ergebnisse dieser Prüfungen müssen in die technische Dokumentation des Endprodukts aufgenommen werden (Anhang VII Punkt 3).
• Meldepflicht: Wird in einer Drittkomponente eine Schwachstelle festgestellt, ist der Hersteller verpflichtet, diese dem ursprünglichen Hersteller oder der Open-Source-Gemeinschaft zu melden und sie im eigenen Produkt zu beheben (Art. 13(6)).

(Art. 13(1), Art. 13(5), Art. 13(6), Erwägungsgrund 35, Anhang VII)

Question 41

Welche Produktausnahmen gibt es unter dem CRA?

Accepted Answer

Folgende Produkte sind vom CRA ausgenommen:

• Medizinprodukte (Verordnung (EU) 2017/745 und 2017/746)
• Kraftfahrzeuge (Verordnung (EU) 2019/2144) und L-Kategorie-Fahrzeuge (168/2013)
• Luftfahrtprodukte (Verordnung (EU) 2018/1139)
• Schiffsausrüstung (Richtlinie 2014/90/EU)
• Produkte für nationale Sicherheit oder Verteidigung
• Produkte zur Verarbeitung von Verschlusssachen

Wichtig: Generische Komponenten, die sowohl in ausgenommenen als auch nicht-ausgenommenen Produkten eingesetzt werden können, unterliegen dennoch dem CRA.

(Art. 2(2)-(6))

Question 42

Gibt es Ausnahmen für Bestandsprodukte (Altprodukte)?

Accepted Answer

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen grundsätzlich nicht den CRA-Anforderungen - sofern keine wesentliche Veränderung vorgenommen wird.

Aber: Ab 11. September 2026 gelten die Meldepflichten (Art. 14) für ALLE Produkte, die sich bereits auf dem Markt befinden. Hersteller müssen also spätestens dann aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden können.

Ein Software-Update, das eine wesentliche Veränderung darstellt, macht das Produkt zu einem neuen Produkt im Sinne des CRA.

(Art. 69, Art. 14, Erwägungsgrund 45)

Question 43

Betrifft der CRA bestehende Unternehmens-IT?

Accepted Answer

Der CRA gilt für Produkte mit digitalen Elementen, die im Rahmen einer Geschäftstätigkeit in Verkehr gebracht werden. Intern entwickelte Software, die ausschließlich für den eigenen Betrieb genutzt und nicht an Dritte weitergegeben wird, fällt nicht unter den CRA.

Wenn jedoch ein Unternehmen Software an Tochtergesellschaften, Partner oder Kunden weitergibt - auch unentgeltlich im Rahmen einer Geschäftsbeziehung - kann dies als Inverkehrbringen gelten.

Interne IT-Infrastruktur (Server, Netzwerke) fällt als solche nicht unter den CRA, wohl aber die darauf eingesetzten Produkte mit digitalen Elementen, wenn sie in Verkehr gebracht wurden.

(Art. 3(21), Art. 3(22), Erwägungsgrund 15)

Question 44

Gilt der CRA für eigenständige Software und Mobile Apps?

Accepted Answer

Ja. Der CRA gilt explizit für eigenständige Software (standalone software), die als Produkt mit digitalen Elementen in Verkehr gebracht wird. Dies umfasst:

• Desktop-Anwendungen
• Mobile Apps
• Firmware
• Betriebssysteme

Reine SaaS-Lösungen (ohne herunterladbare Komponenten) fallen nicht direkt unter den CRA, können aber als Remote Data Processing Service (RDPS) eines Produkts betroffen sein.

Software als Medizinprodukt (SaMD) unterliegt dagegen der Medizinprodukte-Verordnung und ist vom CRA ausgenommen.

(Art. 3(1), Art. 3(4), Erwägungsgrund 12)

Question 45

Welche Konsequenzen drohen bei Nichteinhaltung des CRA?

Accepted Answer

Der CRA sieht abgestufte Sanktionen vor:

• Verstoß gegen wesentliche Anforderungen (Anhang I & II): bis zu 15 Mio. EUR oder 2,5% des weltweiten Jahresumsatzes
• Verstoß gegen andere Verpflichtungen: bis zu 10 Mio. EUR oder 2% des Umsatzes
• Falsche/unvollständige Angaben gegenüber Behörden: bis zu 5 Mio. EUR oder 1% des Umsatzes

Darüber hinaus können Marktüberwachungsbehörden:
• Den Rückruf von Produkten anordnen
• Das Inverkehrbringen untersagen
• Die Vernichtung nicht-konformer Produkte verlangen

(Art. 64, Art. 54-58)

Question 46

Was sollten Unternehmen jetzt tun?

Accepted Answer

Empfohlene Maßnahmen zur CRA-Vorbereitung:

1. Bestandsaufnahme: Identifizieren Sie alle Produkte mit digitalen Elementen in Ihrem Portfolio
2. Produktklassifizierung: Prüfen Sie, ob Ihre Produkte als Standard, Wichtig (Klasse I/II) oder Kritisch eingestuft werden
3. Gap-Analyse: Vergleichen Sie Ihren aktuellen Stand mit den CRA-Anforderungen (Anhang I)
4. SBOM-Prozess: Etablieren Sie eine automatisierte Software-Stücklisten-Erstellung (CycloneDX/SPDX)
5. Schwachstellenmanagement: Implementieren Sie einen Prozess für kontinuierliche Schwachstellenüberwachung
6. Meldewege: Bereiten Sie die 24h/72h-Meldeinfrastruktur vor (spätestens bis September 2026)
7. Lieferantenverträge: Passen Sie Verträge an, um CRA-Anforderungen entlang der Lieferkette sicherzustellen
8. Dokumentation: Beginnen Sie mit der technischen Dokumentation gemäß Anhang VII

Kunnus unterstützt Sie bei all diesen Schritten mit einer All-in-One-Plattform.

Question 47

Wie passt der CRA in den EU-Rechtsrahmen (NIS-2, DORA, etc.)?

Accepted Answer

Der CRA ergänzt bestehende EU-Cybersecurity-Gesetzgebung:

• NIS-2-Richtlinie (2022/2555): Regelt die Cybersicherheit von Betreibern wesentlicher Dienste und Infrastrukturen. Der CRA konzentriert sich auf die Produkte selbst. NIS-2-pflichtige Unternehmen profitieren von CRA-konformen Produkten.
• DORA (2022/2554): Regelt die digitale Betriebsstabilität im Finanzsektor. CRA-konforme Produkte erleichtern die DORA-Compliance für Finanzunternehmen.
• Maschinenverordnung (2023/1230): Enthält eigene Cybersecurity-Anforderungen. Wo sich Anforderungen überschneiden, gilt: Erfüllung der CRA-Anforderungen bedeutet auch Erfüllung der Maschinenverordnung.
• Funkgeräterichtlinie (2014/53/EU): CRA-Konformität ersetzt die delegierten Rechtsakte zu Cybersecurity (Art. 3(3)(d)-(f)).

Der CRA verfolgt das Prinzip 'einmal konform, überall konform' - CRA-Compliance deckt Cybersecurity-Anforderungen anderer sektoraler Gesetzgebung weitgehend ab.

(Art. 8-11, Erwägungsgrund 24-32)

Question 48

Ist der CRA nur eine weitere Bürokratie- und Dokumentationspflicht?

Accepted Answer

Nein. Im Gegensatz zu reinen Managementsystem-Ansätzen (z. B. einem ISMS nach ISO 27001, das auf dem Papier exzellent, in der Realität aber wirkungslos sein kann) fordert der CRA tatsächliche Sicherheitsfähigkeiten im Produkt. Hersteller müssen konkret nachweisen: kostenlose Sicherheitsupdates, öffentliche Security Advisories, Incident Reporting, eine Richtlinie zur koordinierten Offenlegung. Dokumentation allein reicht nicht — Kunden, Wettbewerber und Sicherheitsforscher können Beschwerden wegen Nichtkonformität einreichen, und die Marktüberwachung prüft die reale Produktsicherheit.

(Art. 13, Anhang I Teil II)

Question 49

Macht der CRA Produkte teurer?

Accepted Answer

Der CRA schafft gleiche Wettbewerbsbedingungen. Bisher konnten Hersteller unsichere Produkte günstiger anbieten, weil Cybersicherheit optional war. Der CRA macht Sicherheit zum Standard und nimmt die billigere, unsichere Option vom Markt. Kurzfristig erfordert die Umstellung Investitionen, langfristig profitieren Hersteller und Kunden gleichermaßen: Die Folgekosten durch Sicherheitsvorfälle — Produktrückrufe, Reputationsschäden, Haftungsansprüche — sinken dramatisch.

(Erwägungsgrund 2, 10)

Question 50

Geht es beim CRA nur um Verschlüsselung?

Accepted Answer

Nein. Der CRA definiert 13 grundlegende Cybersicherheitsanforderungen in Anhang I Teil I. Verschlüsselung (Vertraulichkeit) ist nur eine davon. Dazu gehören u. a.: sichere Standardkonfiguration, Authentifizierung und Zugangskontrolle, Integritätsschutz für Daten und Software, Datenminimierung, Verfügbarkeit und Ausfallsicherheit, Härtung und Minimierung der Angriffsfläche, Logging und Monitoring. Dazu kommen die Anforderungen an die Schwachstellenbehandlung in Teil II (SBOM, Coordinated Disclosure, kostenlose Patches).

(Anhang I Teil I, Anhang I Teil II)

Question 51

Gilt der CRA nur für EU-Hersteller?

Accepted Answer

Nein. Der CRA gilt für alle Produkte mit digitalen Elementen, die auf dem EU-Binnenmarkt bereitgestellt werden — unabhängig vom Standort des Herstellers. US-amerikanische, asiatische und alle anderen nicht-EU-Hersteller müssen die Anforderungen erfüllen, wenn sie in der EU verkaufen wollen. In der Praxis wirkt der CRA als globaler Standard: Die meisten internationalen Hersteller werden keine separaten, weniger sichere Produktlinien für Nicht-EU-Märkte pflegen.

(Art. 2(1), Erwägungsgrund 15)

Question 52

Müssen alle 13 Anforderungen auf jedes Produkt angewendet werden?

Accepted Answer

Nein. Der CRA folgt einem risikobasierten Ansatz. Hersteller führen eine Cybersicherheits-Risikobewertung durch und bestimmen darauf basierend, welche der 13 grundlegenden Anforderungen auf ihr spezifisches Produkt anwendbar sind. Ein einfacher Temperatursensor hat andere Anforderungen als ein Router oder ein Passwort-Manager. Die Risikobewertung muss dokumentiert und während des gesamten Unterstützungszeitraums aktualisiert werden.

(Art. 13(2), Art. 13(3))

Question 53

Was genau umfasst die Schwachstellenbehandlung unter dem CRA?

Accepted Answer

Der CRA fordert in Anhang I Teil II einen vollständigen Schwachstellen-Lebenszyklus:

• Identifikation: Alle Schwachstellen systematisch identifizieren und dokumentieren, einschließlich in Drittkomponenten
• Testen: Regelmäßige und wirksame Tests der Produktsicherheit
• Behebung: Sicherheitsaktualisierungen ohne unnötige Verzögerung bereitstellen
• Offenlegung: Koordinierte Offenlegung (Coordinated Disclosure) mit klarer Richtlinie
• Kommunikation: Öffentliche Sicherheitshinweise (Security Advisories) bei behobenen Schwachstellen
• Transparenz: SBOM in maschinenlesbarem Format pflegen

Dieser Prozess muss während des gesamten Unterstützungszeitraums (mindestens 5 Jahre) aufrechterhalten werden.

(Anhang I Teil II, Art. 13(8))

Question 54

Welche Anforderungen stellt der CRA an die SBOM?

Accepted Answer

Der CRA verlangt eine Software-Stückliste (Software Bill of Materials) als Teil der technischen Dokumentation:

• Format: Maschinenlesbar, in einem gängigen Standard (z. B. CycloneDX, SPDX oder SWID)
• Umfang: Mindestens die Top-Level-Abhängigkeiten des Produkts
• Veröffentlichung: Nicht erforderlich — die SBOM muss aber auf Anfrage der Marktüberwachungsbehörden verfügbar sein
• Aktualität: Muss bei Änderungen am Produkt aktualisiert werden

Die SBOM ist kein Selbstzweck, sondern ermöglicht eine systematische Schwachstellenidentifikation über die gesamte Lieferkette.

(Anhang VII Nr. 2(b), Erwägungsgrund 78)

Question 55

Wie müssen Sicherheitsupdates bereitgestellt werden?

Accepted Answer

Der CRA stellt klare Anforderungen an die Bereitstellung von Sicherheitsaktualisierungen:

• Geschwindigkeit: Ohne unnötige Verzögerung nach Bekanntwerden einer Schwachstelle
• Kanal: Über einen sicheren und verlässlichen Verteilungskanal
• Kosten: Kostenlos für den Nutzer
• Automatisierung: Als automatische Updates mit benutzerfreundlichem Opt-out-Mechanismus
• Begleitung: Jedes Update muss von einer öffentlichen Sicherheitsmeldung (Security Advisory) begleitet werden
• Dauer: Für den gesamten Unterstützungszeitraum (mindestens 5 Jahre ab Inverkehrbringen)

Sicherheitsupdates müssen getrennt von funktionalen Updates bereitgestellt werden können.

(Anhang I Teil I Nr. 2(c), Anhang I Teil II Nr. 8)

Question 56

Was bedeutet Coordinated Disclosure unter dem CRA?

Accepted Answer

Der CRA verpflichtet jeden Hersteller, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) zu etablieren. Konkret bedeutet das:

• Eine öffentlich erreichbare Kontaktstelle für Schwachstellenmeldungen
• Ein dokumentierter Prozess für den Umgang mit gemeldeten Schwachstellen
• Zusammenarbeit mit dem meldenden Forscher/Entdecker
• Zeitnahe Behebung und abgestimmte Veröffentlichung
• Eintrag in die Europäische Schwachstellendatenbank (nach Behebung oder 90 Tage nach Meldung)

Unternehmen, die bereits ISO/IEC 29147 (Vulnerability Disclosure) oder ISO/IEC 30111 (Vulnerability Handling) umsetzen, haben eine gute Ausgangsbasis.

(Art. 13(6), Anhang I Teil II Nr. 5-6, Art. 16)

Question 57

Was gehört in die technische Dokumentation nach dem CRA?

Accepted Answer

Die technische Dokumentation muss gemäß Anhang VII alle Informationen enthalten, die zum Nachweis der CRA-Konformität erforderlich sind:

• Allgemeine Produktbeschreibung: Zweckbestimmung, Versionen, sicherheitsrelevante Hardwarekomponenten
• Software Bill of Materials (SBOM): In maschinenlesbarem Format, mindestens die Top-Level-Abhängigkeiten
• Cybersicherheits-Risikobewertung: Vollständige Dokumentation der identifizierten Risiken und getroffenen Maßnahmen
• Angaben zur Schwachstellenbehandlung: Prozesse, Kontaktstelle, Coordinated-Disclosure-Richtlinie
• Prüfberichte: Nachweis, dass die wesentlichen Anforderungen (Anhang I) erfüllt werden
• EU-Konformitätserklärung: Erklärung, dass alle anwendbaren Anforderungen eingehalten werden

Die Dokumentation muss während des Unterstützungszeitraums plus 10 Jahre aufbewahrt und der Marktüberwachungsbehörde auf Anfrage bereitgestellt werden.

(Anhang VII, Art. 31, Art. 13(12))

Question 58

Wie interagiert die CRA mit Fahrzeugregelungen?

Accepted Answer

Produkte, die der Verordnung (EU) 2019/2144 (Kraftfahrzeuge) oder Verordnung (EU) Nr. 168/2013 (L-Kategorie-Fahrzeuge) unterliegen, sind von der CRA ausgenommen. Komponenten, die ausschließlich für die Integration in solche Fahrzeuge entworfen wurden, sind auch ausgenommen. Generische Komponenten, die in verschiedene Produkttypen integriert werden können, unterliegen jedoch der CRA.

(Art. 2(5), Art. 2(6))

Question 59

Wie wirken sich bestehende EU-Typprüfungszertifikate auf die CRA aus?

Accepted Answer

EU-Typprüfungszertifikate, die unter anderer EU-Harmonisierungsgesetzgebung bezüglich Cybersecurity ausgestellt wurden (z.B. Funkgeräterichtlinie, Maschinenverordnung), bleiben bis 11. Juni 2028 gültig. Hersteller können sich auf diese für bereits abgedeckte Risiken verlassen, müssen aber eine umfassende CRA-Risikobewertung durchführen und alle zusätzlichen Risiken adressieren.

(Art. 13(2), Art. 13(3), Erwägungsgrund 66)

Cyber Resilience Act FAQ

Auf einen Blick: Die wichtigsten CRA-Fakten

Anwendungsbereich & Inverkehrbringen

Freie und Open-Source-Software (FOSS)

Wesentliche Veränderungen & Ersatzteile

Unterstützungszeitraum

Produktklassifizierung & Konformitätsbewertung

Cybersecurity-Risikobewertung

Fernverarbeitung von Daten (RDPS) & Cloud

Meldepflichten & Schwachstellenmanagement

Pflichten der Wirtschaftsakteure

Ausnahmen & Bestandsprodukte

Konsequenzen & Handlungsempfehlungen

Häufige Missverständnisse

Schwachstellenbehandlung im Detail

Zusammenspiel mit anderer Gesetzgebung

Rechtliche Quellen

Bereit für CRA-Compliance?