Cyber Resilience Act – Was ist zu tun?

Ein Schritt-für-Schritt-Compliance-Leitfaden für Hersteller, Einführer, Händler und Verwalter quelloffener Software

Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847, „CRA") macht aus Produkt-Cybersicherheit eine verbindliche Rechtspflicht für alle, die „Produkte mit digitalen Elementen" auf dem EU-Markt bereitstellen. Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab dem 11. September 2026; die vollständigen Anforderungen — grundlegende Anforderungen, Risikobewertung, SBOM, EU-Konformitätserklärung und CE-Kennzeichnung — gelten ab dem 11. Dezember 2027. Verstöße können Bußgelder von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, Rücknahme oder Rückruf sowie den Verlust des Marktzugangs auslösen.

Diese Seite beantwortet die praktische Frage, die sich jedes betroffene Unternehmen stellt: Was muss ich eigentlich tun? Sie ist als Roadmap aufgebaut — vom ersten Anwendungsbereichs-Check über Ihre Rolle und deren Pflichten bis hin zu Konformitätsbewertung, Melde-Infrastruktur und den wesentlichen Fristen. Jeder Schritt nennt den einschlägigen CRA-Artikel, damit jede Pflicht auf ihre Grundlage zurückverfolgbar bleibt.

Haftungsausschluss. Diese Seite enthält allgemeine Informationen und stellt keine Rechtsberatung dar. Sie gibt den Rechtsstand von Juli 2026 wieder. Der CRA ist ein neues und sich fortentwickelndes Instrument: Durchführungsrechtsakte, harmonisierte Normen und Leitlinien der Kommission befinden sich noch in Entwicklung, und einzelne Punkte sind noch nicht abschließend geklärt. Handeln Sie nicht allein auf Grundlage dieser Übersicht. Für eine Beratung zu Ihren konkreten Produkten und Ihrer Lieferkette wenden Sie sich bitte an SES Berlin.

Schritt 1 — Anwendungsbereichs-Check: Sind Sie überhaupt erfasst? (Je Produktlinie)

Starten Sie kein unternehmensweites CRA-Projekt, bevor Sie wissen, welche Ihrer Produkte tatsächlich erfasst sind. Führen Sie den Anwendungsbereichs-Check Produktlinie für Produktlinie durch.

Was zu tun ist. Für jedes Produkt zwei kumulative Fragen: (1) Handelt es sich um ein Produkt mit digitalen Elementen — enthält es also Software oder Hardware — und (2) verfügt es über eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz? Beide Voraussetzungen müssen erfüllt sein. Ein rein offline arbeitendes Produkt ohne jede Datenverbindung fällt aus dem CRA heraus.

Achten Sie auf die Grenzfälle:

  • Standalone-SaaS / Cloud-Dienste liegen grundsätzlich außerhalb des CRA und unterfallen stattdessen NIS2, DORA oder der DSGVO — es sei denn, der Dienst ist eine Datenfernverarbeitungslösung im Sinne von Art. 3 Nr. 2, dann gilt er als Teil des Produkts und ist erfasst.
  • Freie und quelloffene Software (FOSS), die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, ist ausgenommen; für Verwalter quelloffener Software gilt ein eigener, leichterer Pflichtenkatalog (siehe Schritt 2).
  • Sektorspezifische Regime (Medizinprodukte, Kraftfahrzeuge, Luftfahrt, Maschinen) gehen ganz oder teilweise vor; ein bereits von einem solchen Cybersicherheitsrahmen erfasstes Produkt kann ausgenommen sein.

Rechtsgrundlage: Art. 2, Art. 3 Nr. 1, Art. 3 Nr. 2 CRA; Erwägungsgrund 31.

Schritt 2 — Bestimmen Sie Ihre Rolle und deren Pflichten

Der CRA weist Pflichten nach der Rolle zu. Am selben Produkt können mehrere Wirtschaftsakteure mit jeweils unterschiedlichem Pflichtenkatalog beteiligt sein. Bestimmen Sie zuerst Ihre Rolle (oder Rollen), denn alles Weitere hängt davon ab.

Hersteller (die weitreichendsten Pflichten)

Was zu tun ist. Wer das Produkt entwickelt oder herstellt bzw. entwickeln/herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet, trägt die vollen Herstellerpflichten. Praktisch bedeutet das: eine Cybersicherheits-Risikobewertung vor dem Inverkehrbringen; Entwicklung und Herstellung nach den grundlegenden Anforderungen in Anhang I (Security by Design); ein Verfahren zur Behandlung von Schwachstellen; Pflege einer Software-Stückliste (SBOM); Festlegung und Einhaltung eines Unterstützungszeitraums; Erstellung der technischen Dokumentation; Ausstellung der EU-Konformitätserklärung; und Anbringung der CE-Kennzeichnung.

Rechtsgrundlage: Art. 13 und Art. 14 CRA.

Einführer

Was zu tun ist. Wer ein Produkt eines außerhalb der EU niedergelassenen Herstellers auf dem EU-Markt in Verkehr bringt, muss zuvor prü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. Bringen Sie kein nicht konformes Produkt in Verkehr und werden Sie tätig, wenn Sie Grund zu der Annahme haben, dass ein Produkt nicht konform ist.

Rechtsgrundlage: Art. 19 CRA.

Händler

