Wesentliche Veränderung nach CRA: wann eine neue Version neu bewertet werden muss (Art. 3 Nr. 30)
Nicht jede Produktänderung löst den CRA neu aus - aber eine wesentliche Veränderung schon: dann gilt das Produkt als neu in Verkehr gebracht und braucht eine neue Konformitätsbewertung samt aktualisierter Dokumente. Der Test (Art. 3 Nr. 30) ist ein ODER: beeinträchtigt die Änderung die Konformität (und war nicht in der Risikobewertung vorhergesehen) ODER ändert sie den Verwendungszweck. Dernium CRA stuft jede Version geführt ein und sagt klar, ob eine Neubewertung fällig ist. Dieser Beitrag zeigt die Logik - und wo bewusst die Verantwortung beim Hersteller bleibt.
Problem
Software ändert sich ständig - aber nicht jede Änderung löst die CRA-Pflichten neu aus. Der Cyber Resilience Act knüpft das an einen scharf umrissenen Begriff: die wesentliche Veränderung (Art. 3 Nr. 30). Liegt eine vor, gilt das Produkt als neu in Verkehr gebracht und braucht eine neue Konformitätsbewertung, eine aktualisierte EU-Konformitätserklärung, technische Dokumentation und Risikobewertung. Liegt keine vor, läuft alles weiter wie bisher. Besonders heikel ist das für Bestandsprodukte: Ein vor dem 11. Dezember 2027 in Verkehr gebrachtes Produkt fällt erst dann unter den CRA, wenn es danach wesentlich verändert wird. Die Einstufung jeder Version ist damit der eigentliche Auslöser - und genau hier irren sich viele, weil die Abgrenzung feiner ist, als sie aussieht.
Kurze Antwort
Dernium CRA stuft jede Version geführt ein. Sie beantworten ein paar klare Fragen zur Änderung, und das Werkzeug leitet daraus die Einstufung ab - wesentlich oder nicht - mit Begründung und, falls wesentlich, dem Hinweis auf die fällige Neubewertung. Der Test folgt exakt dem Gesetz: Eine Änderung nach Inverkehrbringen ist wesentlich, wenn sie die Konformität mit den wesentlichen Anforderungen beeinträchtigt (und das nicht schon in der Risikobewertung vorhergesehen war) oder wenn sie den Verwendungszweck ändert. Ein reines Sicherheitsupdate, das nur das Risiko senkt, ist keine wesentliche Veränderung. Dernium entscheidet das nicht für Sie; das Werkzeug strukturiert die Frage und macht die Folge sichtbar.
Tiefgang
Ein ODER, kein UND. Der häufigste Denkfehler: Man hält die wesentliche Veränderung für eine Kombination mehrerer Bedingungen. Tatsächlich ist Art. 3 Nr. 30 ein ODER zweier Prongs - es genügt einer. Erstens: Die Änderung beeinträchtigt die Konformität mit den wesentlichen Anforderungen (Anhang I Teil I). Zweitens: Die Änderung ändert den Verwendungszweck, für den das Produkt bewertet wurde. Trifft einer zu, ist die Änderung wesentlich.
„Nicht vorhergesehen" gehört nur zum Konformitäts-Prong. Erwägungsgrund 38 verfeinert den ersten Prong: Eine konformitätsberührende Änderung ist nur dann wesentlich, wenn sie nicht bereits in der ursprünglichen Risikobewertung vorhergesehen war. Wer eine mögliche Änderung dort vorausgedacht hat, löst über den Konformitäts-Prong allein nichts aus. Wichtig: Dieses „vorhergesehen" qualifiziert ausschließlich den ersten Prong - eine Zweckänderung ist auch dann wesentlich, wenn sie vorhergesehen war.
Das Sicherheitsupdate-Privileg - und seine Grenze. Erwägungsgrund 39 stellt klar: Ein Update, das nur das Cybersicherheitsrisiko senkt und weder den Verwendungszweck noch Funktionen, Art oder Leistung ändert, ist keine wesentliche Veränderung. Umgekehrt gilt: Ändert ein Update die Funktionen, die Art oder die Leistung - etwa durch eine neue Funktion, die die Angriffsfläche erweitert -, ist es wesentlich, und es ist unerheblich, ob es als Sicherheitsupdate verpackt oder mit einem solchen gebündelt wird. Im Werkzeug ist die Ausnahme bewusst eng gefasst: Sie greift nur, wenn kein eigenständiger Auslöser zutrifft. Ein als „Sicherheitsupdate" markierter Patch, der zugleich die Konformität unvorhergesehen berührt, wird nicht fälschlich entlastet, sondern bleibt wesentlich.
Die Folge wird sichtbar gemacht. Ist eine Version wesentlich verändert, zeigt Dernium CRA die Konsequenz direkt an: neue Konformitätsbewertung (Art. 32), aktualisierte EU-Konformitätserklärung, technische Dokumentation und Risikobewertung - soweit von der Änderung betroffen (Erwägungsgrund 41). Im Readiness-Dashboard fließt die Einstufung als eigener Bereich ein, sodass keine unbewertete Version untergeht.
Abgelehnte Alternativen
- Jede neue Version automatisch als wesentlich behandeln. Übererfüllt und erzeugt unnötige Neubewertungen für reine Sicherheitsupdates - genau das, was Erwägungsgrund 39 ausschließt.
- Den Begriff als UND-Verknüpfung modellieren. Wäre rechtlich falsch; ein einzelner Prong genügt.
- Das Sicherheitsupdate-Flag als pauschalen Freibrief. Würde eine unvorhergesehene Konformitätswirkung verdecken; die Ausnahme greift nur, wenn kein eigenständiger Auslöser zutrifft.
Wie Dernium hilft
Sie pflegen Ihre Versionen ohnehin im CRA-Nachweis. Zu jeder Version beantworten Sie die wenigen Fragen, die der Gesetzestext stellt, und sehen sofort die Einstufung samt Begründung und Folge. Eine Erklärschicht benennt die beiden Prongs, die Vorhersehbarkeits-Feinheit und das Sicherheitsupdate-Privileg in klarer Sprache. So wird aus einer schwer greifbaren Rechtsfrage ein nachvollziehbarer, belegbarer Schritt - besonders wertvoll für Bestandsprodukte, bei denen genau diese Einstufung darüber entscheidet, ob der CRA überhaupt greift.
Offene Punkte
- Die Einstufung ist eine geführte Hilfe, keine Rechtsberatung. Die Tatsachen zur Änderung und die abschließende Entscheidung verantworten Sie als Hersteller.
- Ob eine konkrete Änderung die Konformität „beeinträchtigt" oder den Verwendungszweck „ändert", ist eine fachliche Beurteilung; das Werkzeug strukturiert sie, nimmt sie aber nicht ab.
Verifikation
Der Begriff steht in Artikel 3 Nummer 30; die Verfeinerung des Konformitäts-Prongs in Erwägungsgrund 38, das Sicherheitsupdate-Privileg und der Funktions-Eskalator in Erwägungsgrund 39, die Folge (neue Konformitätsbewertung) in Erwägungsgrund 41 und Artikel 32. Bestandsprodukte fallen unter den CRA, sobald sie ab dem 11. Dezember 2027 wesentlich verändert werden.
Mehr aus unserer CRA-Reihe
- Cyber Resilience Act: Überblick für Softwarehersteller
- SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte
- CRA-Meldepflicht: Schwachstellen und Vorfälle an CSIRT und ENISA (ab 2026)
- CRA-Konformitätsnachweise: Anhang V/VII und CE (ab 2027)
- Coordinated Vulnerability Disclosure: Policy, security.txt und CSAF
- DoC- und Tech-Doc-Generator: Anhang V/VII als PDF
- Schwachstellen über den Support-Zeitraum behandeln: SLA-Uhr und Behebungs-Lebenslauf
- Konformitätsbewertung nach CRA: welcher Pfad für welches Produkt (Art. 32)
- CRA Anhang II: Nutzerinformationen und Anleitungen als PDF
- Die CRA-Risikobewertung (Art. 13): welche Anforderungen für Ihr Produkt gelten
- Drittkomponenten nach CRA: Sorgfaltspflicht für Fremd- und Open-Source-Bausteine (Art. 13 Abs. 5)
- CRA-Readiness auf einen Blick: das Dashboard über alle Bausteine
- Die notifizierte Stelle nach CRA: wann eine Dritt-Prüfung nötig ist und was sie braucht (Art. 32)
- Dernium CRA: ein Werkzeug für den gesamten Cyber Resilience Act