Wesentliche Änderung nach CRA: Wann Updates eine neue Herstellerpflicht auslösen

Eine wesentliche Änderung liegt nach dem Cyber Resilience Act vor, wenn ein bereits in Verkehr gebrachtes Produkt mit digitalen Elementen so verändert wird, dass die Änderung seine Konformität mit den grundlegenden Cybersicherheitsanforderungen beeinflusst oder die ursprünglich bewertete Zweckbestimmung geändert wird. Nicht jedes Update ist wesentlich. Reine Sicherheitsupdates, die nur Risiken senken und die Zweckbestimmung nicht verändern, gelten typischerweise nicht als wesentliche Änderung.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Grundlagen & Anwendungsbereich. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was bedeutet „wesentliche Änderung“ im CRA?

Der CRA definiert eine wesentliche Änderung als Veränderung eines Produkts nach dem Inverkehrbringen, die die Einhaltung der grundlegenden Cybersicherheitsanforderungen aus Anhang I Teil I beeinflusst oder die Zweckbestimmung verändert, für die das Produkt ursprünglich bewertet wurde.

Damit geht es nicht primär darum, wie viele Zeilen Code geändert wurden. Eine kleine Codeänderung kann sicherheitsrelevant sein, während ein großes visuelles Redesign die Cybersicherheitsbewertung kaum berührt. Maßgeblich sind Funktion, Zweck, Risiko und Konformität.

Warum ist die Einstufung so wichtig?

Weil eine wesentliche Änderung neue Herstellerpflichten auslösen kann. Importeur oder Händler werden nach Artikel 21 wie Hersteller behandelt, wenn sie ein Produkt unter eigener Marke in Verkehr bringen oder eine wesentliche Änderung vornehmen. Auch andere natürliche oder juristische Personen können nach Artikel 22 Herstellerpflichten übernehmen, wenn sie ein Produkt wesentlich verändern und anschließend auf dem Markt bereitstellen.

Die Folge ist erheblich: Aus einer scheinbaren Anpassung kann eine Pflicht zu Risikobewertung, sicherer Entwicklung, Schwachstellenmanagement, technischer Dokumentation und Konformitätsbewertung entstehen.

Welche zwei Hauptfragen entscheiden über eine wesentliche Änderung?

In der Praxis sollte jede Änderung mindestens anhand zweier Hauptfragen geprüft werden: Ändert sich die Zweckbestimmung? Und kann die Änderung die CRA-Konformität beziehungsweise das Cybersicherheitsrisiko beeinflussen?

Ist ein Sicherheitsupdate eine wesentliche Änderung?

In der Regel nein, wenn das Sicherheitsupdate ausschließlich darauf abzielt, das Cybersicherheitsrisiko zu reduzieren und die Zweckbestimmung nicht verändert. Der CRA nennt diesen Fall ausdrücklich.

Das gilt auch dann, wenn für den Patch Funktionen oder Leistung geringfügig verändert werden, sofern dies allein der Risikoreduzierung dient. Ein Patch gegen eine bekannte Schwachstelle soll nicht automatisch eine neue vollständige Konformitätsbewertung auslösen.

Kann ein Security-Update trotzdem wesentlich werden?

Ja, wenn das Update weit über die reine Risikoreduzierung hinausgeht. Wird zusammen mit dem Patch eine neue Netzwerkfunktion aktiviert, eine zusätzliche Cloud-Schnittstelle eingeführt oder das Produkt für einen neuen Einsatzzweck geöffnet, muss die Änderung nach den allgemeinen Kriterien bewertet werden.

Ob Sicherheits- und Feature-Änderung in einem gemeinsamen Paket ausgeliefert werden, ist nicht entscheidend. Maßgeblich bleibt die Wirkung der Änderung.

Ist ein Feature-Update automatisch wesentlich?

Nein. Kleine Funktionsänderungen können nicht wesentlich sein. Die Erwägungsgründe nennen beispielsweise visuelle Verbesserungen sowie neue Piktogramme oder zusätzliche Sprachen als Änderungen, die im Allgemeinen nicht als wesentlich gelten sollten.

Anders sieht es aus, wenn eine neue Funktion Zweck, Typ oder Leistung des Produkts verändert und dadurch neue Risiken entstehen. Ein zusätzliches Eingabeelement, eine neue Schnittstelle oder eine neue Fernsteuerungsfunktion kann die Angriffsfläche erweitern und eine Neubewertung erforderlich machen.

Wie wirkt sich eine neue API auf die CRA-Bewertung aus?

Eine neue API ist ein typischer Kandidat für eine erneute Risikoprüfung. Sie kann neue Authentifizierungsanforderungen, Datenflüsse, Eingabevalidierung, Berechtigungen und Missbrauchsszenarien erzeugen.

Das bedeutet nicht automatisch, dass jede API eine wesentliche Änderung ist. Entscheidend ist, ob die ursprüngliche CRA-Risikobewertung diese Funktion und die damit verbundenen Risiken bereits abgedeckt hat. War die Erweiterung vorgesehen und bewertet, kann die Einordnung anders ausfallen als bei einer völlig neuen Produktfunktion.

