Cyber Resilience Act (CRA) Fragen & Antworten

Der Cyber Resilience Act ist die EU-Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Er legt Anforderungen an die Cybersicherheit von Produkten und an den Umgang mit Schwachstellen über den Unterstützungszeitraum fest.

Der CRA soll Sicherheitsrisiken digitaler Produkte reduzieren, grundlegende Cybersicherheitsanforderungen vereinheitlichen und Transparenz für Nutzer verbessern. Hersteller müssen Sicherheit bei Entwicklung, Bereitstellung und Schwachstellenbehandlung berücksichtigen.

Grundsätzlich für Hardware- und Softwareprodukte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst, sofern keine einschlägige Ausnahme greift.

Ja. Auch eigenständig bereitgestellte Software ist ein Produkt mit digitalen Elementen. Entscheidend sind die rechtliche Produktdefinition, die Bereitstellung auf dem EU-Markt und mögliche Ausnahmen.

Reine SaaS-Dienste sind nicht automatisch eigenständige Produkte mit digitalen Elementen im Sinne des CRA. Eine entfernte Datenverarbeitungslösung kann aber Teil eines Produkts sein, wenn sie vom Hersteller konzipiert oder unter seiner Verantwortung entwickelt wurde und für eine Produktfunktion erforderlich ist.

Ja. Firmware, Steuergeräte, vernetzte Sensoren und andere eingebettete digitale Komponenten fallen unter den CRA, sobald sie eine Datenverbindung haben und auf dem EU-Markt bereitgestellt werden.

Eine Internetverbindung ist nicht zwingend erforderlich. Auch andere direkte oder indirekte Datenverbindungen zu Geräten oder Netzwerken eröffnen den Anwendungsbereich, etwa USB, Bluetooth, CAN oder serielle Schnittstellen.

Ja. Der CRA erfasst sowohl B2B- als auch B2C-Produkte. Ein ausschließlicher Verkauf an Geschäftskunden begründet keine allgemeine Ausnahme.

Ausgenommen sind Produkte, für die sektorale EU-Vorschriften mit eigenen Cybersicherheitsanforderungen gelten: Medizinprodukte nach MDR und IVDR, Fahrzeuge und Komponenten im Anwendungsbereich der Typgenehmigung nach Verordnung (EU) 2019/2144, Luftfahrtprodukte nach Verordnung (EU) 2018/1139 und Schiffsausrüstung. Ebenfalls ausgenommen sind Produkte ausschließlich für Verteidigung oder nationale Sicherheit sowie Ersatzteile, die identische Komponenten nach denselben Spezifikationen ersetzen.

Ja. Wer ein erfasstes Produkt auf dem EU-Markt bereitstellt, muss die jeweils einschlägigen CRA-Pflichten erfüllen. Hersteller außerhalb der EU sind daher ebenfalls betroffen, wenn ihre Produkte in der EU vermarktet werden.

Fahrzeuge und Komponenten, für die Cybersicherheitsanforderungen im Rahmen der Typgenehmigung nach Verordnung (EU) 2019/2144 gelten (UNECE R155 und R156), sind vom CRA ausgenommen. Die Ausnahme reicht genau so weit wie die Typgenehmigung. Produkte eines Zulieferers, die außerhalb der Typgenehmigung auf den Markt kommen, etwa Diagnosewerkzeuge, Nachrüstlösungen, Flottentelematik, Ladeinfrastruktur oder dieselbe Steuergeräteplattform für Industrie- oder Marineanwendungen, fallen unter den CRA.

Ja. Ladestationen, Wallboxen und deren Steuerungs- und Kommunikationskomponenten sind keine Fahrzeuge und fallen nicht unter die Typgenehmigung. Sie sind Produkte mit digitalen Elementen und müssen die CRA-Anforderungen erfüllen. Daneben gelten weiterhin die sektoralen Vorgaben, etwa aus der AFIR und dem Messrecht.

Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten. Die meisten materiellen Produktpflichten gelten jedoch erst ab dem 11. Dezember 2027.

