Cyber Resilience Act

Der Cyber Resilience Act (CRA) wurde geschaffen, um ein harmonisiertes Regelwerk für die Cyber-Sicherheit von Produkten mit digitalen Elementen in der Europäischen Union zu erstellen. Angesichts der zunehmenden Vernetzung und des Einsatzes von Software und Elektronik in nahezu allen Produktbereichen soll damit ein einheitlich hohes Schutzniveau gegen Cyber-Risiken wie Angriffe, Datenlecks oder Ausfälle gewährleistet werden. Hauptziel ist es, die Widerstandsfähigkeit und Robustheit der Cyber-Sicherheit dieser Produkte über ihren gesamten Lebenszyklus hinweg zu gewährleisten.

Dazu werden verbindliche Sicherheitsanforderungen an die Hersteller festgelegt, wie z.B. Risikoanalysen, Sicherheitsupdates, Meldepflichten für Schwachstellen und Vorfälle sowie langfristiger Support für die Produkte. Besonders kritische Produktkategorien unterliegen zusätzlichen Prüf- und Zertifizierungspflichten. Durch diesen ganzheitlichen Ansatz sollen erhebliche Risiken für Verbraucher, Unternehmen und öffentliche Einrichtungen in einem stark vernetzten europäischen Binnenmarkt minimiert werden.

Geltungsbereich und Umfang des CRAs

Der Cyber Resilience Act gilt im Prinzip für alle Produkte mit digitalen Elementen (also in irgendeiner Software sind oder Software beinhalten), die eine Netzwerk- oder Geräteverbindung haben und in der EU auf den Markt gebracht werden.

Ausgenommen sind jedoch Produkte, die bereits durch andere EU-Rechtsvorschriften wie für Medizinprodukte, Fahrzeuge oder Luftfahrt geregelt werden. Auch Verteidigungsgüter, Ersatzteile und Produkte, für die die Kommission eine Ausnahme erlassen hat, fallen nicht unter diese Verordnung. Im Wesentlichen zielt sie darauf ab, die Cybersicherheitsanforderungen für die meisten vernetzten Produkte in der EU zu harmonisieren und zu stärken.

Eine Sonderrolle im Geltungsbereich nehmen Open Source Software sowie Cloud-Lösungen bzw. Software-as-a-Service (SaaS) ein.

Open Source Software
Open-Source-Software wird explizit in den Anwendungsbereich einbezogen. Artikel 3 Nummer 48 definiert “Free and Open-Source Software” als Software, deren Quellcode offen geteilt wird und unter einer freien und offenen Lizenz zur Verfügung gestellt wird, die es erlaubt, sie frei zugänglich, nutzbar, modifizierbar und weiterverbreitbar zu machen. Für solche Open-Source-Produkte sieht Artikel 24 vor, dass die “Open-Source-Software-Betreuer” eine Cybersecurity-Policy implementieren und mit den Behörden bei der Risikominderung zusammenarbeiten müssen.
Cloud & Software-as-a-Service (SaaS)
Software-as-a-Service (SaaS) und Cloud-Lösungen fallen nur dann unter die Cyber-Resilienz-Verordnung, wenn sie als “Fernverarbeitungslösungen” (remote data processing solutions) im Sinne von Artikel 3 Nummer 2 angesehen werden. Andernfalls wären sie nicht als “Produkt mit digitalen Elementen” gemäß der Definition in Artikel 3 Nummer 1 zu betrachten und folglich nicht von der Verordnung erfasst.

Geltungsbereich des CRAs – Produkte mit digitalen Elementen

Im Wesentlichen fallen alle vernetzten Software-, Hardware- und Elektronikprodukte mit Datenverarbeitungsfunktionen unter den Begriff “Produkte mit digitalen Elementen”.

Gemäß Artikel 2 (“Scope”) gilt der Cyber Resilience Act für:

Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und zu deren bestimmungsgemäßer Verwendung oder vernünftigerweise vorhersehbarer Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz gehört.

Dabei sind “Produkte mit digitalen Elementen” (Artikel 3) jedes Software– oder Hardware-Produkt sowie dessen Lösungen für die Fernverarbeitung von Daten (“remote data processing solution”), einschließlich Software- oder Hardware-Komponenten, die separat in den Verkehr gebracht werden.

Kern der Definition ist, dass es sich um elektronische Informationssysteme handelt, die digitale Daten verarbeiten, speichern oder übertragen können. Dies umfasst sowohl die Software-Komponenten als auch die physischen Hardware-Komponenten.

Die Fernverarbeitungslösungen beziehen sich auf Datenverarbeitung, für deren Software der Hersteller verantwortlich ist und ohne die das Produkt eine seiner Funktionen nicht ausführen kann.

Die Produkte können eine logische (virtuelle) und/oder physische (elektrisch, optisch, mechanisch) Verbindung zu anderen Geräten oder Netzwerken haben, entweder direkt oder indirekt als Teil eines größeren Systems.

Ausnahmen vom Geltungsbereich des CRAs

Der CRA gilt weitestgehend für die meisten Produkte mit digitalen Elementen, die an Geräte oder Netze angeschlossen sind, wenn sie in der EU in Verkehr gebracht werden. Er gilt jedoch nicht für Produkte, die bereits anderweitig reguliert sind. Hierunter fallen:

