CRA Response Center Demo anfragen

Leitfaden Stand Lesezeit 8 Min.

Wesentliche Änderung: Wann ein Update ein neues Produkt ist

Nicht jedes Update ist nur ein Update. Verändert eine neue Version die Sicherheit oder den Zweck eines Produkts, behandelt der Cyber Resilience Act sie wie ein neues Produkt. Diese Seite erklärt die Abgrenzung, die Folgen und wie Sie die Entscheidung je Release prüfen und festhalten.

Eine wesentliche Änderung ist nach Artikel 3 Nummer 30 des Cyber Resilience Act eine Änderung nach dem Inverkehrbringen. Sie liegt vor, wenn die Änderung die Konformität mit den Sicherheitsanforderungen aus Anhang I Teil I berührt oder die Zweckbestimmung des Produkts ändert. Ein Sicherheitsupdate, das ein Risiko senkt, ist keine wesentliche Änderung; ein Funktionsupdate, das Funktionen, Art oder Leistung des Produkts ändert, in der Regel schon (Erwägungsgrund 39). Die Folge: Die geänderte Version gilt als neu in Verkehr gebracht, und die Konformität ist zu überprüfen. Bestandsprodukte, die nach dem 11. Dezember 2027 wesentlich geändert werden, fallen damit unter die Anforderungen (Artikel 69 Absatz 2).

Das Wichtigste

  • Maßgeblich sind zwei Fragen: Berührt die Änderung die Konformität mit Anhang I Teil I, oder ändert sie die Zweckbestimmung (Artikel 3 Nummer 30)?
  • Sicherheitsfixes, die das Risiko senken und den Zweck nicht ändern, sind keine wesentliche Änderung. Neue Funktionen sind es in der Regel, weil sie die Angriffsfläche vergrößern (Erwägungsgrund 39).
  • Folge ist eine neue oder ergänzte Konformitätsbewertung, nur für die betroffenen Aspekte (Erwägungsgrund 41).
  • Wer ein fremdes Produkt wesentlich ändert, wird selbst Hersteller (Artikel 21 und 22).
  • Versionsnummern sind unerheblich. Entscheidend ist, was sich am Produkt ändert, und dass die Entscheidung je Release dokumentiert ist.

Was sagt die Verordnung?

Artikel 3 Nummer 30 definiert die wesentliche Änderung über zwei Merkmale. Das erste ist eine Auswirkung auf die Konformität mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I. Das zweite ist eine Änderung der Zweckbestimmung, für die das Produkt bewertet wurde. Erwägungsgrund 39 übersetzt das für Software. Eine Softwareänderung ist wesentlich, wenn sie die Zweckbestimmung ändert und in der Risikobewertung nicht vorgesehen war, oder wenn sich die Art der Gefahr oder das Risiko erhöht und die Version bereitgestellt wird.

Derselbe Erwägungsgrund zieht die Grenze nach unten. Eine Sicherheitsaktualisierung, die das Risiko senkt und die Zweckbestimmung nicht ändert, ist keine wesentliche Änderung, auch wenn dafür Funktionen oder Leistung angepasst werden. Geringfügige Funktionsupdates wie eine bessere Darstellung, neue Sprachen oder Piktogramme sind es in der Regel ebenfalls nicht. Ein Funktionsupdate, das Funktionen, Art oder Leistung des Produkts ändert, ist dagegen wesentlich, weil neue Funktionen die Angriffsfläche vergrößern; das Beispiel im Erwägungsgrund ist ein neues Eingabeelement, das eine Eingabevalidierung erfordert. Ob das Update getrennt oder zusammen mit einem Sicherheitsupdate kommt, spielt keine Rolle.

Welche Änderungen sind wesentlich, welche nicht?

Die Kommissionsleitlinie vom 27. Juli 2026 enthält Beispiele. Ihr Originaltext konnte für diese Seite nicht geprüft werden; die Beispiele stammen aus übereinstimmenden Sekundärquellen und sind so gekennzeichnet. Die Leitlinie ist rechtlich unverbindlich.