Was zu tun ist. Vor der Bereitstellung eines Produkts prüfen, dass es die CE-Kennzeichnung trägt und dass Hersteller und Einführer ihre Kennzeichnungs- und Dokumentationspflichten erfüllt haben; dabei mit der gebotenen Sorgfalt im Hinblick auf die anwendbaren Anforderungen vorgehen. Stellen Sie kein Produkt bereit, von dessen Nichtkonformität Sie wissen oder wissen müssten.

Rechtsgrundlage: Art. 20 CRA.

Bevollmächtigter (optional)

Was zu tun ist. Ein Hersteller kann einen in der EU niedergelassenen Bevollmächtigten benennen — dies ist optional, nicht verpflichtend. Für Nicht-EU-Hersteller ohne EU-Einführer ist es praktisch ratsam, weil so ein Wirtschaftsakteur in der Union für Zwecke der Marktüberwachung vorhanden ist (im Einklang mit der Verordnung (EU) 2019/1020). Bei einem Nicht-EU-Hersteller bestimmt die Niederlassung des Bevollmächtigten das für die Meldung zuständige CSIRT.

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

Verwalter quelloffener Software (eine eigenständige, leichtere Rolle)

Was zu tun ist. Wenn Sie eine juristische Person sind (nur juristische Personen kommen in Betracht), die die Entwicklung bestimmter, für eine kommerzielle Nutzung bestimmter FOSS systematisch und nachhaltig unterstützt und deren Brauchbarkeit sichert — etwa eine Stiftung nach dem Muster der Linux-/Python-/Eclipse-Foundation —, sind Sie Verwalter quelloffener Software, nicht Hersteller. Für Sie gilt ein reduzierter Katalog: eine Cybersicherheitsstrategie einrichten, mit den Marktüberwachungsbehörden kooperieren und aktiv ausgenutzte Schwachstellen sowie schwere Vorfälle melden. Sie bringen keine CE-Kennzeichnung an, führen keine Konformitätsbewertung durch und führen die Herstellerdokumentation nicht.

Achten Sie auf das Detail bei den Bußgeldern. Die Bußgeldbefreiung des Verwalters ist nur teilweise: Art. 64 Abs. 10 lit. b nimmt Verwalter nur von den Bußgeldern nach Art. 64 Abs. 3–9 aus. Die Abs.-2-Stufe — bis zu 15 Mio. EUR oder 2,5 % — gilt auch für Verwalter, insbesondere über die Meldepflicht.

Zu beachten: Eine Organisation kann beides sein — Verwalter für ihr Upstream-Projekt und Hersteller für ihre eigene kommerzielle Distribution. Kommerzialisierte quelloffene Software (bezahlter Support, werbefinanziert, Datenverwertung, Dual Licensing) fällt in den vollen Herstellerscope.

Rechtsgrundlage: Art. 3 Nr. 14, Art. 24, Art. 24 Abs. 3, Art. 64 Abs. 2, Art. 64 Abs. 10 lit. b CRA; Erwägungsgründe 18–19.

Die „Herstellerfiktion" — Eigenmarke und wesentliche Änderung

Was zu tun ist. Erkennen Sie, wann Sie zum Hersteller werden, obwohl Sie das Produkt nicht gebaut haben. Wer ein Produkt unter eigenem Namen oder eigener Marke vermarktet oder eine wesentliche Änderung an einem Produkt vornimmt und es dann in Verkehr bringt, übernimmt die vollen Herstellerpflichten. Das ist die Falle für OEM-/White-Label-Wiederverkäufer und Systemintegratoren.

