Die wesentliche Änderung: Wann ein Software-Update Ihr CRA-Produkt neu auf den Prüfstand stellt

Von Redaktion codAIx | 22. Mai 2026

Im Winter 2025 — es war draussen schon dunkel — arbeiteten wir vier angestrengt im Büro. Es war mucksmäuschenstill, da hallte es plötzlich durch den Raum: "Muss ich im Rolling release dann jetzt jeden Tag mehrfach eine Konformitätsbewertung machen oder wie?". Oha, dachten wir. Unsere damaligen Erkenntnisse - mit aktuellen Informationen aus der EU Guidance und dem Wiebe CRA- Kommentar angereichert - wollen wir im heutigen Artikel teilen. Zu Beginn vorab: Mit der einmaligen CRA-Konformitätsbewertung ist es nicht getan. Software lebt von Updates — und jedes Update kann ein Produkt erneut konformitätspflichtig machen, sobald es eine „wesentliche Änderung" im Sinne von Art. 3 Nr. 30 CRA ist. Dann gilt das geänderte Produkt rechtlich als neu in Verkehr gebracht. Wer in einer CI/CD-Pipeline mehrmals täglich ausliefert, hat dabei eine berechtigte Sorge: Erzeugt nicht jedes Release eine neue Bewertungspflicht? Die beruhigende Antwort lautet Nein — der CRA misst nicht die Frequenz, sondern die Qualität der Änderung. Dieser Beitrag zerlegt den Begriff anhand der Verordnung und der EU-Kommissions-Guidance und zeigt, was für Rolling Release und für Bestandsprodukte gilt.

Vorfrage: Greift der CRA bei reinem SaaS überhaupt?

Bevor man die Update-Logik anwendet, lohnt der Blick auf die Vorfrage: Liefert man überhaupt ein „Produkt mit digitalen Elementen" aus? Reine SaaS-Dienste fallen grundsätzlich nicht unter den CRA, sondern gegebenenfalls in das NIS-2-Regime. Der CRA erfasst Cloud nur als „Datenfernverarbeitung", also Verarbeitung, „für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird und ohne die das Produkt mit digitalen Elementen eine seiner Funktionen nicht erfüllen könnte" (Art. 3 Nr. 2 CRA)[1]. Erwägungsgrund 12 grenzt SaaS, PaaS und IaaS ausdrücklich der NIS-2-Richtlinie zu[1].

Für eine reine Web-SaaS ohne lokal installierte oder selbsthostbare Komponente stellt sich die CRA-Frage nach Versionen und wesentlicher Änderung also gar nicht erst. Sobald aber eine Desktop- oder Mobile-App, ein selbsthostbares Image, eine Firmware oder eine produktgebundene Datenfernverarbeitungslösung ausgeliefert wird, greift der CRA — und dann gilt die Update-Logik dieses Beitrags. Die schwierigen Mischformen behandelt der Beitrag zur CRA-Grauzone.

Warum der CRA mit jedem Update neu mitdenkt

Wer die Konformitätsbewertung einmal durchlaufen, die EU-Konformitätserklärung ausgestellt und die CE-Kennzeichnung angebracht hat, könnte meinen, die CRA-Pflichten seien damit abgehakt. Für Software stimmt das nicht. Softwareentwicklung ist ihrem Wesen nach iterativ: Produkte werden nach dem Inverkehrbringen fortlaufend weiterentwickelt, gepatcht und um Funktionen ergänzt.

Der CRA trägt dem mit einem Scharnierbegriff Rechnung: der wesentlichen Änderung (englisch: substantial modification). Überschreitet eine Änderung diese Schwelle, gilt das geänderte Produkt rechtlich als neu in Verkehr gebracht — mit der Folge, dass die Konformität überprüft und das Produkt gegebenenfalls einer neuen Konformitätsbewertung unterzogen werden muss. Bleibt die Änderung dagegen unwesentlich, läuft die ursprüngliche Konformität weiter. Für Softwarehersteller wird „wesentlich oder nicht?" damit zu einer Routineprüfung, die im Idealfall vor jedem Release steht.

Die Legaldefinition: Art. 3 Nr. 30 CRA