Die zentralen Anforderungen an Produkte mit digitalen Elementen und die wesentlichen Herstellerpflichten gelten ab dem 11. Dezember 2027.

Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026. Unternehmen sollten ihre Prozesse zur Erkennung, Bewertung und Meldung bereits eingerichtet haben.

Ab dem 11. Juni 2026 gilt Kapitel IV der Verordnung, also die Vorschriften über notifizierende Behörden und die Notifizierung von Konformitätsbewertungsstellen. Damit können sich Prüfstellen für CRA-Verfahren akkreditieren und notifizieren lassen. Die Marktüberwachung selbst beginnt erst mit der vollen Anwendung im Dezember 2027.

Für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gelten die allgemeinen CRA-Anforderungen nach den Übergangsregeln erst, wenn sie ab diesem Datum wesentlich geändert werden. Die Meldepflichten nach Artikel 14 gelten dagegen seit dem 11. September 2026 auch für zuvor auf dem EU-Markt bereitgestellte erfasste Produkte. Für konkrete Produktversionen ist der Zeitpunkt des Inverkehrbringens zu dokumentieren.

Inverkehrbringen ist die erstmalige Bereitstellung eines konkreten Produkts mit digitalen Elementen auf dem EU-Markt. Der Zeitpunkt ist wichtig für die Frage, welche Pflichten und Übergangsregeln gelten.

Eine wesentliche Änderung liegt vor, wenn eine nach dem Inverkehrbringen vorgenommene Änderung die Einhaltung der grundlegenden Cybersicherheitsanforderungen beeinflusst oder den bestimmungsgemäßen Verwendungszweck verändert. Nicht jedes Sicherheitsupdate ist automatisch eine wesentliche Änderung; maßgeblich sind die Definition und die Umstände des Einzelfalls.

Nein. Produktklassifizierung, Risikobewertung, sichere Entwicklung, technische Dokumentation, Schwachstellenmanagement und bei wichtigen Produkten die externe Konformitätsbewertung benötigen Vorlauf. Die Meldepflichten gelten bereits seit September 2026.

Der CRA unterscheidet insbesondere Hersteller, Bevollmächtigte, Importeure und Händler. Die Pflichten richten sich nach der jeweiligen Rolle und den tatsächlichen Tätigkeiten.

Hersteller ist unter anderem, wer ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet. Auch eine wesentliche Änderung eines Fremdprodukts oder dessen Vertrieb unter eigener Marke löst Herstellerpflichten aus.

Die Unternehmensleitung muss organisatorisch sicherstellen, dass gesetzliche Pflichten eingehalten werden. Dazu gehören angemessene Ressourcen, klare Verantwortlichkeiten, wirksame Kontrollen und nachvollziehbare Entscheidungen.

Ein Bevollmächtigter übernimmt die im schriftlichen Mandat festgelegten Aufgaben innerhalb der gesetzlichen Grenzen. Die grundlegende Verantwortung des Herstellers für die Produktkonformität wird dadurch nicht vollständig übertragen.

Nein. Der CRA verpflichtet Drittstaatenhersteller nicht generell zur Bestellung eines Bevollmächtigten. Ein freiwillig schriftlich mandatierter Bevollmächtigter hat nur die ihm rechtlich übertragbaren Aufgaben. Importeurspflichten sind hiervon getrennt und ersetzen die Herstellerverantwortung nicht.

Importeure müssen unter anderem prüfen, dass die erforderliche Konformitätsbewertung durchgeführt wurde, technische Unterlagen und Kennzeichnungen vorliegen und die Herstelleranforderungen erfüllt sind. Bei festgestellten Risiken müssen sie angemessen reagieren.

Händler müssen vor der Bereitstellung bestimmte Konformitätsmerkmale prüfen und bei erkannten Nichtkonformitäten oder Risiken die gesetzlich vorgesehenen Maßnahmen ergreifen.

Ein Händler oder Importeur kann Herstellerpflichten übernehmen, wenn er ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder eine wesentliche Änderung vornimmt.