Rechtsgrundlage: Art. 21 CRA; Art. 3 Nr. 30 CRA (Definition der „wesentlichen Änderung").

Schritt 3 — Security by Design und Anhang I

Was zu tun ist. Entwerfen und produzieren Sie jedes erfasste Produkt so, dass es die grundlegenden Cybersicherheitsanforderungen in Anhang I erfüllt, angewendet auf risikobasierter Grundlage. Es gibt keine Einheits-Checkliste: Führen Sie für das konkrete Produkt eine Cybersicherheits-Risikobewertung durch, entscheiden Sie, welche Anhang-I-Anforderungen in welcher Tiefe gelten, setzen Sie sie um und — entscheidend — dokumentieren Sie sowohl die Bewertung als auch die Umsetzung. Der CRA verlangt keinen „Nullzustand" ohne Schwachstellen; er verlangt eine gesteuerte, dokumentierte und dem Produktrisiko angemessene Sicherheit, einschließlich der Behandlung bekannter Schwachstellen.

Rechtsgrundlage: Art. 13 CRA; Anhang I CRA.

Schritt 4 — Behandlung und Meldung von Schwachstellen: der 24h-/72h-/Abschluss-Workflow

Dies ist die erste harte operative Frist (11. September 2026) und der Bereich, der Unternehmen am ehesten unvorbereitet trifft. Bauen Sie den Workflow jetzt auf.

Was zu tun ist. Richten Sie einen internen Prozess ein, der bei Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schweren Vorfalls auslöst und Meldungen auf der gesetzlichen Uhr erzeugt:

  • 24 Stunden — Frühwarnung an das koordinierende CSIRT und ENISA;
  • 72 Stunden — eine ausführlichere Meldung;
  • Abschlussbericht — bei einer Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme; bei einem schweren Vorfall innerhalb eines Monats nach der 72-Stunden-Meldung.

Melden Sie einmal über die ENISA Single Reporting Platform; die Plattform leitet die Meldung an das koordinierende CSIRT und ENISA weiter, und das CSIRT verteilt weiter. Das zuständige CSIRT bestimmt sich nach Ihrer Hauptniederlassung (oder, bei einem Nicht-EU-Hersteller, nach der Niederlassung des Bevollmächtigten). Schwachstellen in Drittkomponenten sind ebenfalls meldepflichtig.

Bauen Sie eine integrierte Melde-Governance. Die CRA-Meldung ist kumulativ mit der Meldung nach NIS2 und DSGVO. Errichten Sie nicht drei isolierte Prozesse, sondern eine einheitliche Incident-Response-Governance, die die richtigen Meldungen an die richtigen Behörden innerhalb der jeweiligen Fristen auslösen kann.

Rechtsgrundlage: Art. 14, Art. 14 Abs. 7, Art. 16, Art. 24 Abs. 3 CRA.

Schritt 5 — Unterstützungszeitraum: festlegen, begründen und dokumentieren

Was zu tun ist. Legen Sie für jedes Produkt den Unterstützungszeitraum fest, in dem Sie Sicherheitsupdates bereitstellen. Die gesetzliche Untergrenze beträgt fünf Jahre — fünf Jahre sind aber ein Mindestwert, kein Standard: Ein kürzerer Zeitraum ist nur zulässig, wenn das Produkt voraussichtlich kürzer genutzt wird, und ein längerer Zeitraum ist erforderlich, wenn die Lebensdauer des Produkts länger ist. Dokumentieren Sie die Begründung. Seien Sie transparent hinsichtlich des Enddatums und benachrichtigen Sie die Nutzer über den bevorstehenden Ablauf.

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

Schritt 6 — Komponenten und SBOM: Sorgfalt gegenüber Lieferanten

Was zu tun ist. Sie sind für das Gesamtprodukt verantwortlich, einschließlich Dritt- und Open-Source-Komponenten. Etablieren Sie eine dokumentierte Due Diligence gegenüber Ihren Lieferanten und Komponenten — prüfen Sie ggf. den CE-Status, die Update-Historie und Schwachstellen-Datenbanken. Erstellen Sie eine maschinenlesbare Software-Stückliste (SBOM), die mindestens die Top-Level-Abhängigkeiten abdeckt, in einem gängigen Format wie SPDX oder CycloneDX, und halten Sie sie als Teil Ihrer technischen Dokumentation für die Marktüberwachung bereit.

Rechtsgrundlage: Art. 13 CRA; Anhang I CRA.

Schritt 7 — Konformitätsbewertung und CE-Kennzeichnung

Was zu tun ist. Führen Sie jedes erfasste Produkt durch Konformitätsbewertung und CE-Kennzeichnung:

  1. Klassifizieren Sie das Produkt. Der Standard ist die Selbstbewertung. Wichtige Produkte (Klasse I und II, Anhang III) und kritische Produkte (Anhang IV) unterliegen strengeren Routen; wo erforderlich, ist eine notifizierte Stelle einzubinden. Der Hersteller legt die Klassifizierung primär fest.
  2. Erstellen Sie die technische Dokumentation, durchlaufen Sie die Bewertungsroute, stellen Sie die EU-Konformitätserklärung aus und bringen Sie die CE-Kennzeichnung an.
  3. Wo harmonisierte Normen bestehen, bauen Sie danach, um die Konformitätsvermutung in Anspruch zu nehmen.
  4. Bestehende CE-gekennzeichnete Produkte müssen in ihrer Konformität auf die CRA-Anforderungen erweitert werden — eine CE-Kennzeichnung für ein anderes Regime erfüllt den CRA nicht.

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

Schritt 8 — Verträge und Lieferkette

Was zu tun ist. CRA-Pflichten überschreiten Unternehmensgrenzen; regeln Sie sie ausdrücklich in Ihren Verträgen. Überarbeiten Sie Lieferanten-, OEM- und White-Label-Vereinbarungen, um CRA-Pflichten und angemessene Freistellungen zuzuweisen: Wer führt die Risikobewertung durch, wer pflegt die SBOM, wer liefert die Schwachstelleninformationen für die Melde-Uhr und wer haftet für eine nicht konforme Komponente. Entscheiden und dokumentieren Sie, ob Sie einen Bevollmächtigten benennen (Schritt 2). Wenn Sie unter eigener Marke white-labeln, macht Sie die Herstellerfiktion zum Hersteller — unabhängig vom Vertrag zwischen den Parteien.

Rechtsgrundlage: Art. 18, Art. 21 CRA; Art. 13, Art. 14 CRA.

Schritt 9 — Zeitplan und Prioritäten

Was zu tun ist. Ordnen Sie die Arbeit entlang der gesetzlichen Termine. Die Melde-Infrastruktur ist die erste harte Frist (11. September 2026); priorisieren Sie daher den 24h-/72h-/Abschluss-Workflow und die Anbindung an die ENISA Single Reporting Platform vor der breiteren Konformitätsarbeit. Arbeiten Sie anschließend auf die vollständige Compliance bis zum 11. Dezember 2027 hin.

Für Bestandsprodukte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, besteht keine Nachrüstpflicht — es sei denn, das Produkt wird nach diesem Datum wesentlich geändert. Treffen Sie schließlich eine überlegte Entscheidung zur EUCC-Zertifizierung, wo sie für Ihren Markt oder Ihre Beschaffungsanforderungen relevant ist.

Rechtsgrundlage: Art. 71 CRA; Art. 69 Abs. 2 CRA; Art. 3 Nr. 30 CRA.

Schritt 10 — Folgen der Nichtkonformität

Wer die Kehrseite kennt, priorisiert schärfer. Nichtkonformität betrifft nicht nur Bußgelder.

Bußgelder. Es gelten drei Stufen:

  • bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes — bei Verstößen gegen die grundlegenden Anforderungen / Kernpflichten (Art. 64 Abs. 2);
  • bis zu 10 Mio. EUR oder 2 % — bei sonstigen Pflichten (Art. 64 Abs. 3);
  • bis zu 5 Mio. EUR oder 1 % — bei falschen, unvollständigen oder irreführenden Angaben (Art. 64 Abs. 4).

Marktüberwachungsmaßnahmen. Behörden können Korrekturmaßnahmen anordnen, Konformität verlangen, die Bereitstellung beschränken oder verbieten und die Rücknahme oder den Rückruf anordnen — auch bei CE-gekennzeichneten Produkten mit erheblichem Cybersicherheitsrisiko.

Verlust des Marktzugangs. Ohne gültige CE-Kennzeichnung ist ein rechtmäßiges Inverkehrbringen nicht möglich; Produkte können an der Grenze zurückgewiesen werden.

Zivilrechtliche Produkthaftung. Nach der überarbeiteten Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853) sind Software und digitale Elemente ausdrücklich erfasst, und Schwachstellen oder fehlerhafte bzw. unterlassene Updates können einen Produktfehler begründen. Die Einhaltung der CRA-Sicherheitsanforderungen ist ein bei der Fehlerbewertung nach Art. 7 Abs. 2 PLD zu berücksichtigender Umstand — sie begründet keine automatische Fehlervermutung. Umgekehrt stärkt dokumentierte CRA-Konformität die Entlastung des Herstellers.

