02.04.2026

HiGuide: Cyber Resilience Act (CRA) - Erste Meldepflicht greift ab September 2026

Ein Beitrag von Manuel Atug und Rozerin Karaterzi

Die Cyberresilienz-Verordnung1 (Cyber Resilience Act, CRA) vom 23. Oktober 2024 tritt am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft und gilt unmittelbar ab dem 11. Dezember 2027 in jedem EU-Mitgliedstaat. Artikel 14 gilt erst ab dem 11. September 2026 und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.

Ziel und Zweck des CRA

Die Cybersicherheit ist ein Thema von öffentlichem Interesse. Daher muss die Wirtschaft, die Demokratie, die Sicherheit und die Gesundheit der Verbraucherinnen und Verbraucher, die von Cyberattacken betroffen sind, gewährleistet werden. Um das zu gewährleisten, sollen die Cybersicherheitskonzepte der EU gefördert werden. 
Zudem soll für das Inverkehrbringen von Produkten mit digitalen Elementen ein einheitlicher Rechtsrahmen für Cybersicherheitsanforderungen geschaffen werden. Grundsätzlich soll mit der CRA eine Rahmenbedingung für die Entwicklung sicherer Produkte mit digitalen Elementen geschaffen werden, damit Hardware- und Softwareprodukte mit weniger Schwachstellen den Markt betreten können. Somit sorgt diese Verordnung für genaue Bedingungen, die den Nutzenden die Anwendung von Produkten mit digitalen Elementen einrichten und damit die Cybersicherheit sicherstellen.

Geltungsbereich des CRA

Der CRA richtet sich an Produkte mit digitalen Elementen und gibt konkrete Cybersicherheitsanforderungen vor. Zuvor gab es hierzu Lücken und keinen fehlenden allumfassenden Ansatz. Die hohe Nachlässigkeit mit den festgestellten Problemen und Risiken in Bezug auf Cybersicherheit sorgt für große Rechtsunsicherheit bei den Herstellenden der Produkte als auch für die Nutzenden. Daher wurde dieser Bereich auf Unionsebene reguliert.

Zu den betroffenen Produkten, die unter die CRA fallen, gehören:

  • Hardware mit digitalen Elementen (z. B. vernetzte Geräte)
  • Software, wenn sie als Teil eines Produkts mit digitalen Elementen fungiert oder integriert ist
  • Konkrete Dienste zur „Datenfernverarbeitung“, sofern diese Dienste notwendig sind, d. h. das Produkt mit digitalen Elementen muss seine Funktion erfüllen können (z. B. Cloud-Funktionen, die vom Hersteller bereitgestellt werden)

Zu den betroffenen Akteuren, die unter CRA fallen, gehören:

  • Herstellende der Produkte mit digitalen Elementen, d. h. Firmen, die Hard- oder Software entwickeln, produzieren oder zusammensetzen
  • Importeure, die solche Produkte von außerhalb der EU in den Binnenmarkt bringen
  • Händler und Händlerinnen/Vertreibende innerhalb der EU, die solche Produkte verkaufen oder bereitstellen
  • Verwaltende von quelloffener Software, soweit die Software kommerziell angeboten wird oder in Produkten verwendet, wird
  • Firmen außerhalb der EU können ebenso betroffen sein, wenn sie die Produkte mit digitalen Elementen auf dem EU-Markt anbieten.

Im CRA werden Cybersicherheitsrisiken bewusst angegangen. Produkte mit digitalen Elementen können aber auch andere Sicherheitsrisiken beinhalten, welche nicht immer mit Cybersicherheit zusammenhängen, jedoch aus einer Sicherheitsverletzung ergeben können. Somit sorgen einschlägige Harmonisierungsrechtsvorschriften der EU dafür, dass diese Risiken geregelt werden. Im Fall, dass die Harmonisierungsrechtsvorschriften als CRA nicht anwendbar sind, dann soll die Verordnung (EU) 2023/9882 des Europäischen Parlaments und des Rates angewendet werden.

 

Ausnahmen - was nicht im Geltungsbereich erfasst ist