Ein Dienstleister kann operative Aufgaben wie Sicherheitsprüfungen, Dokumentation oder Schwachstellenanalyse unterstützen. Die gesetzlich zugewiesenen Pflichten des jeweiligen Wirtschaftsakteurs bleiben jedoch bestehen.

Typischerweise Produktmanagement, Entwicklung, Informationssicherheit, Qualitätsmanagement, Einkauf, Recht, Support und Geschäftsführung. Die konkrete Rollenverteilung sollte produktbezogen festgelegt werden.

Eine Komponente mit digitalen Elementen, die eigenständig kommerziell auf dem EU-Markt bereitgestellt wird, ist selbst ein Produkt im Sinne des CRA; ihr Lieferant ist Hersteller dieser Komponente. Der Integrator muss bei der Einbindung von Drittkomponenten die gebotene Sorgfalt walten lassen und Schwachstellen, die er in einer Komponente findet, dem Komponentenhersteller melden. Komponenten, die nur als Teil eines Endprodukts geliefert und nicht eigenständig bereitgestellt werden, erfasst der CRA über das Endprodukt.

Der CRA unterscheidet sonstige Produkte mit digitalen Elementen, wichtige Produkte der Klasse I und II sowie kritische Produkte. Die Einordnung beeinflusst den möglichen Konformitätsbewertungsweg.

Wichtige Produkte der Klasse I sind in Anhang III Teil I aufgeführt. Dazu gehören unter anderem Passwortmanager, VPN-Produkte, Betriebssysteme, Browser, Identitäts- und Zugriffsmanagementsysteme, Netzwerkmanagementsysteme, Router und Modems für den Internetzugang, Mikroprozessoren und Mikrocontroller mit Sicherheitsfunktion, Smart-Home-Produkte mit Sicherheitsfunktion wie Türschlösser und Kameras sowie vernetztes Spielzeug und Wearables für Gesundheitsdaten.

Wichtige Produkte der Klasse II sind in Anhang III Teil II aufgeführt: Hypervisoren und Container-Laufzeitumgebungen, Firewalls sowie Intrusion-Detection- und Intrusion-Prevention-Systeme und manipulationssichere Mikroprozessoren und Mikrocontroller. Für sie ist eine Konformitätsbewertung unter Beteiligung einer notifizierten Stelle verpflichtend.

Kritische Produkte sind in Anhang IV aufgeführt: Hardwaregeräte mit Sicherheitsboxen wie Hardware-Sicherheitsmodule, Smart-Meter-Gateways und Smartcards oder vergleichbare Geräte einschließlich Secure Elements. Die Kommission kann für sie per delegiertem Rechtsakt eine europäische Cybersicherheitszertifizierung nach dem Cybersecurity Act vorschreiben.

Der Hersteller muss sein Produkt anhand der gesetzlichen Kriterien nachvollziehbar klassifizieren. Die Einstufung sollte dokumentiert und bei Änderungen des Produkts oder der Rechtslage überprüft werden.

Nein. Für viele Produkte ist eine interne Konformitätsbewertung möglich. Bei bestimmten wichtigen oder kritischen Produktkategorien ist abhängig von den gesetzlichen Voraussetzungen ein anderes Verfahren erforderlich.

Der Hersteller bewertet und dokumentiert eigenverantwortlich, ob das Produkt die anwendbaren Anforderungen erfüllt. Eine interne Bewertung entbindet nicht von Nachweispflichten oder Marktüberwachung.

Eine notifizierte Stelle ist bei wichtigen Produkten der Klasse II und bei kritischen Produkten ohne EUCC-Zertifikat verpflichtend. Bei wichtigen Produkten der Klasse I ist sie erforderlich, solange der Hersteller keine harmonisierte Norm, gemeinsame Spezifikation oder europäische Zertifizierung vollständig anwendet. Standardprodukte bewerten ihre Konformität intern, können eine notifizierte Stelle aber freiwillig einbinden.