Rechtsgrundlage: Art. 64 Abs. 2–4, Art. 52–56 CRA; Verordnung (EU) 2019/1020; Richtlinie (EU) 2024/2853.

Compliance-Checkliste

  • Anwendungsbereichs-Check je Produktlinie (Produkt mit digitalen Elementen + Datenverbindung; offline außerhalb; SaaS außerhalb, außer Datenfernverarbeitung).
  • Rolle(n) bestimmen — Hersteller, Einführer, Händler, Bevollmächtigter, Verwalter quelloffener Software — und auf die Herstellerfiktion prüfen.
  • Risikobewertung durchführen und dokumentieren; Anhang I risikobasiert anwenden.
  • 24h-/72h-/Abschluss-Workflow aufbauen; an die ENISA Single Reporting Platform anbinden; zuständiges CSIRT klären.
  • CRA-Meldung mit NIS2 und DSGVO integrieren.
  • Unterstützungszeitraum festlegen, begründen und dokumentieren; Transparenz zum Support-Ende.
  • Lieferanten-Due-Diligence und SBOM (SPDX/CycloneDX).
  • Jedes Produkt klassifizieren; technische Dokumentation; EU-Konformitätserklärung; CE; ggf. notifizierte Stelle.
  • Bestehende CE-Produkte auf CRA-Konformität erweitern.
  • CRA-Pflichten und Freistellungen in Verträgen zuweisen.
  • Über Bevollmächtigten und EUCC-Zertifizierung entscheiden.
  • Bestandsprodukte einplanen (keine Nachrüstung außer bei wesentlicher Änderung).

Zeitplan

Datum Meilenstein Was vorhanden sein muss
10.12.2024 CRA tritt in Kraft Sensibilisierung und internes CRA-Projektmandat; Beginn der Anwendungsbereichsanalyse
11.06.2026 Kapitel IV gilt (Notifizierung der Konformitätsbewertungsstellen) Landschaft der notifizierten Stellen verfügbar; Klassifizierungs-/Bewertungsroutenentscheidungen finalisierbar
11.09.2026 Meldepflichten gelten; ENISA Single Reporting Platform operativ 24h-/72h-/Abschluss-Workflow aktiv; CSIRT-Routing geklärt; integrierte NIS2-/DSGVO-Melde-Governance
11.12.2027 Vollständige Geltung Anhang I Security by Design, Risikobewertung, SBOM, Unterstützungszeitraum, technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung
Laufend Unterstützungszeitraum Sicherheitsupdates und Schwachstellenbehandlung während des (mind. fünfjährigen) Unterstützungszeitraums; Benachrichtigungen zum Support-Ende

Wie SES Berlin unterstützen kann

Der CRA berührt Produktentwicklung, Verträge, Incident Response und Marktzugang zugleich — und viele Details werden noch durch Durchführungsrechtsakte, harmonisierte Normen und Leitlinien der Kommission ausgefüllt. SES Berlin berät Hersteller, Einführer, Händler und Verwalter quelloffener Software zu Anwendungsbereichsanalyse, Rollenklassifizierung, Melde-Governance, Konformitätsbewertung und Lieferkettenverträgen. Wenn Sie einen strukturierten CRA-Readiness-Review für Ihr Produktportfolio wünschen, sprechen Sie uns gerne an.

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

Cyber Resilience Act – Was ist zu tun?