Produkte mit digitalen Elementen, die unter die Verordnung (EU) 2017/745 über Medizinprodukte fallen (Artikel 2 Absatz 2a).
Produkte mit digitalen Elementen, die unter die Verordnung (EU) 2017/746 über In-vitro-Diagnostika fallen (Artikel 2 Absatz 2b).
Produkte mit digitalen Elementen, die unter die Verordnung (EU) 2019/2144 über Kraftfahrzeuge fallen (Artikel 2 Absatz 2c).
Produkte mit digitalen Elementen, die nach der Verordnung (EU) 2018/1139 über die Flugsicherheit zertifiziert sind (Artikel 2 Absatz 3)
Ausrüstungen, die unter die Richtlinie 2014/90/EU über Schiffsausrüstung fallen (Artikel 2 Absatz 4)
Produkte mit digitalen Elementen, die unter andere EU-Rechtsvorschriften fallen und ein gleichwertiges oder höheres Cybersicherheitsniveau erreichen, wie von der Kommission in delegierten Rechtsakten festgelegt (Artikel 2 Absatz 5).
Ersatzteile, die identische Komponenten in bestehenden Produkten mit digitalen Elementen ersetzen (Artikel 2 Absatz 6)
Produkte, die ausschließlich für Zwecke der nationalen Sicherheit, der Verteidigung oder der Verarbeitung von Verschlusssachen entwickelt oder modifiziert wurden (Artikel 2 Absatz 7).

Pflichten der Hersteller von Produkten

Hersteller von Produkten mit digitalen Elementen haben eine Vielzahl von Pflichten, um die Cybersicherheit und Konformität ihrer Produkte zu gewährleisten. Diese Pflichten umfassen:

Risikomanagement und Konformität mit wesentlichen Anforderungen
Hersteller von Produkten mit digitalen Elementen müssen sicherstellen, dass ihre Produkte in Übereinstimmung mit den wesentlichen Anforderungen entworfen, entwickelt und produziert werden. Diese Anforderungen umfassen die Cybersicherheitsanforderungen gemäß Anhang I, Teil I (Artikel 13(1)).

Für die Einhaltung dieser Verpflichtung müssen Hersteller eine Risikobewertung der Cybersicherheit durchführen und diese während des gesamten Lebenszyklus des Produkts berücksichtigen, einschließlich Planung, Design, Entwicklung, Produktion, Lieferung und Wartung (Artikel 13(2)).

Die Risikobewertung muss dokumentiert und aktualisiert werden und in die technische Dokumentation aufgenommen werden, die bei der Markteinführung erstellt wird (Artikel 13(3)-(4)).

Hersteller müssen bei der Integration von Komponenten, auch von Drittanbietern, sorgfältig vorgehen, um sicherzustellen, dass diese Komponenten die Cybersicherheit des Produkts nicht gefährden. Dies gilt auch für Open-Source-Software, die nicht kommerziell verfügbar gemacht wurde (Artikel 13(5)).

Bereitstellung von Updates und Beheben von Schwachstellen
Beim Identifizieren einer Schwachstelle in einer Komponente, einschließlich Open-Source-Komponenten, müssen Hersteller die Schwachstelle dem Hersteller oder Wartungsanbieter der Komponente melden und Maßnahmen zur Behebung der Schwachstelle ergreifen (Artikel 13(6)).

Hersteller müssen die Cybersicherheitsaspekte der Produkte systematisch dokumentieren und die Risikobewertung entsprechend aktualisieren (Artikel 13(7)).

Hersteller müssen sicherstellen, dass Schwachstellen während der gesamten Supportperiode, die mindestens fünf Jahre betragen muss, effektiv behandelt werden (Artikel 13(8)).

Sicherheitsupdates müssen mindestens zehn Jahre nach Markteinführung oder für die Dauer der Supportperiode verfügbar bleiben (Artikel 13(9)).

Wenn nachfolgende Versionen einer Software eingeführt werden, müssen Hersteller sicherstellen, dass frühere Versionen auf die neueste Version kostenlos aktualisiert werden können (Artikel 13(10)).

Technische Dokumentation und Konformitätsbewertung
Hersteller müssen technische Dokumentationen erstellen, die Konformitätsbewertungsverfahren durchführen oder durchführen lassen und die EU-Konformitätserklärung abgeben sowie das CE-Kennzeichen anbringen (Artikel 13(12)).

Die technische Dokumentation und die EU-Konformitätserklärung müssen mindestens zehn Jahre lang aufbewahrt werden (Artikel 13(13)).

Hersteller müssen sicherstellen, dass Produkte, die als Teil einer Serie produziert werden, weiterhin den Anforderungen entsprechen (Artikel 13(14)).

Produktkennzeichnungen und Informationen für Nutzer
Hersteller müssen sicherstellen, dass ihre Produkte mit einer eindeutigen Identifikationsnummer versehen sind und ihre Kontaktinformationen auf dem Produkt oder der Verpackung angegeben sind (Artikel 13(15)-(16)).

Hersteller müssen einen einzelnen Ansprechpartner benennen, der es den Nutzern ermöglicht, direkt und schnell mit ihnen zu kommunizieren, und sicherstellen, dass dieser Ansprechpartner leicht zu identifizieren ist (Artikel 13(17)).

Produkte müssen mit den erforderlichen Informationen und Anweisungen für die Nutzer versehen sein, die mindestens zehn Jahre lang zur Verfügung stehen müssen (Artikel 13(18)).

Das Ende des Supports muss klar und verständlich zum Zeitpunkt des Kaufs angegeben werden (Artikel 13(19)).

Schließlich müssen Hersteller eine Kopie der EU-Konformitätserklärung oder eine vereinfachte EU-Konformitätserklärung zusammen mit dem Produkt bereitstellen (Artikel 13(20)).