Der Ausgangspunkt ist die Legaldefinition. Art. 3 Nr. 30 CRA bestimmt die wesentliche Änderung als

„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ässen Zwecks, für den das Produkt geprüft wurde, führt"[1].

Daraus ergibt sich ein Zwei-Punkte-Test. Eine Änderung ist wesentlich, wenn sie mindestens eine der beiden Bedingungen erfüllt: Sie wirkt sich auf die Konformität mit den grundlegenden Cybersicherheitsanforderungen aus Anhang I Teil I aus; oder sie ändert den bestimmungsgemässen Zweck, für den das Produkt ursprünglich geprüft wurde.

Zwei Dinge sind dabei zentral. Erstens: Es genügt eine der beiden Bedingungen — die Schwelle ist alternativ, nicht kumulativ. Zweitens, und praktisch noch wichtiger: Der Massstab ist immer die ursprüngliche Risikobewertung. Erwägungsgrund 39 CRA stellt klar, dass eine Änderung dann wesentlich ist, wenn sie das Cybersicherheitsrisiko verändert und dieses veränderte oder zusätzliche Risiko vom Hersteller in seiner ursprünglichen Risikobewertung nicht berücksichtigt wurde[1]. Wie zentral der Begriff ist, zeigt sich daran, dass der CRA in Art. 26 Abs. 2 lit. d die EU-Kommission ausdrücklich anhält, in ihren Leitlinien auf den „Begriff der wesentlichen Änderung" einzugehen — genau diese Aufgabe erfüllt das einschlägige Kapitel der Draft Communication der Kommission[2].

Vier Konstellationen, in denen die Einstufung zählt

Bevor wir in die Update-Praxis gehen, lohnt der Blick darauf, wozu die Einordnung gebraucht wird — vier Konstellationen:

• Einführer und Händler (Art. 21 CRA): Wer als Einführer oder Händler eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt vornimmt, gilt für die Zwecke des CRA als dessen Hersteller — mit allen Pflichten aus Art. 13 und 14 CRA[1].
• Sonstige Personen (Art. 22 CRA): Auch jede andere natürliche oder juristische Person, die eine wesentliche Änderung vornimmt und das Produkt bereitstellt, gilt als Hersteller. Sie trifft die Pflichten für den geänderten Teil — oder, wenn sich die Änderung auf die Cybersicherheit des Gesamtprodukts auswirkt, für das ganze Produkt (Art. 22 Abs. 2 CRA)[1].
• Altprodukte (Art. 69 Abs. 2 CRA): Wer ein vor dem 11. Dezember 2027 in Verkehr gebrachtes Produkt nach diesem Datum wesentlich ändert, gilt ebenfalls als Hersteller (dazu unten ausführlich)[1].
• Iterative Weiterentwicklung durch den Originalhersteller: Für Produkte, die nach dem 11. Dezember 2027 in Verkehr gebracht werden, entscheidet die Einstufung darüber, ob spätere Änderungen eine neue Konformitätsbewertung auslösen.

Für reine Softwarehersteller, die ihr eigenes Produkt fortlaufend weiterentwickeln, ist vor allem die vierte Konstellation der Alltag. Die ersten drei betreffen den Rollenwechsel: Wer ein fremdes Produkt wesentlich verändert, wird selbst zum Hersteller und übernimmt dessen Haftung.

Rolling Release: Das Missverständnis „jedes Release = neues Produkt"

In agilen Teams ist der Reflex verständlich: "Wenn jedes Inverkehrbringen Pflichten auslöst und wir zwanzigmal pro Woche deployen, ersticken wir in Konformitätsbewertungen." Dieser Reflex beruht auf einem Denkfehler. Der CRA misst nicht die Frequenz und nicht die Code-Menge, sondern die Qualität der Änderung gegenüber der ursprünglichen Risikobewertung.

