Europäisches Parlament und Rat einigen sich vorläufig auf finale Fassung des Cyber Resilience Acts

Über ein Jahr ist vergangen, seit die Europäische Kommission am 19. September 2022 ihren Vorschlag für eine Verordnung über horizontale Cybersicherheitsanforderungen für digitale Produkte (sog. Cyber Resilience Act, kurz: CRA) veröffentlicht hat.

Seither wurde ausgiebig und kontrovers über das ambitionierte Gesetzesvorhaben diskutiert. Nachdem sich bereits im Oktober dieses Jahres abzeichnete, dass sich die Trilog-Verhandlungen auf der Zielgeraden befinden, haben sich das Europäische Parlament und der Rat nun am Freitag, den 30. November bereits in der dritten Verhandlungsrunde vorläufig auf die finale Fassung des Verordnungstextes geeinigt. Einer Verabschiedung und Veröffentlichung des CRA im Amtsblatt der Europäischen Union vor den Wahlen zum Europäischen Parlament im Juni 2024 dürfte damit nichts mehr im Wege stehen.

In inhaltlicher Sicht soll der vereinbarte Kompromiss gegenüber dem ursprünglichen Kommissionsentwurf (nachfolgend bezeichnet als CRA-E) Änderungen in verschiedenen Regelungsbereichen aufweisen. Hinsichtlich des Anwendungsbereichs scheint nunmehr klar, dass SaaS nicht in den Anwendungsbereich des CRA, sondern ausschließlich unter NIS2 fallen soll (vorausgesetzt die dortigen Anwendungsvoraussetzungen liegen vor).

Nachfolgend werden die wesentlichen weiteren Änderungen, die bis dato nach außen gedrungen sind, kurz überblicksartig dargestellt.

Überarbeitung der Produktklassifikation

Diskutiert und überarbeitet wurde insbesondere die über die Notwendigkeit einer „Drittzertifizierung“ entscheidende, von der Europäischen Kommission in Anhang III CRA-E vorgeschlagene Allokation von Produkten zu den Kritikalitätsklassen I und II.

Der Europäische Rat hatte bereits im Februar 2023 neben einer umfassenden Anpassung der ursprünglichen Kataloge (mittels Herauf- und Herabstufung, Ausweitung und Neuaufnahme von Produktkategorien) die Aufnahme einer zusätzlichen Untergliederung in Abhängigkeit davon, ob das jeweilige Produkt bestimmte Funktionen (i.e. Cybersicherheitsfunktionen oder zentrale Systemfunktionen) realisiert oder in sensiblen Umgebungen eingesetzt wird, gefordert.

Geeinigt scheint man sich nunmehr darauf zu haben, dass die Kritikalitätsklasse I, für die laut CRA-E das Verfahren der internen Fertigungskontrolle nur bei lückenloser Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder europäischer Zertifizierungsschemata für Cybersicherheit angewendet werden kann, in der finalen Fassung des CRA folgende Produktkategorien umfassen soll:

• Betriebssysteme,
• Boot-Manager,
• Browser,
• Identitätsmanagementsysteme,
• Mikroprozessoren,
• Mikrosteuerungen mit sicherheitsrelevanten Funktionen und anwendungsspezifische Schaltkreise,
• Netzwerkmanagementsysteme,
• Netzwerkschnittstellen,
• Passwortmanager,
• Router,
• Software zur Ausstellung digitaler Zertifikate,
• Software zur Erkennung von Malware,
• Systeme zur Verwaltung von Sicherheitsinformationen und Ereignissen,
• Verbraucherprodukte (wie Smart-Home-Systeme, mit dem Internet verbundenes Spielzeug und persönliche Wearables), sowie
• virtuelle private Netzwerke (VPNs).

Unter die Kritikalitätsklasse II, für deren Produkte die Durchführung eines Konformitäts bewertungsverfahrens durch eine benannte Stelle, mithin eines Dritten, in jedem Fall verpflichtend vorgeschrieben sein soll, sollen