Korrekturmaßnahmen und Kooperation mit Behörden

Hersteller müssen unverzüglich Korrekturmaßnahmen ergreifen, um das Produkt oder die Prozesse in Einklang mit den Anforderungen zu bringen, wenn diese nicht konform sind (Artikel 13(21)).

Auf Anfrage der Marktüberwachungsbehörden müssen Hersteller alle notwendigen Informationen und Dokumentationen bereitstellen und bei den Maßnahmen zur Beseitigung von Cybersicherheitsrisiken kooperieren (Artikel 13(22)).

Hersteller, die ihre Geschäftstätigkeit einstellen, müssen die relevanten Marktüberwachungsbehörden sowie, soweit möglich, die Nutzer über die bevorstehende Einstellung informieren (Artikel 13(23)).

Diese umfassenden Pflichten stellen sicher, dass Hersteller für die Sicherheit und Konformität ihrer digitalen Produkte verantwortlich sind und alle notwendigen Maßnahmen ergreifen, um potenzielle Cybersicherheitsrisiken zu minimieren.

Wesentliche Anforderungen des CRAs

Artikel 13 gibt vor, dass Hersteller von Produkten sicherstellen müssen, dass ihre Produkte in Übereinstimmung mit den wesentlichen Anforderungen entworfen, entwickelt und produziert werden. Diese Anforderungen umfassen die Cybersicherheitsanforderungen gemäß Anhang I, Teil I.

Grundsätzlich verlangt der Cyber Resilience Act einen risikobasierten Ansatz für die Entwicklung von Produkten. Dies zeigt sich insbesondere auch in der ersten Anforderung:

  • Angemessenes Cybersecurity-Niveau basierend auf den Risiken (Teil I, Absatz 1)
    Beispiel: Ein Hersteller führt eine Risikobewertung durch und implementiert entsprechende Sicherheitsmaßnahmen für sein internetfähiges Produkt.

Die weiteren Anforderungen sollen auf Basis der Risikobewertung umgesetzt werden:

  • Keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen (Teil I, Absatz 2a)
    Beispiel: Vor der Markteinführung werden alle bekannten Schwachstellen behoben.
  • Sichere Standardkonfiguration (Teil I, Absatz 2b)
    Beispiel: Das Produkt wird mit deaktivierten unnötigen Diensten und starken Standardpasswörtern ausgeliefert.
  • Schwachstellen durch Sicherheitsupdates adressierbar (Teil I, Absatz 2c)
    Beispiel: Das Produkt benachrichtigt den Nutzer über neue Updates und stellt eine Funktion für (automatische) Sicherheitsupdates bereit.
  • Unautorisierter Zugriff durch Zugriffskontrolle verhindert (Teil I, Absatz 2d)
    Beispiel: Mehrfaktor-Authentifizierung und Benutzer-Zugriffsmanagement werden implementiert.
  • Vertraulichkeit von Daten durch Verschlüsselung geschützt (Teil I, Absatz 2e)
    Beispiel: Gespeicherte und übertragene Daten werden durch Verschlüsselung geschützt.
  • Integrität von Daten, Befehlen und Konfigurationen geschützt (Teil I, Absatz 2f)
    Beispiel: Digitale Signaturen und Integritätsprüfungen werden eingesetzt, um unerlaubte Modifikationen zu erkennen.
  • Datenminimierung (Teil I, Absatz 2g)
    Beispiel: Nur für die Funktionalität erforderliche Daten werden erhoben und verarbeitet.
  • Grundfunktionen auch nach Vorfällen verfügbar (Teil I, Absatz 2h)
    Beispiel: Ausfallsichere, redundante Architektur und DDoS-Schutzmaßnahmen werden implementiert.
  • Minimaler negativer Einfluss auf andere Geräte und Netzwerke (Teil I, Absatz 2i)
    Beispiel: Eingeschränkte Netzwerkzugriffe und Bandbreitenkontrolle werden umgesetzt.
  • Minimierung der Angriffsfläche (Teil I, Absatz 2j)
    Beispiel: Nicht benötigte Ports, Dienste und Schnittstellen werden deaktiviert.
  • Schadensbegrenzung bei Vorfällen (Teil I, Absatz 2k)
    Beispiel: Mechanismen wie Sandboxing, Least-Privilege-Prinzip und Adressraumlayout-Randomisierung (ASLR) werden genutzt.
  • Sicherheitsüberwachung und -protokollierung (Teil I, Absatz 2l)
    Beispiel: Sicherheitsrelevante Ereignisse werden protokolliert und überwacht.
  • Sichere Datenbereinigung (Teil I, Absatz 2m)
    Beispiel: Eine vollständige und sichere Löschung aller Daten und Einstellungen ist für den Nutzer möglich.

Darüber hinaus müssen Hersteller sicherstellen, dass Schwachstellen während der gesamten Supportperiode effektiv behandelt werden.