Ein Schritt-für-Schritt-Compliance-Leitfaden für Hersteller, Einführer, Händler und Verwalter quelloffener Software

Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847, „CRA") macht aus Produkt-Cybersicherheit eine verbindliche Rechtspflicht für alle, die „Produkte mit digitalen Elementen" auf dem EU-Markt bereitstellen. Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab dem 11. September 2026; die vollständigen Anforderungen — grundlegende Anforderungen, Risikobewertung, SBOM, EU-Konformitätserklärung und CE-Kennzeichnung — gelten ab dem 11. Dezember 2027. Verstöße können Bußgelder von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, Rücknahme oder Rückruf sowie den Verlust des Marktzugangs auslösen.

Diese Seite beantwortet die praktische Frage, die sich jedes betroffene Unternehmen stellt: Was muss ich eigentlich tun? Sie ist als Roadmap aufgebaut — vom ersten Anwendungsbereichs-Check über Ihre Rolle und deren Pflichten bis hin zu Konformitätsbewertung, Melde-Infrastruktur und den wesentlichen Fristen. Jeder Schritt nennt den einschlägigen CRA-Artikel, damit jede Pflicht auf ihre Grundlage zurückverfolgbar bleibt.

Haftungsausschluss. Diese Seite enthält allgemeine Informationen und stellt keine Rechtsberatung dar. Sie gibt den Rechtsstand von Juli 2026 wieder. Der CRA ist ein neues und sich fortentwickelndes Instrument: Durchführungsrechtsakte, harmonisierte Normen und Leitlinien der Kommission befinden sich noch in Entwicklung, und einzelne Punkte sind noch nicht abschließend geklärt. Handeln Sie nicht allein auf Grundlage dieser Übersicht. Für eine Beratung zu Ihren konkreten Produkten und Ihrer Lieferkette wenden Sie sich bitte an SES Berlin.

Schritt 1 — Anwendungsbereichs-Check: Sind Sie überhaupt erfasst? (Je Produktlinie)

Starten Sie kein unternehmensweites CRA-Projekt, bevor Sie wissen, welche Ihrer Produkte tatsächlich erfasst sind. Führen Sie den Anwendungsbereichs-Check Produktlinie für Produktlinie durch.

Was zu tun ist. Für jedes Produkt zwei kumulative Fragen: (1) Handelt es sich um ein Produkt mit digitalen Elementen — enthält es also Software oder Hardware — und (2) verfügt es über eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz? Beide Voraussetzungen müssen erfüllt sein. Ein rein offline arbeitendes Produkt ohne jede Datenverbindung fällt aus dem CRA heraus.

Achten Sie auf die Grenzfälle:

  • Standalone-SaaS / Cloud-Dienste liegen grundsätzlich außerhalb des CRA und unterfallen stattdessen NIS2, DORA oder der DSGVO — es sei denn, der Dienst ist eine Datenfernverarbeitungslösung im Sinne von Art. 3 Nr. 2, dann gilt er als Teil des Produkts und ist erfasst.
  • Freie und quelloffene Software (FOSS), die außerhalb einer kommerziellen Tätigkeit entwickelt oder bereitgestellt wird, ist ausgenommen; für Verwalter quelloffener Software gilt ein eigener, leichterer Pflichtenkatalog (siehe Schritt 2).
  • Sektorspezifische Regime (Medizinprodukte, Kraftfahrzeuge, Luftfahrt, Maschinen) gehen ganz oder teilweise vor; ein bereits von einem solchen Cybersicherheitsrahmen erfasstes Produkt kann ausgenommen sein.

Rechtsgrundlage: Art. 2, Art. 3 Nr. 1, Art. 3 Nr. 2 CRA; Erwägungsgrund 31.

Schritt 2 — Bestimmen Sie Ihre Rolle und deren Pflichten

Der CRA weist Pflichten nach der Rolle zu. Am selben Produkt können mehrere Wirtschaftsakteure mit jeweils unterschiedlichem Pflichtenkatalog beteiligt sein. Bestimmen Sie zuerst Ihre Rolle (oder Rollen), denn alles Weitere hängt davon ab.

Hersteller (die weitreichendsten Pflichten)

Was zu tun ist. Wer das Produkt entwickelt oder herstellt bzw. entwickeln/herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet, trägt die vollen Herstellerpflichten. Praktisch bedeutet das: eine Cybersicherheits-Risikobewertung vor dem Inverkehrbringen; Entwicklung und Herstellung nach den grundlegenden Anforderungen in Anhang I (Security by Design); ein Verfahren zur Behandlung von Schwachstellen; Pflege einer Software-Stückliste (SBOM); Festlegung und Einhaltung eines Unterstützungszeitraums; Erstellung der technischen Dokumentation; Ausstellung der EU-Konformitätserklärung; und Anbringung der CE-Kennzeichnung.

Rechtsgrundlage: Art. 13 und Art. 14 CRA.

Einführer

Was zu tun ist. Wer ein Produkt eines außerhalb der EU niedergelassenen Herstellers auf dem EU-Markt in Verkehr bringt, muss zuvor prü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. Bringen Sie kein nicht konformes Produkt in Verkehr und werden Sie tätig, wenn Sie Grund zu der Annahme haben, dass ein Produkt nicht konform ist.

Rechtsgrundlage: Art. 19 CRA.

Händler