Im Amtsblatt der EU referenzierte harmonisierte Normen begründen für die von ihnen abgedeckten Anforderungen eine Konformitätsvermutung. Ihr tatsächlicher Anwendungsbereich und ihre Veröffentlichung müssen geprüft werden.

Nein. IEC 62443 liefert für industrielle Produkte und Entwicklungsprozesse belastbare Nachweise, ist aber keine harmonisierte CRA-Norm. Ob konkrete CRA-Anforderungen erfüllt sind und eine Konformitätsvermutung besteht, ist gesondert zu prüfen.

Wenn alle einschlägigen Voraussetzungen der anwendbaren EU-Harmonisierungsrechtsvorschriften erfüllt sind, einschließlich erforderlicher Konformitätsbewertung, technischer Dokumentation und EU-Konformitätserklärung.

Mit der EU-Konformitätserklärung übernimmt der Hersteller die Verantwortung für die Konformität des Produkts mit den angegebenen anwendbaren EU-Rechtsvorschriften. Sie muss die erforderlichen Angaben enthalten und aktuell gehalten werden.

CEN, CENELEC und ETSI erarbeiten im Auftrag der Kommission rund 40 harmonisierte Normen für den CRA: horizontale Normen zu Grundsätzen, sicherer Entwicklung und Schwachstellenbehandlung sowie vertikale Normen für die Produktkategorien aus Anhang III und IV. Die Konformitätsvermutung entsteht erst mit der Listung einer Norm im Amtsblatt der EU. Bestehende Normen wie EN 18031 (Funkanlagenrichtlinie) oder ETSI EN 303 645 begründen für den CRA keine Konformitätsvermutung, auch wenn sie inhaltlich gute Vorarbeit leisten.

Cybersicherheit muss bereits bei Konzeption, Architektur, Entwicklung und Test berücksichtigt werden. Sicherheitsanforderungen sollen nicht erst kurz vor der Markteinführung ergänzt werden.

Produkte müssen mit sicherheitsorientierten Voreinstellungen bereitgestellt werden, soweit die Anforderungen anwendbar sind. Dazu gehören etwa eine möglichst geringe Angriffsfläche und geeignete Zugriffsbeschränkungen.

Ja. Hersteller müssen die relevanten Cybersicherheitsrisiken des Produkts bewerten und die Ergebnisse bei Planung, Entwicklung, Herstellung, Bereitstellung und Wartung berücksichtigen.

Unter anderem vorhersehbare Bedrohungen, Schwachstellen, Einsatzumgebungen, Angriffsflächen, mögliche Auswirkungen und Risiken aus Abhängigkeiten. Die Bewertung muss zum Produkt und seinem Verwendungszweck passen.

Ein SDL ist ein strukturierter Entwicklungsprozess mit Sicherheitsanforderungen, Architekturprüfungen, sicheren Codierpraktiken, Tests, Freigaben und Schwachstellenbehandlung. Er hilft, CRA-Anforderungen reproduzierbar umzusetzen.

Der CRA verlangt angemessene und wirksame Sicherheitsprüfungen. Ob und in welchem Umfang Penetrationstests erforderlich sind, hängt von Produkt, Risiken und anwendbaren Anforderungen ab.

Ja. Die einschlägigen Anforderungen umfassen Mechanismen für die sichere Bereitstellung von Sicherheitsupdates. Die konkrete technische Umsetzung muss zum Produkt und seinen Risiken passen.

Nach Anhang I Teil I Nr. 2 Buchstabe a müssen Produkte mit digitalen Elementen ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden. Die weiteren Anforderungen des Anhangs I sind unter Berücksichtigung der produktbezogenen Cybersicherheits-Risikobewertung anzuwenden. Ein bloßes Versprechen absoluter Schwachstellenfreiheit ist weder realistisch noch die gesetzliche Formulierung.

Produkte müssen entsprechend ihrer Risiken geeignete Mechanismen gegen unbefugten Zugriff vorsehen. Dazu gehören Authentisierung, Autorisierung, Berechtigungsbegrenzung und der Schutz von Zugangsdaten.