Was bedeutet „nicht vom Hersteller vorhergesehen“?

Die ursprüngliche Risikobewertung spielt eine wichtige Rolle. Der CRA betrachtet Änderungen besonders kritisch, wenn sie bei der initialen Bewertung nicht vorgesehen waren und neue Risiken oder eine andere Zweckbestimmung entstehen.

Hersteller profitieren deshalb von einer präzisen, aber nicht künstlich engen Produktbeschreibung. Eine Risikobewertung sollte geplante Betriebsvarianten und vorhersehbare Erweiterungen realistisch erfassen. Sie darf aber nicht so allgemein formuliert werden, dass praktisch jede spätere Funktion als angeblich schon berücksichtigt gilt.

Ist eine Reparatur oder Wartung eine wesentliche Änderung?

Nicht zwingend. Reparatur, Wartung oder Aufarbeitung führen nicht automatisch zu einer wesentlichen Änderung, wenn Zweckbestimmung und Funktionalität unverändert bleiben und das Risikoniveau nicht beeinflusst wird.

Ein Austausch eines defekten Bauteils gegen ein gleichwertiges Bauteil kann daher anders zu bewerten sein als der Einbau eines neuen Funkmoduls mit zusätzlicher Fernzugriffsfunktion. Der Begriff „Reparatur“ schützt nicht vor der Bewertung der tatsächlichen technischen Änderung.

Was gilt bei Hardware-Upgrades?

Hardware-Upgrades können wesentlich sein, wenn sie Design, Funktion, Schnittstellen oder Sicherheitsrisiko verändern. Ein leistungsfähigerer Prozessor allein ist nicht zwingend relevant. Ein neues Secure Element, eine zusätzliche Netzwerkschnittstelle oder ein Funkmodul kann dagegen Sicherheitsarchitektur und Risikobewertung berühren.

Bei Hardware sollte deshalb geprüft werden, ob die Änderung neue Kommunikationswege, Speicherbereiche, Berechtigungen oder Abhängigkeiten erzeugt. Auch Firmware-Anpassungen gehören in die Bewertung.

Was gilt bei Software-Versionen?

Softwareentwicklung ist iterativ. Nicht jede neue Version ist ein neues CRA-Produkt. Hersteller sollten jedoch für jedes Release dokumentieren, ob die Änderungen innerhalb der bestehenden Risikobewertung liegen oder eine wesentliche Änderung darstellen.

Ein sinnvoller Release-Prozess enthält deshalb einen festen CRA-Change-Check. Er kann mit wenigen Fragen beginnen: neue Zweckbestimmung, neue Schnittstelle, neue Datenkategorie, neue Berechtigungen, neue sicherheitskritische Komponente, erhöhtes Risiko oder geänderter Konformitätspfad?

Wann muss eine neue Konformitätsbewertung durchgeführt werden?

Wenn eine wesentliche Änderung die CRA-Konformität beeinflussen kann oder die Zweckbestimmung geändert wird, muss die Konformität erneut verifiziert werden. Je nach Produkt und Änderung kann eine neue Konformitätsbewertung erforderlich sein.

War ursprünglich eine benannte Stelle beteiligt, sollte eine Änderung, die zu einer wesentlichen Änderung führen könnte, dieser Stelle mitgeteilt werden. Der bestehende Konformitätspfad ist unter CRA-Konformitätsbewertung und CE-Kennzeichnung beschrieben.

Muss die gesamte technische Dokumentation neu erstellt werden?

Nicht zwingend von null. Sie muss aber so aktualisiert werden, dass der geänderte Produktstand und seine Risiken nachvollziehbar dokumentiert sind. Welche Teile betroffen sind, hängt vom Umfang der Änderung ab.

Bei einer neuen Cloud-Schnittstelle können beispielsweise Architektur, Datenflüsse, Bedrohungsmodell, Tests, Risikobewertung und Nutzerinformationen aktualisiert werden müssen. Bei einer kleinen UI-Anpassung kann ein dokumentierter Change-Check ausreichen.

Wie wirkt sich eine wesentliche Änderung auf SBOM und Komponentenmanagement aus?

Ändern sich Softwarekomponenten, muss auch die SBOM zum neuen Release passen. Besonders relevant ist das, wenn neue Bibliotheken oder Dienste eingebunden werden, die eigene Schwachstellen oder Abhängigkeiten mitbringen.

Die SBOM beantwortet dabei nur, was im Produkt enthalten ist. Ob die Änderung wesentlich ist, entscheidet sich zusätzlich an Zweck, Risiko und Konformität.

Wer trägt die Verantwortung, wenn ein Händler ein Produkt verändert?

Ein Händler oder Importeur kann nach Artikel 21 zum Hersteller werden, wenn er eine wesentliche Änderung durchführt und das Produkt anschließend auf dem Markt bereitstellt. Dann gelten die Herstellerpflichten nach Artikeln 13 und 14.