• Container-Laufzeitsysteme,
• Firewalls,
• Hypervisoren, und
• manipulationssichere Mikroprozessoren und Steuerungen fallen.

Darüber hinaus soll durch den Rat eine zusätzliche Liste kritischer Produkte eingeführt worden sein, für die künftig ein Cybersicherheitszertifikat verlangt werden kann. Unter diese Kategorie sollen insbesondere intelligente Messgeräte und Smartcards fallen.

Differenzierende Regelungen zu Open-Source-Software

Umfangreich diskutiert und verhandelt wurde auch die Ausgestaltung der Regelungen zu Open-Source-Software. Die Kommission hatte hierfür in dem ursprünglichen CRA-E laut EG 10 eine Bereichsausnahme über den Bereitstellensbegriff vorgesehen (ein die Anwendung des CRA-E auslösendes Bereitstellen auf dem Markt liegt gemäß Artikel 3 Nr. 23 CRA-E nur dann vor, wenn dies „im Rahmen einer Geschäftstätigkeit erfolgt“).

Dieser Mechanismus, der angesichts der mannigfaltigen Entwicklungsmodelle von Open-Source-Software einen weiten Interpretationsspielraum zulässt und erhebliche Rechts unsicherheiten birgt, soll nun in der finalen Fassung durch einen differenzierenden Ansatz ersetzt werden. Letzterer soll folgende Fallgruppen vorsehen:

1. Open-Source-Software, die von einem kommerziellen Unternehmen entwickelt, kontrolliert und in Produkte einbettet wird, soll vollumfänglich unter die Anforderungen des CRA fallen.
2. Open-Source-Software, die gemeinsam unter dem Schirm einer unterstützenden Organisation entwickelt wird, soll vereinfachten Anforderungen (insbesondere keine CE-Kennzeichnung) und einem abgemildertes Sanktionsregime (insbesondere keine Geldstrafen) unterliegen. Für diese Kategorie soll die Rechtsfigur des Verwalters eingeführt werden, dem Dokumentationspflichten und die Verantwortung für den Umgang mit Schwachstellen obliegen.
3. Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit bereitgestellt und in Zusammenarbeit entwickelt wird, ohne dass eine Stelle darüber entscheidet, was in den Programmcode aufgenommen wird, soll vom Anwendungsbereich der Verordnung ausgenommen werden.

Darüber hinaus sollen individuelle Entwickler, die Beiträge zu Open-Source-Projekten leisten, explizit nicht als „Hersteller“ im Sinne des CRA und Einrichtungen, die Open-Source-Software in ihren offenen Repositories hosten, nicht als „Vertreiber“ i.S.d. CRA gelten, wenn die Software unter einer freien Lizenz bereitgestellt wird.

Unterstützungszeitraum von mindestens fünf Jahren

Gegenstand der Trilog-Verhandlungen war auch der Zeitraum, innerhalb dessen im Falle des Auftretens von Schwachstellen Sicherheitsupdates durch den Hersteller bereitgestellt werden müssen (sog. Unterstützungszeitraum). Der Kommissionsvorschlag sah diesbezüglich einen maximalen Zeitraum von fünf Jahren (ab Inverkehrbringen) sowie im Falle einer kürzeren Produktlebensdauer einen entsprechend kürzeren Zeitraum vor.

Die finale Fassung soll im Ausgangspunkt ebenfalls an die Produktlebensdauer anknüpfen. Im Gegensatz zu dem Kommissionsentwurf soll in dem vereinbarten Kompromiss jedoch ein Mindestzeitraum von fünf Jahren enthalten sein. Kürzere Unterstützungszeiträume sollen nur dann möglich sein, wenn das Produkt erwartungsgemäß weniger als fünf Jahre in Gebrauch sein wird.