Daraus folgt eine praktische Gestaltungsregel, die der CRA sogar normativ vorgibt: Anhang I Teil II Nr. 2 verlangt, dass „soweit technisch machbar … neue Sicherheitsaktualisierungen getrennt von den Funktionsaktualisierungen bereitgestellt werden"[1]. Wer seine Pipeline so aufbaut, dass Security-Patches eine eigene Release-Spur bekommen, erfüllt damit nicht nur eine gesetzliche Anforderung — er stellt zugleich sicher, dass diese Releases in aller Regel nicht als wesentliche Änderung eingestuft werden. Hinzu kommt eine Erleichterung beim Versionsmanagement: Erwägungsgrund 40 erkennt den „der Softwareentwicklung innewohnenden Wiederholungscharakter" an, und Art. 13 Abs. 10 CRA erlaubt Herstellern, Sicherheitsaktualisierungen während des Unterstützungszeitraums auf die zuletzt in den Verkehr gebrachte Version zu beziehen[1]. Rolling Release und CRA stehen also nicht im Widerspruch — die Verordnung ist auf iterative Entwicklung eingestellt.

Ein echter Graubereich bleibt allerdings: Bei reinem Continuous Deployment ohne diskrete Versionsstände ist die Zuordnung „welcher Auslieferungszeitpunkt ist das massgebliche Inverkehrbringen, an das eine Konformitätserklärung anknüpft?" noch nicht trennscharf geklärt. Hier empfiehlt sich eine vorausschauend formulierte Risikobewertung (siehe unten), die geplante Entwicklungslinien bereits abdeckt.

Funktionsupdates: drei Fallgruppen

Bei Updates, die neue Funktionen bringen, lassen sich aus der EU-Guidance drei Fallgruppen ableiten[2].

Erstens — neue Funktion ändert die Zweckbestimmung: wesentlich. Führt ein Update Funktionen ein, die den bestimmungsgemässen Zweck verschieben, hat der Hersteller diese Änderung in der Regel nicht in seiner ursprünglichen Risikobewertung berücksichtigt — die Änderung ist wesentlich. Beispiel der Kommission: Ein Dashboard, das ursprünglich nur Maschinendaten anzeigt, erhält per Update die Fähigkeit, Maschinen tatsächlich zu steuern. Aus einem Situationsbewusstseins-Werkzeug wird ein Produkt zur operativen Steuerung — eine wesentliche Änderung.

Zweitens — vorab bewertete Funktion wird nachgereicht: unwesentlich. Hat der Hersteller die spätere Einführung einer Funktion bereits in der ursprünglichen Risikobewertung vorgesehen, die Risiken beschrieben und Massnahmen umgesetzt, ist die spätere Aktivierung keine wesentliche Änderung. Beispiel: Eine Messaging-Anwendung startet mit Eins-zu-eins-Nachrichten; die ursprüngliche Risikobewertung deckt die spätere Gruppenchat-Funktion samt Administrationswerkzeugen bereits ab. Wird sie ausgerollt, bewegt sie sich im Rahmen des Bewerteten.

Drittens — auch kleine Funktionen können wesentlich sein. Der Umfang einer Änderung ist nicht entscheidend; entscheidend ist ihre Wirkung auf das Risikoprofil. Beispiel: Ein Update ergänzt eine „Angemeldet bleiben"-Funktion, die Authentifizierungs-Tokens lokal speichert. Funktional eine Kleinigkeit — aber sie eröffnet neue Risiken (Token-Diebstahl, Session-Hijacking), die in der ursprünglichen Risikobewertung nicht enthalten waren: wesentliche Änderung. Die Lehre: Eine wesentliche Änderung bemisst sich nicht nach Programmieraufwand, sondern nach Sicherheitswirkung.

Sicherheitsupdates: im Grundsatz unwesentlich — mit Ausnahmen

Für Sicherheitsupdates gilt eine Grundregel und eine Gegenausnahme.

Grundregel: Sicherheitsupdates sind in aller Regel keine wesentliche Änderung (Erwägungsgrund 39 CRA)[1]. Ihr Zweck ist es gerade, das Cybersicherheitsrisiko zu senken. Ein Update, das den bestimmungsgemässen Zweck nicht verändert und keine neuen Risiken einführt, bleibt unwesentlich — auch dann, wenn dabei einzelne Funktionen eingeschränkt werden, um eine Schwachstelle zu schliessen. Erwägungsgrund 39 nennt ausdrücklich auch geringfügige Funktionsverbesserungen wie optische Anpassungen oder neue Sprachen und Piktogramme als typischerweise unwesentlich.