Vulnerability Handling umfasst die Identifizierung, Dokumentation, Bewertung, Behebung und Kommunikation von Schwachstellen während des maßgeblichen Unterstützungszeitraums.

Eine Software Bill of Materials (SBOM) ist eine strukturierte Liste der Softwarekomponenten und ihrer Abhängigkeiten. Nach Anhang I Teil II müssen Hersteller Komponenten und Schwachstellen identifizieren und dokumentieren, unter anderem durch eine SBOM in einem gebräuchlichen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten des Produkts erfasst.

Nein. Aus der Pflicht, eine SBOM zu erstellen, folgt keine allgemeine Pflicht, die vollständige SBOM öffentlich bereitzustellen. Gesetzliche Zugangs- und Dokumentationspflichten sind gesondert zu beachten.

Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Anhaltspunkte für eine tatsächliche missbräuchliche Ausnutzung bestehen. Die genaue gesetzliche Definition ist für die Meldeentscheidung maßgeblich.

Meldepflichtig sind schwerwiegende Sicherheitsvorfälle, die Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen haben, wenn die Voraussetzungen des Artikels 14 erfüllt sind. Nicht jeder IT-Sicherheitsvorfall im Unternehmen und nicht jede theoretische Schwachstelle löst diese Meldepflicht aus. Die gesetzliche Definition und die Auswirkungen auf das Produkt sind entscheidend.

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit nach Artikel 14 melden. Die Frühwarnung erfolgt unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung; die weitere Meldung binnen 72 Stunden. Für Abschlussberichte gelten unterschiedliche Fristen.

Die ergänzende Meldung nach Artikel 14 Absatz 2 Buchstabe b beziehungsweise Absatz 4 Buchstabe b ist unverzüglich und spätestens 72 Stunden nach Kenntniserlangung einzureichen, sofern die Angaben nicht bereits übermittelt wurden. Die Informationen unterscheiden sich für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.

Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme einzureichen. Bei einem schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Produktsicherheit ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Vorfallmeldung fällig. Rechtsgrundlage: Artikel 14 Absatz 2 Buchstabe c und Absatz 4 Buchstabe c.

Die verpflichtenden Meldungen nach Artikel 14 werden über die von ENISA betriebene Single Reporting Platform (SRP) eingereicht. Sie sind an das zuständige als Koordinator benannte CSIRT gerichtet und werden zugleich ENISA zugänglich gemacht. Das zuständige CSIRT richtet sich nach den Kriterien des Artikels 14 Absatz 7; für Sonderfälle gelten zusätzliche Regeln.

CVD bezeichnet ein koordiniertes Verfahren, über das externe Finder Schwachstellen melden können und Hersteller deren Bewertung, Behebung und Kommunikation organisieren.

Ja. Hersteller müssen geeignete Kontaktmöglichkeiten und Prozesse bereitstellen, damit Schwachstellen gemeldet und bearbeitet werden können.

Der Unterstützungszeitraum ist der Zeitraum, in dem der Hersteller die vorgeschriebenen Maßnahmen zum Umgang mit Schwachstellen gewährleistet. Er richtet sich nach der erwarteten Nutzungsdauer und den gesetzlichen Kriterien.

Der Unterstützungszeitraum beträgt nach Artikel 13 Absatz 8 mindestens fünf Jahre. Nur wenn das Produkt erwartbar kürzer genutzt wird, darf der Zeitraum dieser kürzeren Nutzungsdauer entsprechen; bei längerer erwarteter Nutzungsdauer muss er entsprechend länger sein. Die Festlegung ist in der technischen Dokumentation zu begründen und beim Kauf für Nutzer erkennbar zu machen.

Ja. Sicherheitsupdates müssen während des Unterstützungszeitraums unverzüglich und kostenlos bereitgestellt werden. Ausgenommen sind nur maßgeschneiderte Produkte, für die Hersteller und gewerblicher Nutzer ausdrücklich etwas anderes vereinbart haben.

