Cyber Resilience Act
Wesentliche Änderung
Legaldefinition Art. 3 Nr. 30 CRA
„eine Änderung des Produkts mit digitalen Elementen nach dessen Inverkehrbringen, die sich auf die Konformität des Produkts mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I auswirkt oder zu einer Änderung des bestimmungsgemäßen Zwecks, für den das Produkt geprüft wurde, führt“
Der Cyber Resilience Act (CRA) prüft Produkte nicht dauerhaft, sondern zu einem Zeitpunkt: beim Inverkehrbringen. Die wesentliche Änderung ist der Mechanismus, der verhindert, dass diese Prüfung durch spätere Eingriffe entwertet wird.
Die Definition nennt zwei Auslöser, und es genügt, wenn einer davon zutrifft: Die Änderung wirkt sich auf die Konformität mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I aus oder sie ändert den bestimmungsgemäßen Zweck, für den das Produkt geprüft wurde.
Der zweite Auslöser wird oft übersehen
Am Code kann alles unverändert bleiben. Wird ein Produkt mit einer anderen Zweckbestimmung vermarktet als der geprüften, ist die Schwelle trotzdem überschritten. Eine Software, die als internes Werkzeug bewertet wurde und anschließend für den Betrieb über das offene Internet angeboten wird, ist dafür das klassische Beispiel.
Wer nur technische Änderungen im Blick hat, übersieht diesen Fall systematisch.
Was als wesentlich gilt und was nicht
Eher nicht wesentlich: Fehlerkorrekturen, Sicherheitsupdates, die eine Schwachstelle schließen, Anpassungen an der Oberfläche ohne Auswirkung auf Schutzmechanismen.
Eher wesentlich: neue Schnittstellen nach außen, Änderungen an Authentifizierung, Verschlüsselung oder Rechteverwaltung, der Wechsel einer sicherheitsrelevanten Kernkomponente, neue Funktionen, die zusätzliche Daten verarbeiten oder neue Verbindungen aufbauen.
Die Einordnung ist eine Bewertung, keine Rechenoperation. Genau deshalb gehört sie dokumentiert: Nachvollziehbar festgehaltene Entscheidungen sind das, was bei einer späteren Prüfung zählt.
Die Folgen
Liegt eine wesentliche Änderung vor, ist die Konformität des geänderten Produkts zu überprüfen. Erwägungsgrund 202 hält als Folge fest, dass das Produkt gegebenenfalls einer neuen Konformitätsbewertung zu unterziehen ist. Führt der Hersteller die Konformitätsbewertung unter Beteiligung eines Dritten durch, ist diesem eine Veränderung mitzuteilen, die zu einer wesentlichen Änderung führen könnte. Die technische Dokumentation wird ohnehin fortgeschrieben: Nach Artikel 31 Absatz 2 wird sie gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend aktualisiert.
Den Unterstützungszeitraum verlängert die wesentliche Änderung nicht. Artikel 13 Absatz 10 weist sogar in die andere Richtung: Hat ein Hersteller nachfolgende wesentlich geänderte Versionen eines Softwareprodukts in den Verkehr gebracht, darf er die Einhaltung der grundlegenden Cybersicherheitsanforderung in Anhang I Teil II Nummer 2 auf die zuletzt in den Verkehr gebrachte Version beschränken, sofern die Nutzer der früheren Versionen kostenlos Zugang zu dieser Version haben und ihnen keine zusätzlichen Kosten für die Anpassung der Hardware- und Softwareumgebung entstehen.
Wer dadurch zum Hersteller wird
Die praktisch folgenreichste Wirkung betrifft andere Wirtschaftsakteure. Nimmt ein Einführer oder Händler eine wesentliche Änderung an einem bereits in den Verkehr gebrachten Produkt vor, gilt er nach Artikel 21 als Hersteller und unterliegt den Pflichten der Artikel 13 und 14. Jede sonstige Person, die ein Produkt wesentlich ändert und auf dem Markt bereitstellt, gilt nach Artikel 22 ebenfalls als Hersteller, trägt diese Pflichten aber nur für den von der Änderung betroffenen Teil des Produkts und für das gesamte Produkt erst dann, wenn sich die Änderung auf dessen Cybersicherheit insgesamt auswirkt.
Tiefgreifende Anpassungen für einzelne Kunden sind damit keine Dienstleistung am Rand. Sie sind potenziell der Eintritt in die Herstellerrolle samt allem, was daran hängt.
Fragen aus der Praxis
-
In aller Regel nicht. Ein Update, das eine Schwachstelle schließt, stellt die Konformität wieder her, statt sie zu berühren. Genau das verlangt der CRA ohnehin. Wesentlich wird es erst, wenn dabei die Sicherheitsarchitektur umgebaut wird oder neue Funktionen mit neuen Angriffsflächen hinzukommen. Die Grenze verläuft nicht am Umfang des Codes, sondern an der Auswirkung auf die geprüften Anforderungen.
-
Zunächst ist die Konformität des Produkts in seiner geänderten Form zu überprüfen: Die betroffenen grundlegenden Anforderungen werden neu bewertet, die technische Dokumentation und die Risikobewertung werden aktualisiert, und die Konformitätsbewertung wird gegebenenfalls im betroffenen Umfang wiederholt. Im Ergebnis steht eine geänderte Version, die für sich konform sein muss.
-
Ja, und zwar deutlich. Wer eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt vornimmt und es bereitstellt, gilt für die Zwecke der Verordnung als Hersteller. Bei Einführern und Händlern greifen dann die Pflichten der Artikel 13 und 14 in vollem Umfang. Bei allen übrigen Personen gelten sie nach Artikel 22 Absatz 2 zunächst nur für den von der Änderung betroffenen Teil des Produkts und für das gesamte Produkt erst dann, wenn sich die Änderung auf dessen Cybersicherheit insgesamt auswirkt. Das trifft in der Praxis Systemintegratoren und Anbieter tiefgreifender Kundenanpassungen.
Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.