Gegenausnahme: Ein Sicherheitsupdate kann trotz seines Schutzzwecks eine wesentliche Änderung sein — nämlich dann, wenn es den bestimmungsgemässen Zweck über das ursprünglich Vorgesehene hinaus verändert oder neue, nicht bewertete Risiken einführt[2]. Beispiel der Kommission: Ein Produkt verschlüsselt Dateien lokal; nach Entdeckung einer Schwachstelle stellt der Hersteller per Sicherheitsupdate auf einen serverseitigen Verschlüsselungsdienst um — Dateien werden nun hochgeladen und entfernt verarbeitet. Obwohl sicherheitsmotiviert, verändert das Update den Produktzweck grundlegend: aus lokaler Verschlüsselung wird eine Datenfernverarbeitung. Das ist eine wesentliche Änderung — und nebenbei ein Lehrstück dafür, wie eng wesentliche Änderung und RDPS-Frage zusammenhängen.

Ob ein Funktions- und ein Sicherheitsanteil getrennt oder gebündelt ausgeliefert werden, spielt für die Beurteilung übrigens keine Rolle (Erwägungsgrund 39)[1]: Entscheidend ist die Wirkung, nicht die Verpackung. Eine wesentliche Funktionsänderung lässt sich also nicht dadurch entschärfen, dass man sie an einen Sicherheitspatch koppelt.

Prüfschema für jeden Release

Damit die Einzelfallprüfung nicht im Bauchgefühl endet, lässt sich der folgende Ablauf als feste Prüfliste in den Release-Prozess einbauen:

1. Greift der CRA überhaupt? Wird ein Produkt mit digitalen Elementen ausgeliefert (installierte/selbsthostbare Software, Firmware, produktgebundene Datenfernverarbeitung)? Reines SaaS ohne solche Komponente: in der Regel NIS-2, nicht CRA.
2. Ändert das Update die Zweckbestimmung? Neue, ursprünglich nicht vorgesehene Verwendung → wesentliche Änderung.
3. Verändert das Update das Risikoprofil? Die Kommission nennt vier — nicht abschliessende — Faktoren[2]: Schafft das Update neue Bedrohungsvektoren (zusätzliche Schnittstellen, Kanäle, Ausführungsumgebungen, externe Abhängigkeiten)? Ermöglicht es neue Angriffsszenarien? Verändert es die Eintrittswahrscheinlichkeit bekannter Szenarien? Verändert es die möglichen Auswirkungen? Trifft einer dieser Faktoren zu, muss der Hersteller die Risiken neu bewerten.
4. Reines Sicherheitsupdate? Behebt nur eine Schwachstelle, senkt das Risiko, lässt den Zweck unberührt → keine wesentliche Änderung, sondern laufende Pflicht aus Anhang I Teil II.
5. Geringfügiges Funktionsupdate? Optik, Sprache, Icons ohne Risiko-/Zweckänderung → keine wesentliche Änderung.

Jede Einstufung sollte dokumentiert werden — gerade bei Altprodukten ist diese Dokumentation der Nachweis gegenüber der Marktüberwachung.

Was aus einer wesentlichen Änderung folgt

Steht fest, dass eine Änderung wesentlich ist, gilt das geänderte Produkt als neues Produkt, und seine Bereitstellung ist ein neues Inverkehrbringen[2]. Daraus folgt dreierlei:

• Herstellerrolle. Wer die wesentliche Änderung vornimmt, gilt als Hersteller des geänderten Produkts. Nimmt der Originalhersteller die Änderung selbst vor — der Regelfall bei iterativer Entwicklung —, bleibt er Hersteller; das Produkt gilt aber gleichwohl als neu in Verkehr gebracht.
• Erneute Konformitätsbewertung — fokussiert. Die Konformität ist zu überprüfen und das Produkt gegebenenfalls einer neuen Konformitätsbewertung zu unterziehen (Erwägungsgrund 41 CRA)[1]. Diese muss nicht bei null beginnen: Technische Dokumentation, Tests und Nachweise dürfen für die nicht betroffenen Produktteile wiederverwendet werden; die Bewertung konzentriert sich auf die geänderten Teile[2]. Welches Modul einschlägig ist, behandelt der Artikel zur Konformitätsbewertung.
• Einbindung der notifizierten Stelle. Wurde die ursprüngliche Bewertung unter Beteiligung einer notifizierten Stelle durchgeführt, ist eine potenziell wesentliche Änderung dieser mitzuteilen (Erwägungsgrund 41 CRA)[1].