In Deutschland ist CERT-Bund im Bundesamt für Sicherheit in der Informationstechnik (BSI) das als Koordinator benannte CSIRT für Meldungen nach Artikel 14. Hersteller mit Hauptniederlassung in Deutschland richten ihre Meldungen über die Single Reporting Platform an CERT-Bund; die Meldung wird zugleich ENISA und den CSIRTs der anderen Mitgliedstaaten zugänglich gemacht, in denen das Produkt bereitgestellt wird.

Die Single Reporting Platform von ENISA ist seit dem 11. September 2026 in Betrieb. Der Hersteller benennt eine Person als Assigned Representative, die sich mit einem persönlichen EU-Login-Konto mit Zwei-Faktor-Authentisierung anmeldet, das zuständige Koordinator-CSIRT auswählt und die Herstellerdaten hinterlegt. Eine Vorab-Registrierung ist nicht erforderlich; Registrierung und erste Meldung sind in wenigen Minuten möglich. Bis zu zwanzig weitere Personen können als Secondary Representatives eingeladen werden. Frühwarnung, Meldung und Abschlussbericht werden als Schritte desselben Vorgangs eingereicht. Eine API gibt es zum Start nicht, die Oberfläche ist englischsprachig.

Die technische Dokumentation muss unter anderem Produktbeschreibung, Design- und Entwicklungsinformationen, Cybersicherheits-Risikobewertung, angewandte Anforderungen, Prüfungen und Konformitätsnachweise enthalten. Maßgeblich ist insbesondere Anhang VII.

Der Hersteller muss die technische Dokumentation und die EU-Konformitätserklärung für mindestens zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufbewahren, je nachdem, welcher Zeitraum länger ist. Einzelheiten zu den aufzubewahrenden Unterlagen ergeben sich aus den einschlägigen Vorschriften.

Erforderlich sind unter anderem verständliche Sicherheitsinformationen, Hinweise zu sicherer Installation und Nutzung, Kontaktinformationen und Angaben zum Unterstützungszeitraum nach den anwendbaren Vorgaben.

Sinnvoll ist eine produktbezogene Nachweismatrix, die Anforderungen mit Verantwortlichen, Risikoentscheidungen, Tests, technischen Unterlagen und Freigaben verknüpft. Dadurch werden Lücken früh sichtbar.

Zuständige Marktüberwachungsbehörden überwachen die Einhaltung. Sie können Informationen anfordern, Produkte prüfen und bei Nichtkonformität Maßnahmen nach den gesetzlichen Befugnissen ergreifen.

Der CRA sieht abhängig vom Verstoß unterschiedliche Höchstbeträge für administrative Geldbußen vor. Bei Verstößen gegen bestimmte grundlegende Pflichten können bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres maßgeblich sein, je nachdem welcher Betrag höher ist. Für andere Verstöße gelten andere Höchstgrenzen; Sonderregeln, insbesondere für bestimmte Kleinst- und Kleinunternehmen sowie Open-Source-Stewards, sind zu beachten.

Ja. Die CE-Kennzeichnung ist eine Erklärung des Herstellers, keine behördliche Zulassung. Die Marktüberwachung kann jederzeit Unterlagen anfordern, Produkte prüfen und bei Nichtkonformität Korrekturen, Vertriebsverbote oder Rückrufe anordnen.

NIS2 betrifft vor allem Cybersicherheits-Risikomanagement und Meldepflichten bestimmter Einrichtungen. Der CRA legt produktbezogene Anforderungen fest. Unternehmen können beiden Regelwerken unterliegen.

Der CRA regelt die Cybersicherheit digitaler Produkte, die DSGVO den Schutz personenbezogener Daten. Beide gelten nebeneinander und ersetzen sich nicht. Die Anforderungen aus Anhang I zu Vertraulichkeit, Integrität und Datenminimierung unterstützen den Datenschutz technisch, Datenschutzfolgenabschätzung, Rechtsgrundlagen und Betroffenenrechte bleiben Sache der DSGVO.