Die wesentlichen Anforderungen hierzu:

  • Dokumentation von Schwachstellen und Komponenten (Teil II, Absatz 1)
    Beispiel: Ein Software-Teileliste (Software Bill of Material, SBOM) wird in einem gängigen, maschinenlesbaren Format bereitgestellt.
  • Zeitnahe Behebung von Schwachstellen (Teil II, Absatz 2)
    Beispiel: Sicherheitsupdates werden unmittelbar nach Entdeckung einer Schwachstelle veröffentlicht.
  • Regelmäßige Sicherheitstests (Teil II, Absatz 3)
    Beispiel: Penetrationstests und Code-Reviews werden routinemäßig durchgeführt.
  • Offenlegung von behobenen Schwachstellen (Teil II, Absatz 4)
    Beispiel: Details zu Schwachstellen und Sicherheitsupdates werden veröffentlicht.
  • Koordinierte Schwachstellenoffenlegung (Teil II, Absatz 5)
    Beispiel: Eine Richtlinie für die zeitnahe Behebung und kontrollierte Offenlegung von Schwachstellen wird implementiert.
  • Kontaktstelle für Schwachstellenmeldungen (Teil II, Absatz 6)
    Beispiel: Ein sicherer Kommunikationskanal für die Meldung von Schwachstellen wird bereitgestellt.
  • Sichere Verteilung von Updates (Teil II, Absatz 7)
    Beispiel: Sicherheitsupdates werden über verschlüsselte und authentifizierte Kanäle verteilt.
  • Zeitnahe und kostenlose Bereitstellung von Sicherheitsupdates (Teil II, Absatz 8)
    Beispiel: Sicherheitsupdates werden unverzüglich und in der Regel kostenlos zur Verfügung gestellt.

Berichtspflichten des CRAs

Hersteller sind verpflichtet, Schwachstellen und sicherheitsrelevante Vorfälle umfassend und zeitnah zu melden, um die Cyber-Sicherheit ihrer Produkte zu gewährleisten und eine schnelle Reaktion auf potenzielle Bedrohungen zu ermöglichen.

Diese Meldepflichten umfassen die Meldung an das zuständige CSIRT und an ENISA über eine einheitliche Meldeplattform. Die Meldepflichten sind in bestimmte Zeitrahmen unterteilt, um sicherzustellen, dass Informationen über Schwachstellen und sicherheitsrelevante Vorfälle zeitnah und präzise übermittelt werden.

Nachfolgend sind die detaillierten Pflichten der Hersteller, unterteilt nach Schwachstellen und sicherheitsrelevanten Vorfällen, sowie die entsprechenden Zeitrahmen aufgeführt.

Umgang mit Schwachstellen

Hersteller sind verpflichtet, aktiv ausgenutzte Schwachstellen, die in ihren Produkten entdeckt werden, zeitnah zu melden, um die Ausnutzung durch Angreifer zu minimieren und die Sicherheit ihrer Produkte zu gewährleisten. Diese Meldungen müssen innerhalb bestimmter Fristen erfolgen, um sicherzustellen, dass die zuständigen Stellen schnell informiert werden und geeignete Maßnahmen ergreifen können.

Die erste Warnmeldung muss innerhalb von 24 Stunden nach Bekanntwerden der aktiv ausgenutzten Schwachstelle erfolgen. Diese Meldung muss an das zuständige CSIRT und die ENISA erfolgen und eine Frühwarnung über die Schwachstelle einschließlich der betroffenen Mitgliedstaaten, in denen das Produkt verfügbar ist, enthalten (Artikel 14(2)(a)).
Innerhalb von 72 Stunden nach Bekanntwerden der Schwachstelle muss eine detaillierte Schwachstellenmeldung an das zuständige CSIRT und an ENISA erfolgen. Diese Meldung muss allgemeine Informationen über das betroffene Produkt, die allgemeine Natur der Schwachstelle und der Exploits, die ergriffenen Korrektur- oder Gegenmaßnahmen sowie Maßnahmen, die von den Nutzern ergriffen werden können, enthalten. Außerdem muss angegeben werden, wie sensibel die gemeldeten Informationen sind (Artikel 14(2)(b)).
Spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme muss ein Abschlussbericht an das zuständige CSIRT und an ENISA übermittelt werden. Dieser Bericht muss eine detaillierte Beschreibung der Schwachstelle, einschließlich ihres Schweregrads und ihrer Auswirkungen, Informationen über den Angreifer (falls verfügbar) und Einzelheiten über die ergriffenen Korrekturmaßnahmen enthalten (Artikel 14(2)(c)).

Umgang mit sicherheitsrelevanten Vorfällen

Hersteller sind ebenfalls verpflichtet, schwerwiegende Sicherheitsvorfälle, die die Sicherheit ihrer Produkte beeinträchtigen könnten, zu melden. Diese Meldungen müssen innerhalb bestimmter Fristen erfolgen, um sicherzustellen, dass die Auswirkungen solcher Vorkommnisse so gering wie möglich gehalten werden und rasch geeignete Gegenmaßnahmen ergriffen werden können.

Die erste Warnmeldung muss innerhalb von 24 Stunden nach Bekanntwerden des sicherheitsrelevanten Ereignisses erfolgen. Diese Meldung ist an das zuständige CSIRT und die ENISA zu richten und muss eine vorläufige Beschreibung des Vorfalls enthalten, einschließlich der Angabe, ob der Vorfall mutmaßlich auf eine rechtswidrige oder böswillige Handlung zurückzuführen ist, sowie Angaben zu den betroffenen Mitgliedstaaten (Artikel 14(4)(a)).
Innerhalb von 72 Stunden nach Bekanntwerden des Vorfalls muss eine detaillierte Vorfallsmeldung an das zuständige CSIRT und an ENISA erfolgen. Diese Meldung muss allgemeine Informationen über die Art des Vorfalls, eine erste Bewertung des Vorfalls und die ergriffenen Korrektur- oder Gegenmaßnahmen sowie Maßnahmen, die von den Nutzern ergriffen werden können, enthalten. Außerdem ist anzugeben, wie sensibel die gemeldeten Informationen sind (Artikel 14(4)(b)).
Innerhalb eines Monats nach der detaillierten Meldung muss ein Abschlussbericht an das zuständige CSIRT und an ENISA übermittelt werden. Dieser Bericht muss eine detaillierte Beschreibung des Vorfalls, einschließlich seiner Schwere und Auswirkungen, der Art der Bedrohung oder der Ursache des Vorfalls sowie der ergriffenen und laufenden Gegenmaßnahmen enthalten (Artikel 14(4)(c)).