Was zu tun ist. Vor der Bereitstellung eines Produkts prüfen, dass es die CE-Kennzeichnung trägt und dass Hersteller und Einführer ihre Kennzeichnungs- und Dokumentationspflichten erfüllt haben; dabei mit der gebotenen Sorgfalt im Hinblick auf die anwendbaren Anforderungen vorgehen. Stellen Sie kein Produkt bereit, von dessen Nichtkonformität Sie wissen oder wissen müssten.

Rechtsgrundlage: Art. 20 CRA.

Bevollmächtigter (optional)

Was zu tun ist. Ein Hersteller kann einen in der EU niedergelassenen Bevollmächtigten benennen — dies ist optional, nicht verpflichtend. Für Nicht-EU-Hersteller ohne EU-Einführer ist es praktisch ratsam, weil so ein Wirtschaftsakteur in der Union für Zwecke der Marktüberwachung vorhanden ist (im Einklang mit der Verordnung (EU) 2019/1020). Bei einem Nicht-EU-Hersteller bestimmt die Niederlassung des Bevollmächtigten das für die Meldung zuständige CSIRT.

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

Verwalter quelloffener Software (eine eigenständige, leichtere Rolle)

Was zu tun ist. Wenn Sie eine juristische Person sind (nur juristische Personen kommen in Betracht), die die Entwicklung bestimmter, für eine kommerzielle Nutzung bestimmter FOSS systematisch und nachhaltig unterstützt und deren Brauchbarkeit sichert — etwa eine Stiftung nach dem Muster der Linux-/Python-/Eclipse-Foundation —, sind Sie Verwalter quelloffener Software, nicht Hersteller. Für Sie gilt ein reduzierter Katalog: eine Cybersicherheitsstrategie einrichten, mit den Marktüberwachungsbehörden kooperieren und aktiv ausgenutzte Schwachstellen sowie schwere Vorfälle melden. Sie bringen keine CE-Kennzeichnung an, führen keine Konformitätsbewertung durch und führen die Herstellerdokumentation nicht.

Achten Sie auf das Detail bei den Bußgeldern. Die Bußgeldbefreiung des Verwalters ist nur teilweise: Art. 64 Abs. 10 lit. b nimmt Verwalter nur von den Bußgeldern nach Art. 64 Abs. 3–9 aus. Die Abs.-2-Stufe — bis zu 15 Mio. EUR oder 2,5 % — gilt auch für Verwalter, insbesondere über die Meldepflicht.

Zu beachten: Eine Organisation kann beides sein — Verwalter für ihr Upstream-Projekt und Hersteller für ihre eigene kommerzielle Distribution. Kommerzialisierte quelloffene Software (bezahlter Support, werbefinanziert, Datenverwertung, Dual Licensing) fällt in den vollen Herstellerscope.

Rechtsgrundlage: Art. 3 Nr. 14, Art. 24, Art. 24 Abs. 3, Art. 64 Abs. 2, Art. 64 Abs. 10 lit. b CRA; Erwägungsgründe 18–19.

Die „Herstellerfiktion" — Eigenmarke und wesentliche Änderung

Was zu tun ist. Erkennen Sie, wann Sie zum Hersteller werden, obwohl Sie das Produkt nicht gebaut haben. Wer ein Produkt unter eigenem Namen oder eigener Marke vermarktet oder eine wesentliche Änderung an einem Produkt vornimmt und es dann in Verkehr bringt, übernimmt die vollen Herstellerpflichten. Das ist die Falle für OEM-/White-Label-Wiederverkäufer und Systemintegratoren.