Zu den Produkten, die nicht vom Geltungsbereich der CRA betroffen sind, gehören Geräte, die für militärische oder andere sicherheitsrelevante Absichten erstellt wurden. Diese dienen der nationalen Sicherheit bzw. Verteidigung. Des Weiteren sind Medizinprodukte, Luftfahrt, Fahrzeuge auch vom CRA ausgeschlossen, denn diese stehen bereits unter bestimmten EU-Vorschriften. Es gibt die Ausnahme, dass eine Anpassung in Erwägung gezogen werden kann, sofern das gleiche Schutzniveau sichergestellt ist. Zudem ist z. B. freie und quelloffene Software (Open Source) ebenfalls nicht vom CRA betroffen. Die Ausnahme hierbei besteht im kommerziellen Betrieb bzw. der Vermarktung dieser Software. In dem Fall würde sie unter den CRA fallen. Produkte mit digitalen Elementen, die ausschließlich von der öffentlichen Verwaltung für den Eigenbedarf entwickelt wird sowie Cloud-Dienste, die außerhalb der Verantwortung des Herstellers liegen, sind ebenfalls von der CRA ausgeschlossen.

Anforderungen des CRA an die betroffenen Unternehmen

Die Anforderungen des CRA betreffen hauptsächlich die Herstellenden selbst, denn zu ihren Aufgaben gehören die grundlegende Cybersicherheit. Das bedeutet, Produkte mit digitalen Elementen müssen so gestaltet, entwickelt und hergestellt werden, dass sie ein passendes Sicherheitsniveau erfüllen. Im Anhang I ist vorgesehen, dass die Produkte ohne bekannte ausnutzbare Schwachstelle auf dem Markt bereitgestellt werden und dabei die Sicherheit der Standardkonfiguration zu gewährleisten ist.

Die Schwachstellen müssen durch Updates behoben werden und der Schutz vor unbefugtem Zugriff ist durch Zugriffskontrollen, Authentifizierung, Identitäts- und Zugriffsmanagement sicherzustellen. Abgesehen von den genannten Punkten müssen die verarbeiteten Daten auf eine bestimmte Vertraulichkeit basieren. Das bedeutet, die Verschlüsselung bzw. weitere technischen Maßnahmen müssen realisiert werden. Die Integrität der Daten, die Befehle und Programme sowie die Konfiguration müssen vor Manipulation geschützt und Beschädigungen gemeldet werden. Bei der Datenverarbeitung müssen in dem Zusammenhang die Grundsätze der Datenminimierung berücksichtigt werden. In diesem Fall dürfen die Daten nur dann verarbeitet werden, wenn sie für den Zweck benötigt werden.

Herstellende müssen für die Produkte mit digitalen Elementen eine Konformitätsbewertung umsetzen, damit sie nachweisen können, dass das Produkt die Vorgaben des CRA erfüllt. Dazu gehört auch die Auslegung der EU-Konformitätserklärung. Im Anhang VII steht, dass die Produkte, die konform sind, eine CE-Kennzeichnung tragen müssen und eine technische Dokumentation umgesetzt werden muss. Zudem muss diese Dokumentation die Produktbeschreibung enthalten. Das bedeutet, dass die beabsichtigte Verwendung sowie die Softwareversion und Angaben über das Design, Entwicklung, Produktion und Prozess zur Schwachstellenbehandlung beinhaltet sein müssen. Zudem müssen in der Dokumentation die angewandten Normen, Spezifikationen bzw. Beschreibungen alternativer Lösungen referenziert werden.

Laut Artikel 16 des CRA müssen Herstellende bei Kenntnis von Sicherheitslücken oder Vorfällen im Zusammenhang mit dem Produkt eine Meldung vornehmen. Die Nutzenden dieser Produkte müssen über relevante Sicherheitsupdates oder bekannte Risiken informiert werden. Es soll eine zentrale Meldepflichtplattform eingerichtet werden, über die solche Meldungen erfolgen können.

Umgang mit CRA laut dem BSI

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat auf seiner Webseite einen Informationstext zum Cyber Resilience Act veröffentlicht.3 In diesem Beitrag erläutert das BSI die Zielsetzung und den Anwendungsbereich der europäischen Verordnung und beantwortet dabei wesentliche Fragen, insbesondere zur Betroffenheit von Herstellende, Importeure und Händlern digitaler Produkte. Unterhalb der einführenden Erläuterungen hebt das BSI zudem konkrete Empfehlungen und verbindliche Vorgaben hervor, die als Orientierung für die praktische Umsetzung der CRA-Anforderungen dienen und Unternehmen bei der Vorbereitung auf die neuen regulatorischen Pflichten unterstützen sollen.
 