Benachrichtigung der Nutzer

Hersteller müssen die betroffenen Nutzer und, falls erforderlich, alle Nutzer über aktiv ausgenutzte Schwachstellen oder Sicherheitsvorfälle informieren. Diese Informationen umfassen auch Risikominderungs- und Abhilfemaßnahmen, die von den Nutzern ergriffen werden können (Artikel 14(8)).

Pflichten weiterer Akteure

Neben den Herstellern der Produkte definiert der Cyber Resilience Act zusätzliche Anforderungen an Importeure und Händler von Produkten sowie Verwalter von Open-Source-Software.

Gemäß Artikel 19 dürfen Importeure nur Produkte auf den Markt bringen, die den wesentlichen Anforderungen entsprechen. Sie müssen sicherstellen, dass der Hersteller die Konformitätsbewertungsverfahren durchgeführt hat, die technische Dokumentation vorhanden ist und das CE-Kennzeichen angebracht wurde. Außerdem müssen sie ihren Namen und ihre Kontaktinformationen auf dem Produkt, der Verpackung oder in den Begleitdokumenten angeben. Im Falle von Nichtkonformität oder Sicherheitsrisiken müssen sie Maßnahmen ergreifen und die zuständigen Behörden informieren. Die EU-Konformitätserklärung und die technische Dokumentation müssen mindestens 10 Jahre lang aufbewahrt werden, und Importeure müssen bei Anfragen der Marktüberwachungsbehörden kooperieren.
Gemäß Artikel 20 müssen Händler (“distributors”) mit Sorgfalt handeln und sicherstellen, dass das Produkt die CE-Kennzeichnung trägt und die Anforderungen erfüllt. Sie müssen überprüfen, ob der Hersteller und der Importeur die erforderlichen Informationen und Kennzeichnungen bereitgestellt haben. Bei Verdacht auf Nichtkonformität oder Sicherheitsrisiken dürfen sie das Produkt nicht auf den Markt bringen und müssen den Hersteller und die Marktüberwachungsbehörden informieren. Händler müssen auch bei Anfragen der Behörden kooperieren und die relevanten Informationen zur Verfügung stellen.

Der Cyber Resilience Act (CRA) berücksichtigt auch die besondere Rolle von Open-Source-Software (FOSS) im digitalen Ökosystem. Für FOSS-Projekte gelten grundsätzlich weniger strenge Anforderungen, da sie in die Kategorie der Selbstbewertung fallen. Der CRA führt zudem den Begriff des “Open-Source-Software-Stewards” ein, der für juristische Personen gilt, die FOSS-Projekte unterstützen, ohne sie direkt zu monetarisieren.

Diese Verwalter von Open-Source-Software haben spezifische, wenn auch weniger umfangreiche Verpflichtungen als kommerzielle Softwarehersteller. Gemäß Artikel 24 müssen Verwalter von Open-Source-Software eine Cybersicherheitsrichtlinie einführen und dokumentieren, die die sichere Entwicklung und Handhabung von Schwachstellen fördert. Sie müssen mit den Marktüberwachungsbehörden zusammenarbeiten und die erforderliche Dokumentation auf Anfrage zur Verfügung stellen. Verwalter sind verpflichtet, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle zu melden, soweit sie an der Entwicklung der Produkte beteiligt sind oder diese Vorfälle ihre Systeme betreffen.

Die genauen Auswirkungen des CRA auf die Open-Source-Gemeinschaft und die damit verbundenen Herausforderungen und Chancen werden in unserem ausführlichen Artikel “Der Cyber Resilience Act und seine Auswirkungen auf Open-Source-Software” näher beleuchtet.

Nichteinhaltung des CRAs

Die möglichen Sanktionen und Konsequenzen bei Nichteinhaltung der Anforderungen des Cyber Resilience Act sind streng strukturiert und auf verschiedene Arten von Verstößen zugeschnitten, um die Sicherheit von Produkten zu gewährleisten:

  • Nichteinhaltung wesentlicher Anforderungen: Die Nichteinhaltung der in Anhang I festgelegten wesentlichen Anforderungen an die Cybersicherheit oder die Nichteinhaltung der Verpflichtungen der Hersteller gemäß Artikel 13 und 14 kann mit Geldbußen von bis zu 15 Millionen Euro oder bis zu 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahrs geahndet werden, je nachdem, welcher Betrag höher ist.
  • Verstöße gegen Verfahrens- und Kennzeichnungspflichten: Verstöße gegen Vorschriften wie die ordnungsgemäße Anbringung der CE-Kennzeichnung, das Vorliegen der EU-Konformitätserklärung oder die Pflicht zur technischen Dokumentation können mit Geldbußen von bis zu 10 Millionen Euro oder bis zu 2 % des weltweiten Jahresumsatzes geahndet werden. In diese Kategorie fällt auch die Nichteinhaltung der Anforderungen an Importeure und Händler.
  • Falschangaben und Irreführung: Die Erteilung unrichtiger, unvollständiger oder irreführender Auskünfte an benannte Stellen und Marktüberwachungsbehörden, insbesondere bei der Beantwortung von Auskunftsverlangen dieser Behörden, kann mit Geldbußen bis zu 5 Millionen Euro oder bis zu 1 % des weltweiten Jahresumsatzes geahndet werden.