Altprodukte und die Frist 11. Dezember 2027

Eine besonders praxisrelevante Konstellation betrifft den Produktbestand. Nach Art. 69 Abs. 2 CRA unterliegen Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, den Anforderungen der Verordnung nur dann, wenn sie nach diesem Datum einer wesentlichen Änderung unterzogen werden[1]. Ein Altprodukt bleibt also zunächst aussen vor — bis ein Update die Schwelle überschreitet. Ab diesem Moment gilt es als neu in Verkehr gebracht und muss den CRA vollständig erfüllen.

Daraus ergibt sich eine konkrete Obliegenheit: Hersteller, die den CRA beim erstmaligen Inverkehrbringen eines Altprodukts noch nicht angewendet haben, müssen einer Marktüberwachungsbehörde auf Verlangen belegen können, dass ihre nachfolgenden Updates keine wesentliche Änderung darstellen. Eine vorsorgliche Cybersicherheits-Risikobewertung nach Art. 13 Abs. 2 CRA erleichtert diesen Nachweis. Eine wichtige Ausnahme bleibt: Unabhängig von Art. 69 Abs. 2 gelten die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle für alle vor dem 11. Dezember 2027 in Verkehr gebrachten Produkte (Art. 69 Abs. 3 CRA)[1] — dazu der Artikel zu den CRA-Meldepflichten.

Praxisrelevant ist schliesslich die Einzelexemplar-Betrachtung: „In Verkehr gebracht" knüpft an jedes einzelne Exemplar an, nicht an den Produkttyp. Lagerware, die vor dem Stichtag in die Lieferkette gelangt ist, ist geschützt; identische Einheiten derselben Serie, die danach erstmals bereitgestellt werden, brauchen das CRA-CE.

Was unabhängig von der Einstufung gilt

Ein verbreitetes Missverständnis ist, ein Update sei „compliance-neutral", solange es keine wesentliche Änderung ist. Das trifft nicht zu. Unabhängig davon, ob ein Update als wesentliche Änderung qualifiziert, bleibt der Hersteller verpflichtet, die Sicherheit seiner Updates und seines Produkts während des gesamten Unterstützungszeitraums zu gewährleisten (Schwachstellenbehandlung nach Anhang I Teil II CRA) und die Risikobewertung sowie die technische Dokumentation fortlaufend aktuell zu halten[1] [2]. Die wesentliche Änderung entscheidet also nicht darüber, ob ein Update CRA-relevant ist, sondern nur darüber, ob es eine erneute Konformitätsbewertung und ein neues Inverkehrbringen auslöst. Die laufenden Lebenszyklus-Pflichten — und der Mindest-Unterstützungszeitraum von fünf Jahren nach Art. 13 Abs. 8 CRA[1] — bestehen ohnehin.

Der strategische Blick

Für Softwarehersteller folgt aus alldem weniger eine Last als eine Gestaltungsaufgabe.

Der wirksamste Hebel ist die ursprüngliche Risikobewertung. Weil die wesentliche Änderung immer am ursprünglich Bewerteten gemessen wird, lohnt es sich, geplante Funktionen von Anfang an vorausschauend mitzubewerten. Eine Funktion, deren Risiken bereits beschrieben und durch Massnahmen abgedeckt sind, kann später ausgerollt werden, ohne eine neue Konformitätsbewertung auszulösen — die Risikobewertung „pre-cleart" die Roadmap. Wie sie nach Art. 13 Abs. 2 CRA aufgebaut ist, behandelt der dritte Teil dieser Serie zu den abgestuften CRA-Pflichten.