Rechtsgrundlage: Art. 21 CRA; Art. 3 Nr. 30 CRA (Definition der „wesentlichen Änderung").

Schritt 3 — Security by Design und Anhang I

Was zu tun ist. Entwerfen und produzieren Sie jedes erfasste Produkt so, dass es die grundlegenden Cybersicherheitsanforderungen in Anhang I erfüllt, angewendet auf risikobasierter Grundlage. Es gibt keine Einheits-Checkliste: Führen Sie für das konkrete Produkt eine Cybersicherheits-Risikobewertung durch, entscheiden Sie, welche Anhang-I-Anforderungen in welcher Tiefe gelten, setzen Sie sie um und — entscheidend — dokumentieren Sie sowohl die Bewertung als auch die Umsetzung. Der CRA verlangt keinen „Nullzustand" ohne Schwachstellen; er verlangt eine gesteuerte, dokumentierte und dem Produktrisiko angemessene Sicherheit, einschließlich der Behandlung bekannter Schwachstellen.

Rechtsgrundlage: Art. 13 CRA; Anhang I CRA.

Schritt 4 — Behandlung und Meldung von Schwachstellen: der 24h-/72h-/Abschluss-Workflow

Dies ist die erste harte operative Frist (11. September 2026) und der Bereich, der Unternehmen am ehesten unvorbereitet trifft. Bauen Sie den Workflow jetzt auf.

Was zu tun ist. Richten Sie einen internen Prozess ein, der bei Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schweren Vorfalls auslöst und Meldungen auf der gesetzlichen Uhr erzeugt:

  • 24 Stunden — Frühwarnung an das koordinierende CSIRT und ENISA;
  • 72 Stunden — eine ausführlichere Meldung;
  • Abschlussbericht — bei einer Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme; bei einem schweren Vorfall innerhalb eines Monats nach der 72-Stunden-Meldung.

Melden Sie einmal über die ENISA Single Reporting Platform; die Plattform leitet die Meldung an das koordinierende CSIRT und ENISA weiter, und das CSIRT verteilt weiter. Das zuständige CSIRT bestimmt sich nach Ihrer Hauptniederlassung (oder, bei einem Nicht-EU-Hersteller, nach der Niederlassung des Bevollmächtigten). Schwachstellen in Drittkomponenten sind ebenfalls meldepflichtig.

Bauen Sie eine integrierte Melde-Governance. Die CRA-Meldung ist kumulativ mit der Meldung nach NIS2 und DSGVO. Errichten Sie nicht drei isolierte Prozesse, sondern eine einheitliche Incident-Response-Governance, die die richtigen Meldungen an die richtigen Behörden innerhalb der jeweiligen Fristen auslösen kann.

Rechtsgrundlage: Art. 14, Art. 14 Abs. 7, Art. 16, Art. 24 Abs. 3 CRA.

Schritt 5 — Unterstützungszeitraum: festlegen, begründen und dokumentieren

Was zu tun ist. Legen Sie für jedes Produkt den Unterstützungszeitraum fest, in dem Sie Sicherheitsupdates bereitstellen. Die gesetzliche Untergrenze beträgt fünf Jahre — fünf Jahre sind aber ein Mindestwert, kein Standard: Ein kürzerer Zeitraum ist nur zulässig, wenn das Produkt voraussichtlich kürzer genutzt wird, und ein längerer Zeitraum ist erforderlich, wenn die Lebensdauer des Produkts länger ist. Dokumentieren Sie die Begründung. Seien Sie transparent hinsichtlich des Enddatums und benachrichtigen Sie die Nutzer über den bevorstehenden Ablauf.

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

Schritt 6 — Komponenten und SBOM: Sorgfalt gegenüber Lieferanten

Was zu tun ist. Sie sind für das Gesamtprodukt verantwortlich, einschließlich Dritt- und Open-Source-Komponenten. Etablieren Sie eine dokumentierte Due Diligence gegenüber Ihren Lieferanten und Komponenten — prüfen Sie ggf. den CE-Status, die Update-Historie und Schwachstellen-Datenbanken. Erstellen Sie eine maschinenlesbare Software-Stückliste (SBOM), die mindestens die Top-Level-Abhängigkeiten abdeckt, in einem gängigen Format wie SPDX oder CycloneDX, und halten Sie sie als Teil Ihrer technischen Dokumentation für die Marktüberwachung bereit.

Rechtsgrundlage: Art. 13 CRA; Anhang I CRA.

Schritt 7 — Konformitätsbewertung und CE-Kennzeichnung

Was zu tun ist. Führen Sie jedes erfasste Produkt durch Konformitätsbewertung und CE-Kennzeichnung:

  1. Klassifizieren Sie das Produkt. Der Standard ist die Selbstbewertung. Wichtige Produkte (Klasse I und II, Anhang III) und kritische Produkte (Anhang IV) unterliegen strengeren Routen; wo erforderlich, ist eine notifizierte Stelle einzubinden. Der Hersteller legt die Klassifizierung primär fest.
  2. Erstellen Sie die technische Dokumentation, durchlaufen Sie die Bewertungsroute, stellen Sie die EU-Konformitätserklärung aus und bringen Sie die CE-Kennzeichnung an.
  3. Wo harmonisierte Normen bestehen, bauen Sie danach, um die Konformitätsvermutung in Anspruch zu nehmen.
  4. Bestehende CE-gekennzeichnete Produkte müssen in ihrer Konformität auf die CRA-Anforderungen erweitert werden — eine CE-Kennzeichnung für ein anderes Regime erfüllt den CRA nicht.

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

Schritt 8 — Verträge und Lieferkette

Was zu tun ist. CRA-Pflichten überschreiten Unternehmensgrenzen; regeln Sie sie ausdrücklich in Ihren Verträgen. Überarbeiten Sie Lieferanten-, OEM- und White-Label-Vereinbarungen, um CRA-Pflichten und angemessene Freistellungen zuzuweisen: Wer führt die Risikobewertung durch, wer pflegt die SBOM, wer liefert die Schwachstelleninformationen für die Melde-Uhr und wer haftet für eine nicht konforme Komponente. Entscheiden und dokumentieren Sie, ob Sie einen Bevollmächtigten benennen (Schritt 2). Wenn Sie unter eigener Marke white-labeln, macht Sie die Herstellerfiktion zum Hersteller — unabhängig vom Vertrag zwischen den Parteien.

Rechtsgrundlage: Art. 18, Art. 21 CRA; Art. 13, Art. 14 CRA.

Schritt 9 — Zeitplan und Prioritäten

Was zu tun ist. Ordnen Sie die Arbeit entlang der gesetzlichen Termine. Die Melde-Infrastruktur ist die erste harte Frist (11. September 2026); priorisieren Sie daher den 24h-/72h-/Abschluss-Workflow und die Anbindung an die ENISA Single Reporting Platform vor der breiteren Konformitätsarbeit. Arbeiten Sie anschließend auf die vollständige Compliance bis zum 11. Dezember 2027 hin.

Für Bestandsprodukte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, besteht keine Nachrüstpflicht — es sei denn, das Produkt wird nach diesem Datum wesentlich geändert. Treffen Sie schließlich eine überlegte Entscheidung zur EUCC-Zertifizierung, wo sie für Ihren Markt oder Ihre Beschaffungsanforderungen relevant ist.

Rechtsgrundlage: Art. 71 CRA; Art. 69 Abs. 2 CRA; Art. 3 Nr. 30 CRA.

Schritt 10 — Folgen der Nichtkonformität

Wer die Kehrseite kennt, priorisiert schärfer. Nichtkonformität betrifft nicht nur Bußgelder.

Bußgelder. Es gelten drei Stufen:

  • bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes — bei Verstößen gegen die grundlegenden Anforderungen / Kernpflichten (Art. 64 Abs. 2);
  • bis zu 10 Mio. EUR oder 2 % — bei sonstigen Pflichten (Art. 64 Abs. 3);
  • bis zu 5 Mio. EUR oder 1 % — bei falschen, unvollständigen oder irreführenden Angaben (Art. 64 Abs. 4).

Marktüberwachungsmaßnahmen. Behörden können Korrekturmaßnahmen anordnen, Konformität verlangen, die Bereitstellung beschränken oder verbieten und die Rücknahme oder den Rückruf anordnen — auch bei CE-gekennzeichneten Produkten mit erheblichem Cybersicherheitsrisiko.

Verlust des Marktzugangs. Ohne gültige CE-Kennzeichnung ist ein rechtmäßiges Inverkehrbringen nicht möglich; Produkte können an der Grenze zurückgewiesen werden.

Zivilrechtliche Produkthaftung. Nach der überarbeiteten Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853) sind Software und digitale Elemente ausdrücklich erfasst, und Schwachstellen oder fehlerhafte bzw. unterlassene Updates können einen Produktfehler begründen. Die Einhaltung der CRA-Sicherheitsanforderungen ist ein bei der Fehlerbewertung nach Art. 7 Abs. 2 PLD zu berücksichtigender Umstand — sie begründet keine automatische Fehlervermutung. Umgekehrt stärkt dokumentierte CRA-Konformität die Entlastung des Herstellers.