Bei der Festsetzung der Höhe der Geldbußen werden in jedem Einzelfall Art, Schwere und Dauer des Verstoßes sowie die wirtschaftlichen Auswirkungen auf den betroffenen Markt berücksichtigt. Ziel dieser Sanktionen ist es, eine starke abschreckende Wirkung zu erzielen und gleichzeitig die Verhältnismäßigkeit zu wahren, um die Sicherheit im digitalen Binnenmarkt der EU zu erhöhen.

Umsetzung des CRAs und die IEC 62443

Die IEC 62443-Normenreihe spielt eine wichtige Rolle bei der Umsetzung des Cyber Resilience Acts (CRA). Wie das vereinfachte Schaubild zeigt, adressieren insbesondere die Teile IEC 62443-4-1, IEC 62443-4-2 und IEC 62443-3-3 zentrale Anforderungen des CRA in den Bereichen Sicherheitsanforderungen und Schwachstellenmanagement.

Das von der ENISA veröffentlichte detaillierte Mapping der Anforderungen des CRAs zu verschiedenen Normen und Standards bestätigt diese Relevanz. Es zeigt auf, wie die IEC 62443 viele der CRA-Anforderungen abdeckt, insbesondere im Bereich der Industrieautomation und Steuerungssysteme. Die Normenreihe bietet somit einen wertvollen Rahmen für Hersteller, um die Vorgaben des CRA systematisch umzusetzen. Gleichzeitig weist das ENISA-Mapping auch auf Lücken hin, die durch weitere Standardisierungsarbeit geschlossen werden müssen.

Insgesamt unterstützt die IEC 62443 Unternehmen dabei, den regulatorischen Anforderungen des CRA gerecht zu werden und die Cybersicherheit ihrer Produkte zu verbessern.

Konformität mit dem CRA

Der Cyber Resilience Act (CRA) führt ein umfassendes System zur Bewertung und Sicherstellung der Konformität von Produkten mit digitalen Elementen ein. Dieses System zielt darauf ab, ein hohes Niveau an Cybersicherheit und Resilienz im gesamten EU-Binnenmarkt zu gewährleisten. Die Konformitätsbewertung ist ein zentraler Bestandteil des CRA und variiert je nach Risikoeinstufung und Kritikalität des jeweiligen Produkts.

Welches Konformitätsbewertungsverfahren dabei zu wählen ist, hängt von der Risikostufe des Produkts ab.

Produkte mit digitalen Elementen (Artikel 6) bilden die Grundkategorie. Diese Produkte müssen die grundlegenden Anforderungen aus Anhang I, Teil I erfüllen, wobei auch die Herstellungsprozesse den Anforderungen aus Anhang I, Teil II entsprechen müssen. Für diese Kategorie sind keine spezifischen Konformitätsbewertungsverfahren vorgeschrieben, jedoch müssen die Hersteller sicherstellen, dass ihre Produkte bei ordnungsgemäßer Installation, Wartung und bestimmungsgemäßer Verwendung den Sicherheitsanforderungen genügen.

Wichtige Produkte mit digitalen Elementen (Artikel 7) stellen die zweite Kategorie dar. Diese Produkte werden durch ihre Kernfunktionalitäten definiert, die den in Anhang III aufgeführten Kategorien entsprechen. Sie müssen spezielle Konformitätsbewertungsverfahren durchlaufen, um die Einhaltung der wesentlichen Cybersicherheitsanforderungen zu gewährleisten.

Die Kategorien wichtiger Produkte werden in Klasse I und Klasse II unterteilt, wie in Anhang III dargelegt. Diese Klassen basieren auf:

  • Klasse I: Produkte, die für die Cybersicherheit von entscheidender Bedeutung sind, einschließlich der Sicherung der Authentifizierung, der Verhinderung von Eindringlingen, der Endpunktsicherheit etc.
  • Klasse II: Produkte, die ein erhebliches Risiko nachteiliger Auswirkungen haben, wie Netzwerkmanagement, Konfigurationskontrolle, Virtualisierung oder die Verarbeitung personenbezogener Daten.

Für wichtige Produkte der Klasse I gilt: Werden harmonisierte Normen oder europäische Zertifizierungssysteme für Cybersicherheit nicht oder nur teilweise angewandt, müssen das Produkt und seine Herstellungsverfahren entweder einem EU-Baumusterprüfung (Modul B) in Verbindung mit interner Produktionskontrolle (Modul C) oder einer umfassenden Qualitätssicherung (Modul H) unterzogen werden.

Bei wichtigen Produkten der Klasse II muss der Hersteller die Konformität mit den grundlegenden Anforderungen durch ähnliche Verfahren oder gegebenenfalls durch eine europäische Zertifizierung für Cybersicherheit nach dem Cybersecurity Act nachweisen. Hierbei ist wichtig, dass die Integration eines solchen Produkts in ein anderes Produkt nicht automatisch dazu führt, dass letzteres denselben Bewertungsverfahren unterliegt.

Die dritte Kategorie umfasst kritische Produkte mit digitalen Elementen (Artikel 8). Diese Produkte werden durch delegierte Rechtsakte der Europäischen Kommission definiert. Sie müssen über Kernfunktionen verfügen, die in Anhang IIIa der Verordnung aufgeführt sind.