Der erwartete Gebrauchszeitraum soll von dem jeweiligen Hersteller unter Berücksichtigung der voraussichtlichen Nutzungsdauer, der Erwartungshaltung der Nutzer, der Art des Produkts, seines Zwecks und dem Unterstützungszeitraum für ähnliche Produkte auf dem Markt festgelegt und in den technischen Unterlagen dokumentiert werden. Er soll zudem auf der Verpackung des jeweiligen Produktes angegeben werden müssen. Die finale Entwurfsfassung setzt damit auch stark auf wettbewerbliche Mechanismen, um Hersteller zu möglichst langen Unterstützungszeiträumen zu motivieren.

Sicherheitsaktualisierungen, die während des Unterstützungszeitraums zur Verfügung gestellt werden, sollen schließlich mindestens 10 Jahre nach ihrer Veröffentlichung oder für den Rest des Unterstützungszeitraums (je nachdem, welcher Zeitraum länger ist) verfügbar gehalten werden müssen.

Zur Meldung von Schwachstellen und Sicherheitsvorfällen

Heftig umstritten war – auch jenseits der Trilog-Verhandlungen – die im Kommissions entwurf enthaltene Pflicht zur Meldung aktiv ausgenutzter Schwachstellen an ENISA. Cybersicherheitsexperten hatten in einem offenen Brief vom 3. Oktober 2023 mit deutlichen Worten kritisiert, dass die von der Kommission vorgesehene Regelung zur Offenlegung von Schwachstellen neue Bedrohungen schaffe, die die Sicherheit digitaler Produkte und der Personen, die sie nutzen, untergraben würden. Zentraler Kritikpunkt war, dass ein zentrales Verzeichnis von ungepatchten Schwachstellen ein erhebliches Missbrauchspotential seitens staatlicher Akteure (für nachrichtendienstliche oder Überwachungs-Zwecke) und privater, krimineller Personen oder Vereinigungen berge.

Mit ihrer Kritik scheinen die Experten nur eingeschränkt durchgedrungen zu sein: Die finale Fassung soll weiterhin eine Meldepflicht von aktiv ausgenutzten Schwachstellen enthalten. Es sollen lediglich die Fristen für derartige Meldungen mit den Fristenregelungen der NIS2-Richtlinie synchronisiert worden sein (d.h. 24 Stunden für die Erstmeldung, 72 Stunden für den ausführlichen Bericht und ein Monat für den Abschlussbericht). Hinsichtlich des Meldeempfängers soll in der vereinbarten Fassung vorgesehen sein, dass die Hersteller die Schwachstellen zunächst an die jeweils zuständige nationale Behörde zu melden hätten und gleichzeitig die Rolle der ENISA gestärkt werden solle.

Musik wird alsbald in den Standardisierungsgremien spielen

Für die Anwendung der neuen Vorgaben soll den erfassten Marktakteuren nunmehr eine dreijährige Übergangsfrist zugebilligt werden. Die Meldepflichten sollen abweichend hiervon jedoch bereits nach 21 Monaten nach Inkrafttreten scharf geschaltet werden.

Es bleibt zu hoffen, dass mit hinreichender Vorlaufzeit vor Scharfschaltung der neuen Anforderungen Leitfäden und vor allem harmonisierte Normen für die erfassten Produktkategorien vorliegen, auf deren Grundlage Hersteller und benannte Dritte mit hinreichender Rechtssicherheit die Einhaltung der neuen Anforderungen bewerten und sicherstellen können. Dies gilt umso mehr, als das lückenlose Vorliegen harmonisierter Normen Voraussetzung für die eigenständige Konformitätsbewertung der in der Kritikalitätsklasse I gelisteten Produkte darstellt.

Angesichts des weiten Anwendungsbereichs des CRA dürfte insofern ein kleiner Standardisierungsmarathon anstehen, innerhalb dessen zumindest in Teilen auf die gegenwärtigen Standardisierungsbemühungen unter der Delegierten Verordnung 2022/30 zur Funkanlagenrichtlinie zurückgegriffen werden kann.