Rechtsgrundlage: Art. 64 Abs. 2–4, Art. 52–56 CRA; Verordnung (EU) 2019/1020; Richtlinie (EU) 2024/2853.

Compliance-Checkliste

  • Anwendungsbereichs-Check je Produktlinie (Produkt mit digitalen Elementen + Datenverbindung; offline außerhalb; SaaS außerhalb, außer Datenfernverarbeitung).
  • Rolle(n) bestimmen — Hersteller, Einführer, Händler, Bevollmächtigter, Verwalter quelloffener Software — und auf die Herstellerfiktion prüfen.
  • Risikobewertung durchführen und dokumentieren; Anhang I risikobasiert anwenden.
  • 24h-/72h-/Abschluss-Workflow aufbauen; an die ENISA Single Reporting Platform anbinden; zuständiges CSIRT klären.
  • CRA-Meldung mit NIS2 und DSGVO integrieren.
  • Unterstützungszeitraum festlegen, begründen und dokumentieren; Transparenz zum Support-Ende.
  • Lieferanten-Due-Diligence und SBOM (SPDX/CycloneDX).
  • Jedes Produkt klassifizieren; technische Dokumentation; EU-Konformitätserklärung; CE; ggf. notifizierte Stelle.
  • Bestehende CE-Produkte auf CRA-Konformität erweitern.
  • CRA-Pflichten und Freistellungen in Verträgen zuweisen.
  • Über Bevollmächtigten und EUCC-Zertifizierung entscheiden.
  • Bestandsprodukte einplanen (keine Nachrüstung außer bei wesentlicher Änderung).

Zeitplan

Datum Meilenstein Was vorhanden sein muss
10.12.2024 CRA tritt in Kraft Sensibilisierung und internes CRA-Projektmandat; Beginn der Anwendungsbereichsanalyse
11.06.2026 Kapitel IV gilt (Notifizierung der Konformitätsbewertungsstellen) Landschaft der notifizierten Stellen verfügbar; Klassifizierungs-/Bewertungsroutenentscheidungen finalisierbar
11.09.2026 Meldepflichten gelten; ENISA Single Reporting Platform operativ 24h-/72h-/Abschluss-Workflow aktiv; CSIRT-Routing geklärt; integrierte NIS2-/DSGVO-Melde-Governance
11.12.2027 Vollständige Geltung Anhang I Security by Design, Risikobewertung, SBOM, Unterstützungszeitraum, technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung
Laufend Unterstützungszeitraum Sicherheitsupdates und Schwachstellenbehandlung während des (mind. fünfjährigen) Unterstützungszeitraums; Benachrichtigungen zum Support-Ende

Wie SES Berlin unterstützen kann

Der CRA berührt Produktentwicklung, Verträge, Incident Response und Marktzugang zugleich — und viele Details werden noch durch Durchführungsrechtsakte, harmonisierte Normen und Leitlinien der Kommission ausgefüllt. SES Berlin berät Hersteller, Einführer, Händler und Verwalter quelloffener Software zu Anwendungsbereichsanalyse, Rollenklassifizierung, Melde-Governance, Konformitätsbewertung und Lieferkettenverträgen. Wenn Sie einen strukturierten CRA-Readiness-Review für Ihr Produktportfolio wünschen, sprechen Sie uns gerne an.

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