Kritische Produkte müssen ein europäisches Cybersicherheitszertifikat nach dem Cybersecurity Act mit einem Sicherheitsniveau (assurance level) von wesentlich oder höher erhalten. Zu den Kriterien für die Identifizierung dieser Produkte gehören ihre kritische Abhängigkeit durch wichtige Einrichtungen und das Potenzial für eine schwerwiegende Unterbrechung kritischer Lieferketten im gesamten Binnenmarkt.

Für wichtige Produkte (Artikel 6) kann Anhang III durch delegierte Rechtsakte geändert werden, indem auf der Grundlage der Cybersicherheitsfunktionen und -risiken dieser Produkte neue Kategorien hinzugefügt oder bestehende Kategorien geändert werden. Beim Erlass dieser Rechtsakte müssen die Auswirkungen auf den Markt und die Bereitschaft der Mitgliedstaaten zur Einführung von Zertifizierungssystemen berücksichtigt werden.

Für kritische Produkte (Artikel 6a) kann die Kommission ebenfalls über delegierte Rechtsakte festlegen, welche Produkte ein europäisches Cybersicherheitszertifikat benötigen. In den Rechtsakten muss dabei auch das Sicherheitsniveau festgelegt werden, das den Cybersicherheitsrisiken und dem Verwendungszweck des Produkts angemessen ist.

Konformitätsbewertungsverfahren im CRA

Der Cyber Resilience Act (CRA) sieht verschiedene Konformitätsbewertungsverfahren für Produkte mit digitalen Elementen vor, um die Konformität mit den grundlegenden Anforderungen gemäß Anhang I sicherzustellen. Diese Verfahren umfassen

Interne Kontrolle
Dies ist das einfachste Verfahren, bei dem der Hersteller die Konformität seines Produkts intern überprüft und dokumentiert (Anhang VIII, Modul A).
EU-Baumusterprüfung
Dies ist eine unabhängige Prüfung des Produktdesigns durch eine benannte Stelle, gefolgt von einer internen Fertigungskontrolle durch den Hersteller (Anhang VIII, Module B und C). Dies ist insbesondere für wichtige Produkte der Klasse I vorgesehen, wenn harmonisierte Normen, gemeinsame Spezifikationen oder europäische Cybersicherheitszertifizierungen nicht vollständig angewendet wurden oder nicht vorhanden sind.
Umfassende Qualitätssicherung
Bei der Konformitätsbewertung auf der Grundlage einer umfassenden Qualitätssicherung (Anhang VIII, Modul H) übernimmt eine benannte Stelle die umfassende Qualitätskontrolle des Herstellungsprozesses.
Europäische Cybersecurity-Zertifizierung

Für kritische Produkte, die in Anhang IV aufgeführt sind, ist eine Zertifizierung nach dem Cybersecurity Act erforderlich, um die Konformität mit den grundlegenden Anforderungen nachzuweisen, sofern verfügbar und anwendbar (Artikel 8(1)). Die Zertifizierung muss mindestens ein „erhebliches“ (“substantial”) Sicherheitsniveau erreichen und kann die Einbeziehung einer benannten

Weitere Informationen zu den einzelnen Konformitätsbewertungsverfahren gibt es in unserem Beitrag zur CE-Kennzeichnung.

Auswahl des Konformitätsbewertungsverfahrens

Produkte aller Kategorien, einschließlich unkritischer, wichtiger (sowohl Klasse I als auch II) und kritischer Produkte, können potenziell durch das Cybersicherheits-Zertifizierungssystem des Gesetzes zertifiziert werden. Für wichtige Produkte, die nicht den harmonisierten Normen entsprechen, und für kritische Produkte, für die kein entsprechendes Zertifizierungssystem angenommen wurde, ist die Einschaltung einer benannten Stelle erforderlich (Module B+C oder H). Die Methode der internen Fertigungskontrolle (Modul A) gilt in erster Linie für unkritische Produkte und für wichtige Produkte der Klasse I, jedoch nur in Fällen, in denen eine harmonisierte Norm umfassend angewandt wurde.

Das folgende Diagramm stellt den Entscheidungsprozess für die Auswahl des geeigneten Verfahrens nach dem Cyber Resilience Act dar.

Entscheidungsbaum für die Auswahl des Konformitäts-Verfahrens nach dem Cyber Resilience Act

Diese Unterscheidung stellt sicher, dass der Grad der Überprüfung und Bewertung dem potenziellen Cybersicherheitsrisiko der jeweiligen Produktkategorie angemessen ist.

ProdukttypInterne Kontrolle (Modul A)EU-Baumusterprüfung (Modul B+C)Umfassende Qualitätssicherung (Modul H)Cybersecurity Zertifikat
Unkritisch
Wichtig – Klasse I
(Anhang III)
(✓)1)
Wichtig – Klasse II
(Anhang III)
Kritisch
(Anhang IIIa)
(✓)2)(✓)2)
1) Die Verwendung einer harmonisierten Norm ist erforderlich, um eine vollständige Übereinstimmung zu erreichen.
2) Nur möglich, wenn für die Produktkategorie kein delegierter Rechtsakt erlassen wurde, der ein Zertifikat vorschreibt.

Aktueller Stand des CRAs

Der erste Entwurf des Cyber Resilience Act wurde am 15. September 2022 von der Europäischen Kommission vorgelegt. Der Europäische Wirtschafts- und Sozialausschuss (EWSA) gab im Dezember 2022 seine Stellungnahme zu diesem Vorschlag ab. Im Europäischen Parlament wurde der Bericht im Juli 2023 vom Ausschuss für Industrie, Forschung und Energie (ITRE) angenommen. Im Rat der Europäischen Union wurde im Juli 2023 ein gemeinsamer Standpunkt erzielt. Am 30. November 2023 einigten sich die Mitgesetzgeber (Parlament, Rat und Kommission) im Trilog auf einen vorläufigen Text. Der ITRE-Ausschuss billigte die Einigung im Januar 2024 und das Parlament stimmte am 12. März 2024 zu. Der Rat muss den Text jetzt noch formell annehmen, bevor das Gesetz in Kraft treten kann.