ÄnderungWesentlich?Grund und Quelle
Sicherheitsfix, der eine Lücke schließt, ohne den Zweck zu ändernNeinRisiko sinkt, Zweck bleibt (Erwägungsgrund 39)
Neue Sprachen, Piktogramme, bessere DarstellungIn der Regel neinGeringfügiges Funktionsupdate (Erwägungsgrund 39)
Freischalten einer Funktion, die bereits bewertet und im Design vorgesehen warNeinRisikobewertung hat sie erfasst (Leitlinie, Sekundärquelle)
Austausch eines Bauteils gegen ein identisches ErsatzteilNeinErsatzteile sind nach Artikel 2 Absatz 6 ausgenommen (Leitlinie, Sekundärquelle)
Neues Eingabeelement, das Eingabevalidierung brauchtJaNeue Angriffsfläche (Erwägungsgrund 39)
Nachrüsten einer FernkonnektivitätJaNeuer Kommunikationskanal (Leitlinie, Sekundärquelle)
Persistenter Login mit lokal gespeicherten ZugangstokenJaNeues Risiko (Leitlinie, Sekundärquelle)
Anzeige von Betriebsdaten wird per Update zur MaschinensteuerungJaZweckänderung (Leitlinie, Sekundärquelle)
Lokale Verschlüsselung wird durch einen Fern-Dienst des Herstellers ersetztJaNeue externe Abhängigkeit (Leitlinie, Sekundärquelle)
Komfortfunktion wie ein Diagnose-ExportPrüfenKann wesentlich sein, wenn neue Schnittstellen entstehen (Leitlinie, Sekundärquelle)

Die Leitlinie fasst laut Sekundärquellen drei Prüffragen zusammen: Führt das Update neue Bedrohungsvektoren ein? Ermöglicht es neue Angriffsszenarien? Ändert es Wahrscheinlichkeit oder Auswirkung bekannter Szenarien? Ein Ja spricht für eine wesentliche Änderung.

Was folgt aus einer wesentlichen Änderung?

  • Konformität neu prüfen. Erwägungsgrund 41 verlangt, die Konformität zu überprüfen und gegebenenfalls eine neue Konformitätsbewertung durchzuführen. Laut Leitlinie (Sekundärquelle) nur für die betroffenen Aspekte; Tests und Dokumente für unberührte Teile müssen nicht wiederholt werden. War eine notifizierte Stelle beteiligt, ist sie zu informieren (Anhang VIII Teil II Nummer 7, Ergänzung der Baumusterbescheinigung).
  • Neues Inverkehrbringen. Die geänderte Version gilt als neu in Verkehr gebracht (Leitlinie, Sekundärquelle). Das löst die Pflichten aus Artikel 13 für diese Version aus: technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung.
  • Bestandsprodukte werden erfasst. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Anforderungen nur, wenn sie nach diesem Datum wesentlich geändert werden (Artikel 69 Absatz 2). Eine neue Funktion für eine Maschine aus 2020 holt diese Maschine also in den CRA. Laut Leitlinie (Sekundärquelle) gilt das für den geänderten Teil oder, wenn die Cybersicherheit insgesamt berührt ist, für das ganze Produkt. Die Meldepflicht nach Artikel 14 gilt unabhängig davon für alle Produkte (Artikel 69 Absatz 3).
  • Eigener Unterstützungszeitraum. Jede wesentlich geänderte Version hat laut Leitlinie (Sekundärquelle) einen eigenen Unterstützungszeitraum, der neu zu bewerten ist. Ein automatischer Neustart oder eine Verlängerung folgt daraus nicht; nur wenn sich die erwartete Nutzungsdauer ändert, ändert sich der Zeitraum. Artikel 13 Absatz 10 erlaubt, die Schwachstellenbehebung auf die neueste wesentlich geänderte Version zu beschränken, wenn der Wechsel kostenlos ist. Details unter Unterstützungszeitraum.

Wer ändert, wird Hersteller: Artikel 21 und 22

Die wesentliche Änderung ist nicht nur ein Thema für den ursprünglichen Hersteller. Nach Artikel 21 gilt ein Importeur oder Händler als Hersteller, wenn er ein bereits in Verkehr gebrachtes Produkt wesentlich ändert. Artikel 22 Absatz 1 dehnt das auf jede andere Person aus, die ein Produkt wesentlich ändert und bereitstellt. Nach Absatz 2 treffen sie dann die Pflichten aus Artikel 13 und 14 für den betroffenen Teil oder, wenn die Cybersicherheit des Produkts insgesamt berührt ist, für das gesamte Produkt.

Das wirkt in beide Richtungen. Wer eine zugekaufte Steuerung mit eigener Software erweitert und weiterverkauft, ist für diesen Teil Hersteller. Baut ein Integrator oder Kunde das Produkt tiefgreifend um und stellt es anderen bereit, liegt die Verantwortung für die Änderung dort. Mehr dazu unter Importeure, Händler und Bevollmächtigte.

Wie prüfe ich das je Release?

