Der EU Cyber Resilience Act (CRA) — Häufige Fragen

Der Cyber Resilience Act (Verordnung (EU) 2024/2847, „CRA") führt erstmals verbindliche, horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen ein, die in der EU auf den Markt gebracht werden. Betroffen sind Hersteller, Einführer und Händler von Hard- und Software weltweit — nicht nur „IT-Unternehmen" —, und die Anforderungen werden durch CE-Kennzeichnung, Marktüberwachungsbefugnisse und empfindliche Bußgelder abgesichert. Der CRA ist am 10. Dezember 2024 in Kraft getreten; die Melde- und Schwachstellenpflichten gelten ab dem 11. September 2026, die vollständigen Anforderungen ab dem 11. Dezember 2027.

Diese Seite beantwortet die Fragen, die uns zum CRA am häufigsten gestellt werden. Sie richtet sich an ein allgemeines unternehmerisches Publikum und ist bewusst praxisorientiert gehalten.

Hinweis: Dieser FAQ enthält ausschließlich allgemeine Informationen und stellt keine Rechtsberatung dar. Er gibt den Rechtsstand von Juli 2026 wieder. Der CRA wird durch Durchführungs- und delegierte Rechtsakte, harmonisierte Normen und Leitlinien der Europäischen Kommission fortlaufend konkretisiert; mehrere dieser Rechtsakte lagen bei Redaktionsschluss noch im Entwurf vor oder standen aus. Bitte holen Sie vor Compliance-Entscheidungen individuellen Rat ein. Für eine auf Ihre Produkte zugeschnittene Scope-Prüfung wenden Sie sich an SES Berlin.

1. Grundlagen

Was ist der Cyber Resilience Act?

Der CRA ist eine EU-Verordnung, die verbindliche Cybersicherheitsanforderungen über den gesamten Lebenszyklus von „Produkten mit digitalen Elementen" festlegt — von der Konzeption über die Produktion bis zum Ablauf des Unterstützungszeitraums. Er fügt sich in den neuen Rechtsrahmen (New Legislative Framework) ein: Produkte müssen die grundlegenden Anforderungen erfüllen, eine Konformitätsbewertung durchlaufen, die CE-Kennzeichnung tragen und von einer EU-Konformitätserklärung begleitet werden. Als Verordnung gilt der CRA unmittelbar in allen Mitgliedstaaten, ohne dass eine nationale Umsetzung erforderlich ist.

Rechtsgrundlage: Verordnung (EU) 2024/2847; grundlegende Anforderungen in Anhang I.

Welche Ziele verfolgt der CRA?

Der CRA verfolgt zwei Kernziele: Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, sollen weniger Schwachstellen aufweisen und „secure by design and by default" sein; zugleich sollen Hersteller die Verantwortung für die Cybersicherheit über den gesamten Produktlebenszyklus übernehmen, einschließlich der Behandlung von Schwachstellen und der Bereitstellung von Sicherheitsupdates. Ein weiteres Ziel ist Transparenz, damit Unternehmen und Verbraucher informierte Entscheidungen treffen und Produkte sicher nutzen können.

Wer wird vom CRA erfasst?

Der CRA richtet sich in erster Linie an Hersteller von Produkten mit digitalen Elementen, begründet aber auch eigenständige Pflichten für Einführer und Händler. Adressiert werden ferner Bevollmächtigte und — in abgeschwächter Form — Verwalter quelloffener Software (Open-Source-Software-Stewards). Ob Sie „erfasst" sind, hängt zunächst davon ab, ob Ihr Produkt ein Produkt mit digitalen Elementen ist, und sodann von Ihrer Rolle in der Lieferkette.

Rechtsgrundlage: Begriffsbestimmungen in Art. 3 CRA; Pflichten der Wirtschaftsakteure in Art. 13, 14, 18–23 CRA.

Bin ich betroffen — wie prüfe ich das?

Prüfen Sie der Reihe nach: (1) Stelle ich auf dem EU-Markt ein Produkt bereit, das Software oder Firmware enthält? (2) Verfügt dieses Produkt über eine — direkte oder indirekte — Datenverbindung zu einem Gerät oder Netz? (3) Welche Rolle habe ich (Hersteller, Einführer, Händler — oder bringe ich Produkte unter eigener Marke in Verkehr bzw. nehme ich eine wesentliche Änderung vor)? Lauten die Antworten auf (1) und (2) „ja" und stehen Sie irgendwo in dieser Lieferkette, ist der CRA für Sie sehr wahrscheinlich einschlägig. Da Klassifizierung, Herstellerfiktion und die Open-Source-Regeln kontraintuitiv sein können, empfiehlt sich eine dokumentierte Scope-Prüfung je Produktlinie.

2. Anwendungsbereich — Produkte, Software und Ausnahmen

Was ist ein „Produkt mit digitalen Elementen"?

Ein „Produkt mit digitalen Elementen" ist jedes Software- oder Hardwareprodukt einschließlich seiner Datenfernverarbeitungslösungen, dessen bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz umfasst. Es müssen kumulativ zwei Voraussetzungen erfüllt sein: Es muss sich um ein Software- oder Hardwareprodukt handeln, und es muss diese Datenverbindung bestehen. Rein offline arbeitende Produkte ohne Datenverbindung fallen aus dem Anwendungsbereich heraus.

Rechtsgrundlage: Art. 3 Nr. 1 und Nr. 2 CRA.

Erfasst der CRA eigenständige Software, mobile Apps und SaaS?

Eigenständige Software und mobile Apps, die die Definition erfüllen, sind als Produkte mit digitalen Elementen erfasst. Eigenständige Software-as-a-Service (SaaS) und Cloud-Dienste fallen grundsätzlich nicht unter den CRA; sie unterliegen vorrangig der NIS2-Richtlinie, DORA und der DSGVO. Die wichtige Ausnahme ist die „Datenfernverarbeitungslösung": Software auf der Cloud-Seite, die vom Hersteller entwickelt wird und für die Funktionsfähigkeit des Produkts erforderlich ist, gilt als Teil des Produkts und ist erfasst.

Rechtsgrundlage: Art. 3 Nr. 1, Nr. 2 CRA; die Abgrenzung zu SaaS/Cloud wird durch die Kommissions-FAQ weiter konkretisiert (in Entwicklung).

Gibt es eine Ausnahme für freie und quelloffene Software (FOSS)?

Ja. Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, fällt gar nicht unter den CRA. Wo FOSS tatsächlich nichtkommerziell ist, greifen die Herstellerpflichten der Verordnung nicht. Das Bild ändert sich jedoch, sobald die Software kommerzialisiert wird; für „Verwalter quelloffener Software" gilt ein erleichtertes Regime (dazu die eigenen Fragen unten).

Rechtsgrundlage: Erwägungsgründe zu FOSS; Art. 3 Nr. 14 und Art. 24 CRA.

Gibt es weitere Produktausnahmen?

Ja. Produkte, die bereits sektorspezifischen EU-Cybersicherheitsregeln unterliegen — etwa Medizinprodukte, In-vitro-Diagnostika, Kraftfahrzeuge sowie Produkte der Zivilluftfahrt und bestimmte Maschinenprodukte —, sind ganz oder teilweise ausgenommen, soweit diese Regime bereits ein gleichwertiges Schutzniveau erreichen. Auch bestimmte ausschließlich für die nationale Sicherheit oder Verteidigung entwickelte Produkte sind ausgenommen. Sektorspezifische Regeln gehen dem CRA im Überschneidungsbereich grundsätzlich vor.

Rechtsgrundlage: Art. 2 CRA und Erwägungsgründe zum Sektorvorrang; die genauen Grenzen sind im Einzelfall zu beurteilen.

Zählt die Bereitstellung von Software innerhalb eines Konzerns?

Der CRA knüpft an die „Bereitstellung auf dem Markt" im Rahmen einer Geschäftstätigkeit an. Ob eine interne Überlassung von Software zwischen Gesellschaften desselben Konzerns ein Inverkehrbringen darstellt, hängt vom Einzelfall ab, insbesondere davon, ob das Produkt zum Vertrieb oder zur Verwendung im Rahmen einer Geschäftstätigkeit überlassen wird oder rein internen Charakter hat. Dies ist einer der Punkte, zu denen die Kommissionsleitlinien noch in Entwicklung sind; konzerninterne Konstellationen sollten daher im Einzelfall geprüft und nicht pauschal als außerhalb des Anwendungsbereichs behandelt werden.

Rechtsgrundlage: „Bereitstellung auf dem Markt" / „Inverkehrbringen", Art. 3 CRA; im Einzelfall zu beurteilen.

3. Rollen und Pflichten

Welche Pflichten treffen den Hersteller?

Der Hersteller trägt den Kern der CRA-Pflichten. Vor dem Inverkehrbringen muss er eine Cybersicherheits-Risikobewertung durchführen, die grundlegenden Anforderungen des Anhangs I risikobasiert anwenden und dies dokumentieren, das Produkt ohne bekannte ausnutzbare Schwachstellen bereitstellen, die Konformitätsbewertung durchführen, die technische Dokumentation und die EU-Konformitätserklärung erstellen und die CE-Kennzeichnung anbringen. Während des Unterstützungszeitraums muss er Schwachstellen behandeln, Sicherheitsupdates bereitstellen und die Meldepflichten erfüllen.

Rechtsgrundlage: Art. 13 und Art. 14 CRA; Anhang I.

Vorsicht vor der „Herstellerfiktion": Eigenmarke und wesentliche Änderung

Wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder ein bereits auf dem Markt befindliches Produkt wesentlich ändert und sodann bereitstellt, gilt als Hersteller und übernimmt die vollen Herstellerpflichten nach Art. 13 und 14 — auch wenn das Produkt tatsächlich von einem Dritten gefertigt wurde. Zudem trägt ein Wirtschaftsakteur, der unter Art. 21 fällt, die Herstellerpflichten. Diese „Herstellerfiktion" erfasst häufig Händler, Integratoren und Rebrander, die davon ausgingen, lediglich weiterzuverkaufen.

Rechtsgrundlage: Art. 3 Nr. 13 CRA (Definition), Art. 21 CRA.

Welche Pflichten treffen den Einführer?

Ein Einführer darf nur Produkte in Verkehr bringen, die dem CRA entsprechen. Zuvor muss er überprüfen, dass der Hersteller die Konformitätsbewertung durchgeführt, die technische Dokumentation erstellt, die CE-Kennzeichnung angebracht und die erforderlichen Informationen und Anleitungen beigefügt hat. Hat der Einführer Grund zu der Annahme, dass ein Produkt nicht konform ist oder ein erhebliches Cybersicherheitsrisiko darstellt, darf er es nicht in Verkehr bringen und muss den Hersteller und die Marktüberwachungsbehörden unterrichten.

Rechtsgrundlage: Art. 19 CRA.

Welche Pflichten treffen den Händler?

Händler müssen im Hinblick auf den CRA mit der gebotenen Sorgfalt handeln. Vor der Bereitstellung eines Produkts müssen sie prüfen, ob es die CE-Kennzeichnung trägt, ob Hersteller und gegebenenfalls Einführer ihren Kennzeichnungs- und Dokumentationspflichten nachgekommen sind und ob die erforderlichen Anleitungen vorliegen. Zu beachten ist: Eine Eigenmarken-Vermarktung oder wesentliche Änderung überführt den Händler in die vollen Herstellerpflichten.

Rechtsgrundlage: Art. 20 CRA; Art. 21 CRA.

Ist ein Bevollmächtigter erforderlich?

Nein — die Bestellung eines Bevollmächtigten ist optional. Sie ist jedoch für Nicht-EU-Hersteller ohne EU-Einführer praktisch ratsam, weil die Marktüberwachungsbehörden einen in der Union niedergelassenen Wirtschaftsakteur als Ansprechpartner benötigen (im Einklang mit der Verordnung (EU) 2019/1020). Für Nicht-EU-Hersteller bestimmt die Niederlassung des Bevollmächtigten zudem, welches CSIRT für die Meldung zuständig ist.

Rechtsgrundlage: Art. 18 CRA; Art. 14 Abs. 7 CRA; Verordnung (EU) 2019/1020.

4. Verwalter quelloffener Software und Bußgelder

Was ist ein „Verwalter quelloffener Software"?

Ein Verwalter quelloffener Software (Open-Source-Software-Steward) ist eine juristische Person — keine natürliche Person und kein „Hersteller" —, die die Entwicklung bestimmter freier und quelloffener Software, die für kommerzielle Tätigkeiten bestimmt ist, systematisch und nachhaltig unterstützt und zur Sicherung ihrer Brauchbarkeit beiträgt. Typische Beispiele sind die großen Open-Source-Stiftungen. Verwalter unterliegen einem gegenüber Herstellern erleichterten Pflichtenkatalog.

Rechtsgrundlage: Art. 3 Nr. 14 CRA; Erwägungsgründe zu Verwaltern.

Was muss ein Verwalter quelloffener Software konkret tun?

Verwalter unterliegen einem reduzierten Pflichtenkatalog nach Art. 24: Sie müssen eine Cybersicherheitsstrategie einführen und dokumentieren, mit den Marktüberwachungsbehörden kooperieren und die Meldepflicht nach Art. 24 Abs. 3 erfüllen (die auf den Meldemechanismus des Art. 14 zurückverweist). Verwalter bringen keine CE-Kennzeichnung an, führen keine Konformitätsbewertung durch und unterliegen nicht den herstellerbezogenen Aufbewahrungspflichten für die Dokumentation.

Rechtsgrundlage: Art. 24 CRA, einschließlich Art. 24 Abs. 3.

Sind Open-Source-Stiftungen Bußgeldern nach dem CRA ausgesetzt?

Nur teilweise. Art. 64 Abs. 10 lit. b nimmt Verwalter lediglich von den Bußgeldern nach Art. 64 Abs. 3–9 aus. Die Stufe des Art. 64 Abs. 2 — bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes — gilt auch für Verwalter, und zwar vor allem über die Meldepflicht nach Art. 24 Abs. 3 in Verbindung mit Art. 14. Es trifft daher nicht zu, dass Stiftungen keinen CRA-Bußgeldern ausgesetzt wären: Ihr Risiko ist verengt, aber nicht beseitigt.

Rechtsgrundlage: Art. 64 Abs. 2 und Art. 64 Abs. 10 lit. b CRA; Art. 24 Abs. 3 in Verbindung mit Art. 14 CRA.

Was gilt, wenn die quelloffene Software kommerzialisiert wird?

Sobald quelloffene Software im Rahmen einer Geschäftstätigkeit in Verkehr gebracht wird — etwa durch bezahlten Support, Monetarisierung, werbefinanzierte oder datengetriebene Modelle oder Dual Licensing —, gilt für den handelnden Akteur der volle Herstellerscope. Wichtig: Eine Organisation kann beides sein — Verwalter für das Upstream-Projekt und Hersteller für ihre eigene kommerzielle Distribution derselben Software.

Rechtsgrundlage: Art. 3 Nr. 13, Nr. 14 CRA.

5. Kernpflichten in der Praxis

Was ist der Unterstützungszeitraum, und was gilt für Sicherheitsupdates?

Hersteller müssen einen Unterstützungszeitraum festlegen und einhalten, in dem sie Schwachstellen behandeln und Sicherheitsupdates bereitstellen. Der CRA sieht eine Untergrenze von mindestens 5 Jahren vor; kürzer darf der Zeitraum nur sein, wenn das Produkt voraussichtlich kürzer genutzt wird, und er muss länger sein, wenn die erwartete Produktlebensdauer länger ist. Der Unterstützungszeitraum ist festzulegen, zu dokumentieren und transparent gegenüber den Nutzern zu kommunizieren.

Rechtsgrundlage: Art. 13 Abs. 8 CRA; Transparenz nach Art. 13 Abs. 19 CRA.

Brauche ich eine Software-Stückliste (SBOM)?

Ja, der Sache nach. Hersteller sind für die Sicherheit des Gesamtprodukts einschließlich der Dritt- und Open-Source-Komponenten verantwortlich und müssen insoweit eine dokumentierte Sorgfaltsprüfung vornehmen. Als Teil der technischen Dokumentation müssen sie eine SBOM erstellen und vorhalten, die zumindest die Top-Level-Abhängigkeiten des Produkts abdeckt, in einem gängigen und maschinenlesbaren Format (üblich sind Formate wie SPDX oder CycloneDX).

Rechtsgrundlage: Art. 13 CRA und Anhang I; technische Dokumentation Anhang VII.

Welche Meldepflichten bestehen (24h / 72h / Abschlussbericht)?

Die Meldepflicht wird durch Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schweren Vorfalls ausgelöst. Der Hersteller muss übermitteln: eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und einen Abschlussbericht. Der Abschlussbericht ist fällig 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme (bei einer aktiv ausgenutzten Schwachstelle) bzw. einen Monat nach der 72-Stunden-Meldung (bei einem schweren Vorfall). Gemeldet wird einmal über die ENISA Single Reporting Platform, die die Meldung an das koordinierende CSIRT (bestimmt nach Hauptniederlassung oder Bevollmächtigtem) und an ENISA weiterleitet. Diese Pflichten bestehen kumulativ zu etwaigen parallelen Pflichten nach NIS2 und DSGVO.

Rechtsgrundlage: Art. 14 CRA; Art. 16 CRA; Art. 14 Abs. 7 CRA.

Wann wird Software „in Verkehr gebracht"?

Software wird „in Verkehr gebracht", wenn sie erstmals im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird, sei es entgeltlich oder unentgeltlich. „Bereitstellung auf dem Markt" ist jede Abgabe zum Vertrieb oder zur Verwendung auf dem EU-Markt im Rahmen einer Geschäftstätigkeit. Dieser Begriff — und nicht ein formaler Verkauf — löst die CRA-Pflichten aus und ist maßgeblich für den Zeitpunkt, für die Herstellerfiktion und für Bestandsprodukte.

Rechtsgrundlage: Begriffsbestimmungen in Art. 3 CRA.

6. Konformität, CE-Kennzeichnung und Bestandsprodukte

Brauche ich Konformitätsbewertung und CE — und muss ich ein bestehendes CE-Produkt neu zertifizieren?

Produkte mit digitalen Elementen müssen ab dem 11. Dezember 2027 vor dem Inverkehrbringen eine Konformitätsbewertung durchlaufen, von einer EU-Konformitätserklärung erfasst sein und die CE-Kennzeichnung tragen. Die meisten Produkte können im Wege der Selbstbewertung bewertet werden, während „wichtige" und „kritische" Produkte die Einbindung einer notifizierten Stelle erfordern können. Eine CE-Kennzeichnung nach anderem EU-Recht ersetzt die CRA-Konformität nicht — der CRA tritt mit seiner eigenen Cybersicherheits-Konformität hinzu, sodass bestehende CE-Produkte für ihre Cybersicherheitsaspekte in der Regel einer CRA-Bewertung bedürfen.

Rechtsgrundlage: Art. 13 Abs. 12, Art. 28–32 CRA; Klassifizierung in Anhang III/IV.

Wie wird ein Produkt klassifiziert (Standard / wichtig / kritisch)?

Die meisten Produkte fallen in die Standardkategorie und unterliegen der Selbstbewertung. In Anhang III aufgeführte Produkte gelten als „wichtig" (Klasse I oder II) und können eine notifizierte Stelle erfordern. Eine kleine, in Anhang IV genannte Gruppe gilt als „kritisch" und kann strengeren Verfahren unterliegen. Die Klassifizierung nimmt zunächst der Hersteller vor, orientiert an der Kernfunktion des Produkts; die Leitlinien der Kommission sind noch in Entwicklung.

Rechtsgrundlage: Art. 7 und Anhang III (wichtig), Anhang IV (kritisch) CRA.

Darf ich meine Bestandsprodukte weiter verkaufen?

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen grundsätzlich nicht nachträglich an den CRA angepasst werden. Etwas anderes gilt nur, wenn ein solches Produkt nach diesem Datum wesentlich geändert wird; dann gilt es als neues Produkt und der CRA findet vollständig Anwendung. Hersteller sollten nachweisen können, dass ein bestimmtes Update keine wesentliche Änderung darstellt.

Rechtsgrundlage: Art. 69 Abs. 2 CRA; „wesentliche Änderung" Art. 3 Nr. 30 CRA.

Was ist eine „wesentliche Änderung"?

Eine wesentliche Änderung ist eine Modifikation eines Produkts nach dem Inverkehrbringen, die dessen Konformität mit den grundlegenden Anforderungen berührt oder seine Zweckbestimmung ändert — etwa das Hinzufügen einer materiell neuen Funktion oder Schnittstelle. Gewöhnliche Sicherheitspatches sind in der Regel keine wesentlichen Änderungen; echte neue Funktionalität kann es sein. Da den Hersteller die Darlegungslast trifft, empfiehlt es sich, Update-Entscheidungen zu dokumentieren.

Rechtsgrundlage: Art. 3 Nr. 30 CRA; Kommissions-Leitlinienentwurf.

7. Bußgelder und weitere Folgen

Welche Bußgelder sieht der CRA vor?

Der CRA sieht drei Bußgeldstufen vor: bis zu 15 Mio. € oder 2,5 % des gesamten weltweiten Jahresumsatzes (der höhere Wert) für Verstöße gegen die grundlegenden Anforderungen des Anhangs I und die Kernpflichten der Art. 13 und 14; bis zu 10 Mio. € oder 2 % für Verstöße gegen sonstige Pflichten; und bis zu 5 Mio. € oder 1 % für die Erteilung falscher, unvollständiger oder irreführender Angaben.

Rechtsgrundlage: Art. 64 Abs. 2, Abs. 3 und Abs. 4 CRA.

Welche Folgen bestehen jenseits von Bußgeldern?

Bußgelder sind nicht die einzige Folge. Marktüberwachungsbehörden können Korrekturmaßnahmen anordnen, die Bereitstellung eines Produkts beschränken oder verbieten und dessen Rücknahme oder Rückruf anordnen — auch bei CE-gekennzeichneten Produkten mit erheblichem Cybersicherheitsrisiko. Ohne gültige CE-Kennzeichnung besteht kein rechtmäßiger Marktzugang, und nicht konforme Produkte können an der EU-Außengrenze zurückgewiesen werden. Hinzu tritt die zivilrechtliche Produkthaftung.

Rechtsgrundlage: Art. 52–56 CRA in Verbindung mit Verordnung (EU) 2019/1020.

Wie wirkt die zivilrechtliche Produkthaftung mit dem CRA zusammen?

Nach der revidierten Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853, „PLD") sind Software und digitale Elemente ausdrücklich erfasst, und ein Produkt kann wegen einer Cybersicherheits-Schwachstelle oder eines fehlerhaften oder unterlassenen Sicherheitsupdates fehlerhaft sein. Die PLD sieht eine verschuldensunabhängige (Gefährdungs-)Haftung vor und erfasst auch Schäden wie die Zerstörung oder Korruption von Daten. Die Einhaltung — oder Nichteinhaltung — von Cybersicherheitsanforderungen wie dem CRA ist ein bei der Fehlerbewertung zu berücksichtigender Umstand (Art. 7 Abs. 2 PLD); sie begründet keine automatische Fehlervermutung. Umgekehrt kann dokumentierte CRA-Konformität die Entlastung des Herstellers stützen.

Rechtsgrundlage: Richtlinie (EU) 2024/2853 (PLD), insbesondere Art. 7 Abs. 2.

8. Verhältnis zu anderen EU-Regimen

Wie verhält sich der CRA zu NIS2, DORA und der DSGVO?

Der CRA ist eine Produktverordnung und tritt neben diese anderen Regime, ohne sie zu ersetzen. NIS2 verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zum Risikomanagement und zur Vorfallmeldung; ein CRA-Meldeereignis kann daher mit einer parallelen NIS2-Meldung zusammenfallen. DORA regelt die digitale operative Resilienz im Finanzsektor, die DSGVO die Verletzung des Schutzes personenbezogener Daten. Eigenständige Cloud- und SaaS-Dienste unterliegen vorrangig NIS2, DORA und der DSGVO und nicht dem CRA. Die Meldung nach dem CRA besteht kumulativ; die Vorfall-Governance sollte daher so ausgestaltet werden, dass sie alle einschlägigen Regime zugleich erfüllt.

Rechtsgrundlage: Erwägungsgründe zum Verhältnis; Art. 14–16 CRA; NIS2, DORA, DSGVO und PLD als eigenständige Regelwerke.

Schnelltest: Bin ich betroffen?

Beantworten Sie jede Frage mit ja/nein. Mehrere „ja"-Antworten sprechen stark dafür, dass der CRA einschlägig ist und eine Scope-Prüfung angezeigt ist:

Stellen Sie im Rahmen Ihrer Geschäftstätigkeit Software oder Hardware auf dem EU-Markt bereit?
Verfügt dieses Produkt über eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz?
Vertreiben Sie Produkte unter eigener Marke oder ändern Sie Produkte Dritter vor dem Verkauf?
Führen Sie Produkte mit Software oder Firmware in die EU ein oder vertreiben Sie solche innerhalb der EU?
Betreuen oder finanzieren Sie quelloffene Software, die für eine kommerzielle Nutzung bestimmt ist?
Ist Ihr Produkt nicht vollständig von einem sektorspezifischen Regime erfasst?
Wird Ihr Produkt am oder nach dem 11. Dezember 2027 noch verkauft oder mit Updates versorgt?

Was jetzt zu tun ist — nächste Schritte

Scope-Prüfung je Produktlinie — feststellen, welche Produkte „Produkte mit digitalen Elementen" sind, wer CRA-Hersteller ist und wie jedes Produkt klassifiziert (Standard / wichtig / kritisch).
Rollen im Portfolio abbilden — Sie können für einige Produkte Hersteller, für andere Einführer oder Händler und möglicherweise Verwalter quelloffener Software sein.
Prozesse für Secure by Design und Schwachstellenbehandlung aufbauen, einschließlich eines SBOM-Ansatzes (SPDX/CycloneDX) und dokumentierter Sorgfaltsprüfung für Dritt- und Open-Source-Komponenten.
Unterstützungszeiträume festlegen und dokumentieren (mindestens 5 Jahre, länger bei längerer Lebensdauer).
Integrierte Melde-Governance aufsetzen, ausgerichtet am Takt 24h/72h/Abschlussbericht und an der ENISA Single Reporting Platform, abgestimmt mit NIS2 und DSGVO.
Konformitätsdokumentation und CE rechtzeitig vor dem 11. Dezember 2027 vorbereiten.

Wie wir helfen können

SES Berlin berät Hersteller, Einführer, Händler und Open-Source-Organisationen zum Cyber Resilience Act — von der ersten Scope- und Klassifizierungsprüfung je Produktlinie über die Konformitäts- und CE-Strategie, die Governance von Unterstützungszeitraum und SBOM bis hin zu integrierten Meldeprozessen über CRA, NIS2 und DSGVO hinweg. Wenn Sie eine Scope-Prüfung für Ihre Produkte wünschen, sprechen Sie uns an.

Dieser FAQ enthält allgemeine Informationen, keine Rechtsberatung, und gibt den Rechtsstand von Juli 2026 wieder.

Verordnungstext: Alle in diesem FAQ zitierten Normen finden Sie im CRA-Verordnungstext (VO (EU) 2024/2847) — mit Inhaltsverzeichnis aller Artikel und Anhänge sowie dem Link zum amtlichen Volltext.