Häufig gestellte Fragen (FAQ) zum CRA

Was ist der Zusammenhang zwischen CRA und Funkanlagenrichtlinie (RED)?

Der Cyber Resilience Act baut auf bestehenden EU-Regulierungen wie der Funkanlagenrichtlinie (RED) und dessen delegierten Rechtsakt auf und erweitert deren Anwendungsbereich. Während die RED spezifische Anforderungen für drahtlose Geräte festlegt, adressiert der CRA die Cybersicherheit für ein breiteres Spektrum von Produkten mit digitalen Elementen.

Der CRA wird nach seinem Inkrafttreten voraussichtlich den delegierten Rechtsakt der RED für Cybersicherheit ersetzen. Für mehr Informationen zur RED und ihren aktuellen Sicherheitsanforderungen empfehlen wir unseren Beitrag zur Funkanlagenrichtlinie. Zur Umsetzung der Anforderungen des delegierten Rechtsakts mittels harmonisierter Normen empfehlen wir den Beitrag zur EN 18031.

Ändern sich die Anforderungen des CRAs mit der Kritikalität der Produkte?

Nein, die grundlegenden Anforderungen des CRAs ändern sich nicht mit der Kritikalität der Produkte. Die Anforderungen selbst bleiben für jede Produktkategorie gleich. Allerdings ändert sich das Konformitätsbewertungsverfahren je nach Kritikalität des Produkts.

Bei wichtigen und kritischen Produkten:

  • wird der Bewertungsprozess in der Regel umfangreicher und detaillierter sein
  • können strengere Kriterien für die Risikobewertung angewandt werden
  • ist eine externe Validierung oder Zertifizierung erforderlich

Die Tiefe der Analyse und die Strenge der Bewertungskriterien passen sich also an die Kritikalität an, während die grundlegenden Anforderungen des CRAs gleich bleiben.

Bis wann muss mein Unternehmen / müssen meine Produkte konform sein?

Die Konformität mit dem Cyber Resilience Act (CRA) muss grundsätzlich 36 Monate nach Inkrafttreten der Verordnung erreicht sein. Dies ist der Zeitpunkt, ab dem die Verordnung vollständig anwendbar wird.

Allerdings gibt es einige wichtige Ausnahmen und gestaffelte Fristen:

  • Produkte, die vor dem Datum der vollen Anwendbarkeit (36 Monate nach Inkrafttreten) auf den Markt gebracht wurden, müssen nur dann die Anforderungen erfüllen, wenn sie ab diesem Datum wesentlich modifiziert werden.
  • Artikel 14 (Berichts- bzw. Meldepflichten) wird bereits 21 Monate nach Inkrafttreten anwendbar. Allerdings gelten die Verpflichtungen aus Artikel 14 für alle Produkte im Geltungsbereich, auch wenn sie vor der vollen Anwendbarkeit auf den Markt gebracht wurden.
  • Bestehende EU-Typprüfbescheinigungen und Genehmigungsentscheidungen bezüglich Cybersicherheitsanforderungen bleiben bis 42 Monate nach Inkrafttreten gültig, es sei denn, sie laufen vorher ab oder andere EU-Harmonisierungsvorschriften sehen etwas anderes vor.
  • Kapitel IV mit den Artikeln 35 bis 51 (Benannte Stellen) wird schon 18 Monate nach Inkrafttreten anwendbar.

Es ist wichtig zu beachten, dass diese Fristen ab dem Datum des Inkrafttretens der Verordnung gelten, welches zum jetzigen Zeitpunkt noch nicht feststeht.

Unterstützung bei der Umsetzung des CRAs

Die Umsetzung der Anforderungen des Cyber Resilience Acts (CRA) stellt für viele Unternehmen eine komplexe Herausforderung dar. Unser erfahrenes Team von Cybersecurity-Experten bietet umfassende Unterstützung bei der Implementierung und Einhaltung dieser wichtigen Vorschrift:

  • Analyse Ihrer Produkte und Prozesse auf CRA-Konformität
  • Entwicklung maßgeschneiderter Implementierungsstrategien zur Erfüllung der CRA-Anforderungen
  • Unterstützung bei der Integration von Cybersicherheitsmaßnahmen in den Entwicklungszyklus
  • Implementierung technischer Anforderungen, wie sichere Boot- und Updateprozesse sowie Verschlüsselung
  • Durchführung technischer Tests, wie Penetrationstests und Schwachstellenanalysen
  • Begleitung bei Zulassungen und Zertifizierungen sowie der Erstellung der notwendigen Dokumentation

Wir verstehen die individuellen Anforderungen verschiedener Branchen und passen unsere Beratungsleistungen Ihren spezifischen Bedürfnissen an. Unser Ziel ist es, Ihnen nicht nur bei der Einhaltung des CRA zu helfen, sondern auch die Sicherheit und Resilienz Ihrer Produkte nachhaltig zu stärken.

Kontaktieren Sie uns für ein unverbindliches Erstgespräch, in dem wir gemeinsam besprechen, wie wir Sie bei der effizienten und effektiven Umsetzung des Cyber Resilience Acts unterstützen können.