Am Anfang stehen Produktinventar, rechtliche Anwendbarkeitsprüfung, Rollenklärung, Klassifizierung und eine Gap-Analyse. Danach sollten Prioritäten, Verantwortlichkeiten und ein verbindlicher Umsetzungsplan festgelegt werden.

Sie vergleicht bestehende Entwicklungs-, Sicherheits-, Dokumentations- und Schwachstellenprozesse mit den anwendbaren CRA-Anforderungen. Ergebnisse sollten Risiken, Lücken, Maßnahmen, Verantwortliche und Termine enthalten.

Der CRA schreibt nicht pauschal ein Managementsystem mit einem bestimmten Namen vor. Ein strukturiertes, wirksames System für Produktcybersicherheit erleichtert jedoch die dauerhafte Erfüllung und Nachweisführung.

Nein. ISO/IEC 27001 bewertet das Informationssicherheits-Managementsystem einer Organisation und ersetzt weder die produktbezogenen Anforderungen aus Anhang I noch die Konformitätsbewertung. Ein bestehendes ISMS liefert aber Governance, Risikomanagement, Lieferantensteuerung und Incident-Prozesse, auf die ein CRA-Programm aufsetzen kann. Sichere Produktentwicklung, technische Dokumentation und Konformitätsbewertung müssen ergänzt werden.

Hersteller müssen Risiken aus Drittkomponenten, Zulieferern und Abhängigkeiten berücksichtigen. Dafür sind geeignete Anforderungen, Nachweise, Meldewege und Vereinbarungen mit Lieferanten hilfreich.

Open-Source-Komponenten sind im Produktkontext auf Risiken, bekannte Schwachstellen, Updates und Abhängigkeiten zu prüfen. Die CRA-Regeln für freie und quelloffene Software sowie Open-Source-Stewards müssen differenziert betrachtet werden.

Freie und quelloffene Software, die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, fällt nicht unter die produktbezogenen CRA-Pflichten. Die Abgrenzung einer kommerziellen Tätigkeit ist einzelfallabhängig. Für Open-Source-Software-Stewards sieht der CRA besondere Pflichten vor, deren Anwendbarkeit gesondert zu prüfen ist.

Für ein einzelnes Standardprodukt mit vorhandenem Entwicklungsprozess sind sechs bis zwölf Monate realistisch. Ein Portfolio mit mehreren Plattformen, nachzurüstendem Update-Mechanismus und Produkten der Klasse II braucht achtzehn Monate und mehr, weil Prüfstellen und Entwicklungskapazität die Dauer bestimmen. Ohne Bestandsaufnahme ist jede Schätzung Spekulation.

Die Kosten hängen insbesondere von Produktanzahl, technischer Komplexität, Prozessreife, Sicherheitslücken und externem Prüfbedarf ab. Eine belastbare Kalkulation sollte auf einer produktbezogenen Gap-Analyse beruhen.

Geeignet sind nachvollziehbare Kriterien wie vollständige Produktklassifizierung, aktuelle Risikobewertungen, definierte Unterstützungszeiträume, getestete Update-Prozesse, SBOM-Abdeckung und dokumentierte Konformitätsnachweise.

Häufige Fehler sind eine zu späte Produktklassifizierung, fehlende Verantwortlichkeiten, unvollständige Softwareinventare, unklare Schwachstellenmeldeprozesse und die Annahme, dass ISO-27001-Zertifizierung allein ausreicht.

Die Anforderungen gelten unabhängig von der Unternehmensgröße. Der CRA sieht für Kleinst- und Kleinunternehmen Erleichterungen vor: ein vereinfachtes Format der technischen Dokumentation, das die Kommission per Durchführungsrechtsakt festlegt, Leitlinien und Schulungsangebote der Mitgliedstaaten sowie die Berücksichtigung ihrer Größe bei den Gebühren notifizierter Stellen. KMU sollten mit den betroffenen Produkten und den größten Risiken beginnen und vorhandene Entwicklungs- und QM-Prozesse nutzen.