Zwingende gesetzliche Vorgaben des CRA

  1. Rollenbestimmung: Welche Pflichten auf Sie zukommen, hängt direkt von Ihrer Rolle ab: Sind Sie Hersteller, Importeur oder Händler?
  2. Cybersicherheitsanforderungen (Anhang I):

    - Secure by Default (keine Standardpasswörter, Reset-Möglichkeit)

    - Schutz vor unbefugtem Zugriff (Authentifizierung, Identitätsmanagement)

    - Integritätsschutz (Software/Daten)

  3. Sichere Updates zur Minimierung der Angriffsfläche ("Least Privilege"): Automatische Updates (oder Benachrichtigung), Signaturen, keine Verschlechterung der Sicherheit durch Updates.
  4. Schwachstellenmanagement: 

    - Pflicht zur Behandlung von Schwachstellen während des Support-Zeitraums (min. 5 Jahre oder Produktlebensdauer).

    - Vulnerability Disclosure Policy (VDP) haben

    - Meldepflicht: Meldung aktiv ausgenutzter Schwachstellen & Vorfälle an die Behörde (ab 11.09.2026)

  5. Technische Dokumentation (Anhang VII):

    - Produktbeschreibung & Architektur

    - Risikoanalyse (Assessment of risks)

    - SBOM (Software Bill of Materials) – ist explizit als Teil der Dokumentation gefordert.

  6. Konformitätsbewertung & CE: Durchführen des Verfahrens (Selbstbewertung oder durch Dritte, je nach Produktklasse), Ausstellen der Erklärung, Anbringen des CE-Kennzeichens.
     
  7. Informationen an Nutzer: Sicherheitsrelevante Infos, Support-Dauer (EOL-Datum), Anleitungen

Handlungsempfehlungen des BSI

  1. Gap-Analyse: Das Gesetz verlangt Konformität, sagt aber nicht, dass vorher eine Gap-Analyse erfolgen muss. Es ist aber der logischste erste Schritt.
  2. Spezifische Methoden im SDL (Code Reviews, Penetrationstests): Das Gesetz verlangt, dass das Produkt sicher entwickelt wurde. Wie das geschieht (ob durch Code Review, Pair Programming oder PenTests), ist jedem Unternehmen selbst überlassen (außer bei "Wichtigen/Kritischen Produkten", wo Dritte prüfen). Aber: Ohne PenTests wird die Sorgfaltspflicht kaum nachgewiesen werden können. Vertragliche Absicherung der Lieferkette: Das Gesetz verpflichtet den Hersteller für das Endprodukt. Dass er seine Zulieferer per Vertrag (SLAs, Regress) verpflichtet, ist eine wirtschaftliche/juristische Empfehlung, um nicht auf den Kosten sitzen zu bleiben.
  3. Organisatorisches Setup ("CRA-Programm", Schulungen, KPIs): Das Gesetz schreibt keine Projektstruktur oder Schulungen vor. Aber ohne diese Maßnahmen wird die Umsetzung in großen Firmen vermutlich schwierig.
  4. Audit-Paket bereitstellen: Eine reine Empfehlung zur Prozessoptimierung, damit man bei einer Marktüberwachungsanfrage weiß, was man tun muss.
  5. Nutzung spezifischer Interims-Standards (ISO 27001, OWASP, ETSI): Das Gesetz verlangt die Einhaltung der "Essential Requirements". Solange es keine harmonisierten EU-Normen zum CRA gibt, ist die Nutzung von ETSI oder OWASP eine starke Empfehlung, um den "Stand der Technik" nachzuweisen.

Die Anforderung der ENISA gemäß CRA

Die ENISA (Agentur der Europäischen Union für Cybersicherheit) sollte die Fähigkeiten besitzen, den Prozess der Durchführung des CRA zu unterstützen, insbesondere die Zusammenarbeit der Marktüberwachungsbehörden. Wenn es Hinweise auf mögliche Nichtkonformität von Produkten mit digitalen Elementen mit der CRA gibt, ist der ENISA gestattet, die Produktkategorien zu ermitteln, zu denen Sweeps organisiert werden sollten. 

Auch hat die ENISA weitere Zuständigkeiten, die im CRA gegliedert sind. Zunächst soll die ENISA einheitliche Meldeplattformen einrichten, steuern und aufrechthalten, um die Meldepflichten der Hersteller zu vereinfachen. Außerdem kann die ENISA das Computer Security Incident Response Team (CSIRT) bei der Anwendung von Cybersicherheitsgründen bei verzögerter Meldung unterstützen. 

Zusammenfassend kann festgehalten werden, dass die ENISA geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreift, um die Sicherheit der Meldeplattformen zu gewährleisten und Risiken zu bewältigen. Sie meldet dem CSIRTs-Netzwerk und der Kommission jeden Sicherheitsvorfall, der die Meldeplattform betrifft und unterstützt somit die Kommission, Mitgliedstaaten und Marktüberwachungsbehörden mit technischer Expertise in Bezug auf die Risikobewertung der Produkte mit digitalen Elementen.