Zweitens gehört die Frage „wesentlich oder nicht?" als fester, dokumentierter Prüfschritt in den Release-Prozess — am besten anhand der vier Faktoren oben. Und drittens ist die wesentliche Änderung kein Argument gegen häufige Updates: Sicherheitsupdates bleiben im Grundsatz unwesentlich, und wer Security- und Funktionsspuren trennt, schafft nicht laufend neue Bewertungen, sondern erfüllt seine Lebenszyklus-Pflichten. Konformitätskritisch wird es erst dort, wo neue Funktionen den Zweck verschieben oder unbewertete Risiken einführen.

crAIready macht Ihre Release-Pipeline CRA-fest

crAIready ist die AI-gestützte SaaS-Plattform, die Konformität nicht als Einmal-Projekt, sondern als Dauerzustand führt — passend zu einer Welt, in der laufend ausgeliefert wird:

• Change-Klassifizierung pro Release: strukturierte Bewertung jedes geplanten Updates anhand der Kriterien aus Art. 3 Nr. 30 und Erwägungsgrund 39 sowie der vier Prüffaktoren — mit klarer Ampel „wesentliche Änderung: ja / nein" je Version: die automatische Erkennung (etwa Versionssprung oder SBOM-Abweichung) schlägt vor, Sie bestätigen mit Begründung — bei „wesentlich" führt die Plattform direkt zur neuen Konformitätsbewertung.
• Risikobewertungs-Anker: Ihre ursprüngliche Risikobewertung bleibt als lebendes Dokument hinterlegt, das mit jeder Version fortgeschrieben und neu bestätigt wird — so wird jedes Update gegen den geprüften Zweck und das geprüfte Risikoprofil abgeglichen.
• Audit-Spur: Jedes Update wird als Sicherheits- oder Funktionsupdate klassifiziert und getrennt dokumentiert (Anhang I Teil II Nr. 2), eine Vermischung wird markiert — auditfest mit Ihrer technischen Dokumentation verknüpft.

Der Einstieg ist unser kostenloser CRA Quick-Check: eine erste, belastbare Orientierung, ob ein geplantes Update Ihres Produkts eine wesentliche Änderung darstellt — ohne Beratungsabhängigkeit. Die verbindliche Beurteilung Ihres Einzelfalls bleibt Ihnen vorbehalten.

Methodik dieser Recherche

Die rechtlichen Aussagen sind direkt gegen die Verordnung (EU) 2024/2847 (Cyber Resilience Act) geprüft, insbesondere Art. 3 Nr. 30 und die Erwägungsgründe 39–41; ergänzend herangezogen wurde der Kommentar von Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos 2025). Die mit konkreten Beispielen und Prüffaktoren belegten Aussagen stammen aus der Draft Communication der EU-Kommission (Ares(2026)2319816, Kapitel zur wesentlichen Änderung) — einem Entwurf vom März 2026; die Konsultation endete am 31. März 2026, eine finale Fassung lag zum Stand dieses Beitrags nicht vor. Formulierungen und Randnummern können sich in der finalen Version ändern.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 3 Nr. 2 und Nr. 30, Art. 13 Abs. 2, 8 und 10, Art. 14, Art. 21, Art. 22, Art. 26, Art. 69 Abs. 2 und 3, Anhang I Teil I und Teil II, Erwägungsgründe 12, 39, 40, 41.

[2] Europäische Kommission, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", März 2026 (Entwurf; Kapitel zur wesentlichen Änderung und zu Software-Updates). Öffentliche Konsultation bis 31. März 2026; finale Fassung zum Stand dieses Beitrags nicht veröffentlicht. Siehe Cyber Resilience Act – Europäische Kommission.

[3] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — insbesondere zur Auslegung der wesentlichen Änderung (Art. 3 Nr. 30) und zum Rollenwechsel nach Art. 21/22.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Die zitierte Draft Communication der EU-Kommission ist ein Entwurf; ihre finale Fassung war zum Stand dieses Beitrags nicht veröffentlicht. Stand: 22. Mai 2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Wo endet die CRA-Pflicht beim Software-Bundle? Wer für integrierte Komponenten verantwortlich ist — insbesondere für proprietäre Software, die auf Open Source aufsetzt — und warum die Annahme „die Verantwortung endet bei der Installation" rechtlich nicht trägt.

Veröffentlicht am: 22.05.2026 | Zuletzt geprüft am: 03.07.2026