Die Entscheidung gehört in den Freigabeprozess, nicht in die Rückschau. Fünf Schritte, die sich je Version wiederholen:

  1. Änderungen auflistenWas ist neu, geändert oder entfernt: Funktionen, Schnittstellen, Kommunikationskanäle, Abhängigkeiten, Ausführungsumgebungen. Die SBOM-Differenz zur Vorversion gehört dazu.
  2. Gegen die Zweckbestimmung haltenKann das Produkt nach dem Update etwas, wofür es nicht bewertet wurde? Anzeige wird Steuerung, lokal wird vernetzt, manuell wird automatisch.
  3. Die drei Prüffragen stellenNeue Bedrohungsvektoren, neue Angriffsszenarien, veränderte Wahrscheinlichkeit oder Auswirkung bekannter Szenarien. Die Risikobewertung nach Artikel 13 Absatz 3 wird dabei aktualisiert.
  4. Entscheiden und begründenWesentlich oder nicht, mit Begründung je Änderung. Bei "wesentlich": betroffene Aspekte benennen, Konformitätsbewertung für diese Aspekte planen, notifizierte Stelle informieren, Unterstützungszeitraum der neuen Version festlegen.
  5. FesthaltenEntscheidung, Begründung, Datum und verantwortliche Person in die technische Dokumentation. Die Marktüberwachungsbehörde kann sie auf begründetes Verlangen einsehen (Artikel 13 Absatz 22).

Der letzte Schritt fehlt am häufigsten. Wer je Release ein kurzes Protokoll mit Entscheidung und Begründung führt, kann später zeigen, dass er die Frage gestellt hat, auch wenn die Behörde die Antwort anders sieht. Dasselbe Protokoll hilft, wenn nach einem Update eine Schwachstelle gemeldet wird: Es zeigt, welche Version was kann und seit wann. CRA Response Center führt im Ernstfall das Nachweisprotokoll ab Eingang der Meldung; die Release-Entscheidung davor bleibt beim Hersteller.

Typische Fehler

  • Feature-Releases als "Minor" deklarieren. Versionsnummern sind unerheblich. Entscheidend ist, was sich am Produkt ändert.
  • Sicherheitsfix und neue Funktion im selben Paket. Das Sicherheitsupdate ist nicht wesentlich, die neue Funktion vielleicht schon; die gemeinsame Auslieferung ändert daran nichts.
  • Bestandsprodukte für sicher halten. Die nächste neue Funktion nach dem 11. Dezember 2027 holt das Altprodukt in den CRA.
  • Die Entscheidung nicht festhalten. Eine unbegründete "nicht wesentlich"-Einstufung ist gegenüber der Marktüberwachung kaum zu verteidigen.

Was bleibt offen?

Die Grenze zwischen Zweckänderung und neuer Funktion innerhalb des bisherigen Zwecks bleibt Einzelfallsache; harmonisierte Normen könnten sie konkretisieren, liegen aber am 7. Oktober 2026 nicht im Amtsblatt vor. Die Leitlinie ist unverbindlich und hier nur über Sekundärquellen belegt.

Häufige Fragen

Ist ein Sicherheitspatch eine wesentliche Änderung?

Nein, wenn er das Risiko senkt und die Zweckbestimmung nicht ändert (Erwägungsgrund 39). Das gilt auch, wenn dafür Funktionen oder Leistung angepasst werden.

Ist jede neue Funktion eine wesentliche Änderung?

In der Regel ja, wenn sie Funktionen, Art oder Leistung des Produkts ändert oder neue Schnittstellen schafft (Erwägungsgrund 39). Geringfügige Änderungen wie neue Sprachen oder Piktogramme sind ausgenommen.

Muss ich bei einer wesentlichen Änderung alles neu testen?

Nein. Laut Leitlinie (Sekundärquelle) nur die betroffenen Aspekte; Tests und Dokumente für unberührte Teile werden nicht wiederholt. Artikel 22 Absatz 2 regelt das für Dritte ausdrücklich.

Startet der Unterstützungszeitraum neu?

Die neue Version hat einen eigenen Zeitraum, der neu zu bewerten ist. Ein automatischer Neustart oder eine Verlängerung folgt daraus laut Leitlinie (Sekundärquelle) nicht.

Was ist mit Produkten, die vor Dezember 2027 verkauft wurden?

Sie unterliegen den Anforderungen nur, wenn sie nach dem 11. Dezember 2027 wesentlich geändert werden (Artikel 69 Absatz 2). Die Meldepflicht nach Artikel 14 gilt für sie trotzdem (Artikel 69 Absatz 3).

Mein Kunde baut mein Produkt um. Bin ich dafür verantwortlich?

Wer ein Produkt wesentlich ändert und bereitstellt, gilt nach Artikel 22 für den geänderten Teil als Hersteller. Die Verantwortung für die Änderung liegt dann dort, nicht beim ursprünglichen Hersteller.

Weiterlesen

Quellen

Die Meldepflicht läuft. Wer nimmt bei Ihnen nachts ab?

CRA Response Center nimmt Schwachstellen-Meldungen an, prüft sie, weckt Ihre Rufkette und führt die Fristen-Uhren. Ab 190 Euro im Monat, Einrichtung zum Festpreis.

Demo anfragen