Das ist für Integratoren und Reseller wichtig. Wer Standardhardware mit eigener Firmware versieht, sicherheitsrelevante Funktionen freischaltet oder das Produkt für einen neuen Zweck konfiguriert, sollte seine Rolle nicht pauschal als Händler behandeln.

Was gilt für Systemintegratoren und andere Dritte?

Auch eine andere natürliche oder juristische Person kann nach Artikel 22 Herstellerpflichten übernehmen, wenn sie eine wesentliche Änderung durchführt und das Produkt anschließend auf dem Markt bereitstellt.

Die Verantwortung kann sich auf den geänderten Teil beschränken, wenn nur dieser betroffen ist. Wirkt sich die Änderung auf die Cybersicherheit des gesamten Produkts aus, können die Pflichten das Gesamtprodukt erfassen. Diese Abgrenzung sollte dokumentiert werden.

Wie dokumentiert man die Entscheidung „nicht wesentlich“?

Auch eine Entscheidung gegen eine wesentliche Änderung sollte nachvollziehbar sein. Ein kurzer Change-Assessment-Datensatz reicht häufig, wenn er die entscheidenden Punkte enthält.

1. Produkt und Version benennen.
2. Änderung technisch beschreiben.
3. Betroffene Funktionen und Schnittstellen nennen.
4. Auswirkung auf Zweckbestimmung prüfen.
5. Auswirkung auf Cybersicherheitsrisiko bewerten.
6. Betroffene Anforderungen und Nachweise identifizieren.
7. Entscheidung mit Begründung dokumentieren.
8. Freigabe durch zuständige Rolle festhalten.

Bei vielen Releases kann dieser Check direkt in das Change- oder Release-System eingebaut werden.

Welche typischen Fehler gibt es bei der Bewertung?

Nur auf die Größe des Updates schauen

Viele geänderte Dateien bedeuten nicht automatisch hohe CRA-Relevanz. Umgekehrt kann eine kleine neue Schnittstelle sehr relevant sein.

Security-Patch pauschal freistellen

Ein echter Patch zur Risikoreduzierung ist typischerweise nicht wesentlich. Wird aber gleichzeitig eine neue Funktion eingebaut, muss diese separat bewertet werden.

Zweckbestimmung nicht aktualisieren

Wenn Marketing und Vertrieb das Produkt plötzlich für neue Einsatzbereiche bewerben, kann sich die regulatorische Bewertung ändern, auch wenn der Code weitgehend gleich bleibt.

Konformitätsstelle zu spät einbinden

Bei Produkten mit Drittbewertung kann eine späte Meldung zu Verzögerungen führen.

Wie sollte ein CRA-Change-Management aussehen?

Der effizienteste Weg ist ein fester Prüfschritt im bestehenden Entwicklungsprozess. Product Owner oder Change-Verantwortliche markieren Änderungen mit potenzieller CRA-Relevanz, Security bewertet die Risikowirkung und Compliance entscheidet über notwendige Dokumentations- oder Konformitätsschritte.

So entsteht kein separates Bürokratiesystem. Die Entscheidung wird dort getroffen, wo Änderung, Release und technische Informationen ohnehin zusammenlaufen.

Wie bewertet man mehrere kleine Änderungen über viele Releases?

Ein häufiger Praxisfall ist nicht das eine große Update, sondern eine Folge kleiner Änderungen. Jede einzelne Erweiterung kann für sich harmlos wirken, während sich über mehrere Releases Zweck, Angriffsfläche oder Sicherheitsarchitektur deutlich verschieben. Hersteller sollten deshalb nicht nur den letzten Commit bewerten, sondern regelmäßig prüfen, ob die Summe der Änderungen noch von der ursprünglichen Risikobewertung und Konformitätsentscheidung gedeckt ist.

Ein sinnvoller Ansatz ist ein kumulativer Review an festen Produktmeilensteinen, beispielsweise bei Major Releases oder jährlich für kontinuierlich ausgelieferte Software. Dabei werden neue Schnittstellen, Berechtigungen, Datenarten, Abhängigkeiten und Einsatzszenarien seit der letzten grundlegenden Bewertung zusammengeführt.

So verhindert man den sogenannten Salami-Effekt: Zehn Änderungen werden einzeln als „nicht wesentlich“ eingestuft, obwohl der heutige Produktstand funktional kaum noch dem ursprünglich bewerteten Produkt entspricht.

Wo steht die Definition der wesentlichen Änderung?

Die Definition und die Folgen ergeben sich aus Artikel 3 Nummer 30 sowie den Artikeln 21 und 22 der Verordnung (EU) 2024/2847 bei EUR-Lex. Die Erwägungsgründe 39 bis 42 enthalten zusätzliche Beispiele zur Abgrenzung von Sicherheitsupdates, Feature-Updates, Reparaturen und Upgrades.