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

Von Redaktion codAIx | 6. Juli 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 den CRA-Kommentaren von Wiebe und Schröder/Hartl angereichert — wollen wir im heutigen Artikel teilen. 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, der EU-Kommissions-Guidance und der Kommentarliteratur und zeigt, was für Rolling Releases 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 vom CRA ab und weist sie 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 Kapitel 4 „Substantial modifications and spare parts“ des veröffentlichten Guidance-Entwurfs der Kommission[2].

Drei Präzisierungen zum Prüfungsmassstab

Der juristische Kommentar von Schröder/Hartl schärft diesen Test an drei Stellen, die in der Praxis regelmässig übersehen werden[4].

Erstens: Nur Anhang I Teil I zählt. Massstab der Wesentlichkeitsprüfung ist ausschliesslich die Konformität mit den grundlegenden Cybersicherheitsanforderungen aus Anhang I Teil I. Die Anforderungen an die Schwachstellenbehandlung in Anhang I Teil II bleiben bei dieser Prüfung ausser Betracht (NK-CRA/Poncza, CRA Art. 3 Rn. 212)[4]. Das ist eine präzise und praktisch wichtige Eingrenzung: Ein Update, das ausschliesslich die Prozesse der Schwachstellenbehandlung berührt, ist über diese Alternative nicht als wesentlich einzustufen — was nichts daran ändert, dass die Pflichten aus Teil II ohnehin durchlaufend gelten (siehe unten).

Zweitens: „Auswirken“ ist weniger als „entfallen“. Für die Einstufung ist nicht erforderlich, dass die Konformität vollständig entfällt. Es genügt, dass sich die Änderung auf sie „auswirkt“, sie also in irgendeiner Weise beeinflusst. Nach den Erwägungsgründen 38 und 41 sind auch Konstellationen erfasst, in denen die Änderung zu Unklarheit über die Konformität führt und deshalb ein neues Konformitätsbewertungsverfahren erforderlich wird (Rn. 213)[4]. Wer also nach einem Update nicht sicher sagen kann, ob die ursprünglichen Nachweise noch tragen, kann diese Unsicherheit nicht zu seinen Gunsten auflösen.

Drittens: Die Ratio setzt die Grenze nach unten. Zweck der Definition ist es, sämtliche Änderungen zu erfassen, die das Cybersicherheitsniveau beeinträchtigen. Änderungen, die dieses Niveau nicht absenken und keine neuen Risiken schaffen, sollen dagegen gerade nicht erfasst werden (Rn. 211)[4]. Diese Zweckbestimmung ist das Auslegungsgeländer für alle Zweifelsfälle der folgenden Abschnitte.

Die zweite Alternative: Änderung des bestimmungsgemässen Zwecks

Die Zweckbestimmung ist keine objektive Grösse, sondern eine Festlegung, die der Hersteller selbst trifft. Art. 3 Nr. 23 CRA definiert sie über die Verwendung, für die das Produkt bestimmt ist, einschliesslich der Nutzungsumstände und -bedingungen, wie sie sich aus Gebrauchsanleitung, Werbe- oder Verkaufsmaterial und technischer Dokumentation ergeben[1]. Eine Änderung im Sinne von Art. 3 Nr. 30 liegt vor, wenn von dieser Festlegung abgewichen wird (NK-CRA/Poncza, CRA Art. 3 Rn. 214–217)[4].

Praktisch relevant wird das vor allem dort, wo eine Fehlanwendung möglich ist — und Hersteller müssen dabei auch die vernünftigerweise vorhersehbare Fehlanwendung im Sinne von Art. 3 Nr. 25 CRA in den Blick nehmen[1]. Der Grund für die Strenge liegt auf der Hand: Verschiebt sich der bestimmungsgemässe Zweck, ist damit zu rechnen, dass das Produkt für Zwecke eingesetzt wird, die bei der Konformitätsbewertung nie betrachtet wurden — mit dem Risiko, dass es für genau diese Einsatzszenarien kein angemessenes Mass an Cybersicherheit bietet. Für die Praxis heisst das: Wer die Produktbeschreibung, das Verkaufsmaterial oder die Dokumentation um neue Einsatzszenarien erweitert, verändert damit potenziell auch den geprüften Zweck.

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. Rolling Release und CRA stehen also nicht im Widerspruch — die Verordnung ist auf iterative Entwicklung eingestellt.

Ein Vorbehalt gehört an dieser Stelle allerdings dazu: Die Entwarnung stützt sich auf die Auslegung der Kommissions-Guidance. Die Kommentarliteratur legt bei Funktionsaktualisierungen einen strengeren Massstab an — dazu unten der Abschnitt „Zwei Ausgangsvermutungen“. Wer häufig Features ausliefert, sollte deshalb wissen, dass die Entlastung an der vorausschauenden Risikobewertung hängt, nicht an der Release-Frequenz allein.

Ein echter Graubereich bleibt zudem: 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.

Keine Pflicht, alte Versionsstände parallel zu pflegen

Eine zweite Erleichterung wird in der Praxis noch häufiger übersehen als die Trennung der Release-Spuren — dabei ist sie für iterativ ausliefernde Anbieter die wichtigste überhaupt.

Erwägungsgrund 40 CRA erkennt den „der Softwareentwicklung innewohnenden Wiederholungscharakter“ ausdrücklich an: Hersteller, die aufgrund einer späteren wesentlichen Änderung neue Versionen eines Softwareprodukts in den Verkehr gebracht haben, sollen während des Unterstützungszeitraums Sicherheitsaktualisierungen nur für die zuletzt in den Verkehr gebrachte Version anbieten dürfen[1].

Normativ steht das in Art. 13 Abs. 10 CRA. Der Wortlaut ist enger gefasst, als die Kurzformel vermuten lässt, und lohnt die genaue Lektüre: Hat ein Hersteller nachfolgende wesentlich geänderte Versionen eines Softwareprodukts in den Verkehr gebracht, so kann er die Sicherstellung der Einhaltung der in Anhang I Teil II Nr. 2 festgelegten grundlegenden Cybersicherheitsanforderung auf die zuletzt in den Verkehr gebrachte Version beschränken — allerdings nur, sofern die Nutzer der zuvor in den Verkehr gebrachten Version kostenlos Zugang zu der zuletzt in den Verkehr gebrachten Version haben und ihnen keine zusätzlichen Kosten für die Anpassung der Hardware- und Softwareumgebung entstehen, in der sie die Originalversion des Produkts verwenden[1].

Vier Punkte sind dabei praxisentscheidend:

1. Die Erleichterung betrifft nur Anhang I Teil II Nr. 2 — also die Anforderung, Schwachstellen unverzüglich zu behandeln und zu beheben, unter anderem durch Bereitstellung von Sicherheitsaktualisierungen. Die übrigen Anforderungen der Schwachstellenbehandlung bleiben bestehen: Erwägungsgrund 40 nennt ausdrücklich die Strategie zur koordinierten Offenlegung von Schwachstellen und Vorkehrungen zum Informationsaustausch über potenzielle Schwachstellen — und zwar für alle nachfolgenden, wesentlich geänderten Versionen[1].
2. Die beiden Bedingungen sind kumulativ. Kostenpflichtige Upgrades oder ein Versionssprung, der neue Hardware oder eine geänderte Softwareumgebung verlangt, lassen die Erleichterung entfallen. Erwägungsgrund 40 nennt als Positivbeispiel die Aufrüstung eines Desktop-Betriebssystems, die keine neue Hardware wie eine schnellere Zentraleinheit oder mehr Speicher erfordert[1].
3. Anknüpfungspunkt ist die wesentliche Änderung. Art. 13 Abs. 10 CRA spricht von „nachfolgenden wesentlich geänderten Versionen“. Für geringfügige Sicherheits- oder Funktionsaktualisierungen, die keine wesentliche Änderung darstellen, stellt Erwägungsgrund 40 gesondert klar, dass Hersteller sie nur für die letzte Version oder Unterversion eines nicht wesentlich geänderten Softwareprodukts bereitstellen können[1].
4. Hardware-Sonderfall. Ist ein Hardwareprodukt — Erwägungsgrund 40 nennt das Smartphone — nicht mit der neuesten Version des Betriebssystems kompatibel, mit dem es ursprünglich geliefert wurde, muss der Hersteller während des Unterstützungszeitraums zumindest für die letzte kompatible Version weiterhin Sicherheitsaktualisierungen bereitstellen[1].

Dieselbe Regel fassen die technischen FAQs der Kommissionsdienststellen in Nr. 4.3.2 zusammen: Unter den genannten Voraussetzungen sind Hersteller nicht verpflichtet, Schwachstellen für alle Versionen eines Softwareprodukts zu behandeln und zu beheben[5]. Die FAQs sind von den Kommissionsdienststellen erstellt, nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; sie sind als lebendes Dokument angelegt.

Für Rolling-Release- und Continuous-Deployment-Anbieter ist das die praktisch wichtigste Entlastung im gesamten Update-Regime: Es besteht keine Pflicht, alte Versionsstände parallel zu pflegen, solange der Wechsel auf die aktuelle Version für die Nutzer kostenlos und ohne Anpassung ihrer Hardware- und Softwareumgebung möglich ist. Wer ohnehin fortlaufend auf eine einzige aktuelle Linie ausliefert, erfüllt diese Bedingung typischerweise von selbst — genau deshalb passt das Modell gut zum CRA. Umgekehrt gilt: Wer Long-Term-Support-Zweige gegen Aufpreis anbietet oder Major-Upgrades kostenpflichtig stellt, kann sich für die Altzweige auf Art. 13 Abs. 10 CRA nicht berufen und bleibt dort in der vollen Pflicht aus Anhang I Teil II Nr. 2.

Funktionsupdates: drei Fallgruppen

Bei Updates, die neue Funktionen bringen, lassen sich aus Kapitel 4.3 der Kommissions-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 (Rn. 105 der Guidance)[2].

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 (Rn. 106 der Guidance)[2].

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 (Rn. 107 der Guidance)[2]. Die Lehre: Eine wesentliche Änderung bemisst sich nicht nach Programmieraufwand, sondern nach Sicherheitswirkung.

Zwei Ausgangsvermutungen: Kommentar und Guidance im Vergleich

An dieser Stelle sollten Hersteller wissen, dass die beiden massgeblichen Auslegungshilfen bei Funktionsaktualisierungen unterschiedlich ansetzen — obwohl sich beide auf Erwägungsgrund 39 CRA stützen.

Die Lesart des Kommentars. Schröder/Hartl grenzen Funktionsaktualisierungen ausdrücklich von Sicherheitsaktualisierungen ab: Werden einer Software neue Funktionen hinzugefügt, also solche, die die ursprünglich beabsichtigten Funktionen oder die Art beziehungsweise Leistung des Produkts verändern, kann dies die Angriffsfläche vergrössern und damit das Cybersicherheitsrisiko erhöhen — als Beispiel wird das Hinzufügen eines neuen Eingabeelements genannt. Funktionsaktualisierungen seien deshalb nach Erwägungsgrund 39 regelmässig als wesentliche Änderungen einzustufen; ausgenommen seien nur geringfügige Aktualisierungen wie visuelle Verbesserungen oder das Hinzufügen neuer Sprachen oder Piktogramme zur Benutzeroberfläche (NK-CRA/Poncza, CRA Art. 3 Rn. 223)[4]. Ob die Funktionsaktualisierung allein oder zusammen mit einer Sicherheitsaktualisierung bereitgestellt wird, ist für die Bewertung unerheblich (Rn. 224)[4].

Die Lesart der Guidance. Die Kommission stellt demgegenüber darauf ab, ob die neuen Funktionalitäten bereits in der Risikobewertung des Herstellers berücksichtigt waren: Waren sie vorgesehen, beschrieben, bewertet und mit Minderungsmassnahmen versehen, liegt keine wesentliche Änderung vor (Rn. 106 der Guidance — Beispiele: die im ursprünglichen Design bereits bewertete Gruppenchat-Funktion; die Aktivierung bereits angelegter, aber deaktivierter Steuerungsfunktionen)[2]. Zugleich stellt die Guidance klar, dass es nicht auf Umfang oder Komplexität der Änderung ankommt, sondern auf ihre Auswirkung auf das Cybersicherheitsrisikoprofil (Rn. 107)[2].

Wie sich das auflösen lässt. Der Unterschied liegt nicht im Massstab, sondern in der Ausgangsvermutung. Der Kommentar geht bei Funktionsaktualisierungen von einer Regelvermutung zugunsten der Wesentlichkeit aus; die Guidance macht die Einstufung davon abhängig, ob die Funktion in der ursprünglichen Risikobewertung bereits antizipiert war. Für Hersteller ist das weniger ein Widerspruch als ein Fingerzeig auf denselben Hebel: Wer neue Funktionen bereits in der ursprünglichen Risikobewertung vorsieht, dokumentiert und bewertet, steht nach beiden Massstäben besser da. Wer das nicht tut, ist nach der Kommentarlesart im Zweifel bereits bei einer wesentlichen Änderung, während er nach der Guidance immerhin noch den Nachweis führen kann, dass sich das Risikoprofil nicht verändert hat.

Für die Einordnung ist zweierlei zu bedenken: Der gegenwärtig veröffentlichte Annex zeigt, welche Auslegung des CRA die Kommission förmlich annehmen will. Nach der förmlichen Annahme können Marktüberwachungsbehörden diese Auslegung als Orientierung berücksichtigen. Ihre Entscheidungen müssen sie jedoch auf den CRA und andere verbindliche Rechtsakte stützen. Auch Gerichte sind an die Guidance nicht gebunden. Der Kommentar formuliert die strengere Lesart, an der sich eine vorsichtige Compliance-Strategie orientieren kann, gerade dort, wo Fehleinschätzungen teuer werden (Altprodukte, notifizierte Stelle im Verfahren, regulierte Abnehmerbranchen).

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]; bestätigt in Rn. 108 der Guidance[2]). 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, und selbst wenn das Update dabei erhebliche technische Änderungen mit sich bringt. Erwägungsgrund 39 nennt ausdrücklich auch geringfügige Funktionsverbesserungen wie optische Anpassungen oder neue Sprachen und Piktogramme als typischerweise unwesentlich. Der Kommentar formuliert die Grundregel enger: Softwareänderungen durch Sicherheitsaktualisierungen gelten dann nicht als wesentlich, wenn allein das Cybersicherheitsrisiko verringert werden soll und sich die Zweckbestimmung nicht ändert — nach Erwägungsgrund 39 seien damit in der Regel Fälle gemeint, in denen die Sicherheitsaktualisierung nur geringfügige Anpassungen des Quellcodes nach sich zieht (NK-CRA/Poncza, CRA Art. 3 Rn. 222)[4].

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 beziehungsweise erhöhte Cybersicherheitsrisiken einführt. Das kann insbesondere der Fall sein, wenn ein Update die Produktgrenzen oder die Abhängigkeitsstruktur des Produkts wesentlich verändert — etwa indem es Datenflüsse grundlegend verändert oder neue, von aussen erreichbare Schnittstellen hinzufügt (Rn. 109 der Guidance)[2]. Beispiel 49 der Guidance: Ein Produkt verschlüsselt Dateien lokal auf dem Gerät. Nach Entdeckung einer Schwachstelle stellt der Hersteller per Sicherheitsupdate auf einen von ihm selbst betriebenen Remote-Verschlüsselungsdienst um — Dateien werden nun hochgeladen und extern verarbeitet. Trotz der Sicherheitsmotivation ist das eine wesentliche Änderung, weil sich der Produktzweck grundlegend verschiebt: von lokaler Verschlüsselung zu einer Datenfernverarbeitung. Das Beispiel ist zugleich ein Lehrstück dafür, wie eng wesentliche Änderung und RDPS-Frage zusammenhängen.

Abgrenzung zu Drittanbieter-Änderungen: An anderer Stelle stellt die Guidance klar, dass eine grössere Änderung, die ein Drittanbieter an seinem Datenfernverarbeitungsdienst vornimmt, für sich genommen keine wesentliche Änderung des Produkts mit digitalen Elementen darstellt — diese Elemente liegen nicht in der Verantwortung des Herstellers (Rn. 208, Kapitel 8.2 der Guidance)[2]. Die Kommission empfiehlt Herstellern gleichwohl, sich vertraglich oder organisatorisch zusichern zu lassen, von solchen Änderungen ihrer Cloud-Dienstleister angemessen informiert zu werden, und auf dieser Grundlage ihre eigene Risikobewertung bei Bedarf zu aktualisieren. Auch dieser Punkt belegt, wie eng die wesentliche Änderung mit der RDPS-Abgrenzung verzahnt ist — vgl. dazu den Beitrag zur CRA-Grauzone weiter oben.

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. Der Kommentar bestätigt das ausdrücklich für Funktionsaktualisierungen (NK-CRA/Poncza, CRA Art. 3 Rn. 224)[4].

Seitenblick Reparaturen: Für Hersteller mit Hardware-Anteil lohnt der Vergleich zur physischen Welt. Eine Reparatur ist grundsätzlich keine wesentliche Änderung — auch dann nicht, wenn das Produkt zu Reparaturzwecken vorübergehend in ein Drittland ausgeführt wird, und auch dann nicht, wenn Ersatzteile aufgrund des technischen Fortschritts eine bessere Leistung erbringen; Massstab bleibt die im Entwurfsstadium festgelegte ursprüngliche Leistung. Anders liegt es nach Erwägungsgrund 42, wenn die Reparatur die Zweckbestimmung und die Funktionen ändert oder das Risikoniveau erhöht (NK-CRA/Poncza, CRA Art. 3 Rn. 218–220)[4]. Für Softwareänderungen gelten nach Erwägungsgrund 39 grundsätzlich dieselben Massstäbe wie für physische Reparaturen (Rn. 221)[4] — die Parallele ist also kein Zufall, sondern gewollt.

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. Massstab ist die vom Hersteller selbst festgelegte Zweckbestimmung nach Art. 3 Nr. 23 CRA, einschliesslich vernünftigerweise vorhersehbarer Fehlanwendungen (Art. 3 Nr. 25 CRA).
3. Verändert das Update das Risikoprofil? Die Kommission nennt vier — nicht abschliessende — Faktoren (Rn. 110 der Guidance)[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. Bestätigen sich die Annahmen und Schutzmassnahmen der ursprünglichen Risikobewertung weiterhin, bleibt das Update in aller Regel unterhalb der Schwelle zur wesentlichen Änderung; andernfalls ist eine Neubewertung erforderlich (Rn. 111 f. der Guidance)[2]. Bezugspunkt ist dabei allein Anhang I Teil I; Anhang I Teil II bleibt bei der Wesentlichkeitsprüfung ausser Betracht.
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.

Wer die strengere Lesart der Kommentarliteratur mitberücksichtigen will, ergänzt Schritt 5 um eine Rückfrage: Ist die neue Funktion in der ursprünglichen Risikobewertung beschrieben und bewertet? Lautet die Antwort Nein und geht die Funktion über Optik, Sprache oder Piktogramme hinaus, sollte im Zweifel von einer wesentlichen Änderung ausgegangen werden.

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 (Kapitel 4.4 der Guidance)[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 (Kapitel 4.4 der Guidance)[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. Gerade hier wirkt sich die strengere Kommentarlesart zu Funktionsaktualisierungen aus: Wer ein Altprodukt weiterhin um neue Funktionen ergänzt, sollte für jede dieser Funktionen dokumentieren, warum sie das Risikoprofil nicht verändert. 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. Die technischen FAQs der Kommissionsdienststellen bestätigen das in Nr. 7.2 unter ausdrücklichem Verweis auf Abschnitt 2.2 des „Blue Guide“ der EU-Kommission: Vom CRA ausgenommen sind nur die einzelnen vor dem 11. Dezember 2027 in Verkehr gebrachten Exemplare; Produkte, die nach einem nicht CRA-konformen Typ hergestellt werden, dürfen ab diesem Datum nicht mehr in Verkehr gebracht werden — auch dann nicht, wenn das erste Exemplar dieses Typs vorher in Verkehr gebracht wurde. Das Beispiel der FAQs: 10.000 vor dem Stichtag in Verkehr gebrachte Router muss der Hersteller nicht nachrüsten, selbst wenn sie den Endnutzer noch nicht erreicht haben; weitere 5.000 Exemplare desselben Typs darf er danach aber nicht mehr in Verkehr bringen[5]. Lagerware, die vor dem Stichtag in die Lieferkette gelangt ist, ist also geschützt; identische Einheiten derselben Serie, die danach erstmals bereitgestellt werden, brauchen das CRA-CE.

Für reine Softwareprodukte kommt eine Auslegungsfrage hinzu, die in dieser Serie an anderer Stelle ausführlich behandelt wird: Ob eine Softwareversion mit dem erstmaligen Angebot für alle Kopien als in Verkehr gebracht gilt — so die Kommissions-Guidance — oder ob jeder einzelne Download gesondert anknüpft — so die Kommentarliteratur —, ist nicht abschliessend geklärt. Die Folgen für Versionen, die über den 11. Dezember 2027 hinaus zum Download angeboten werden, behandelt der Auftaktartikel dieser Serie zu Zweck und Anwendungsbereich.

Die Ersatzteil-Ausnahme

Eng verwandt mit der Altproduktfrage ist eine Ausnahme, die Hersteller mit Hardware-Anteil unmittelbar betrifft. Art. 2 Abs. 6 CRA nimmt Ersatzteile aus dem Anwendungsbereich aus, die auf dem Markt bereitgestellt werden, um identische Komponenten in Produkten mit digitalen Elementen zu ersetzen, und die nach denselben Spezifikationen hergestellt werden wie die Bauteile, die sie ersetzen sollen[1]. Erwägungsgrund 29 CRA begründet das mit der wirksamen Reparierbarkeit und der Verlängerung der Produktlebensdauer und stellt klar, dass die Ausnahme beide Fallgruppen erfasst: Ersatzteile, die der Reparatur von Altprodukten dienen, die vor dem Geltungsbeginn der Verordnung zur Verfügung gestellt wurden, und Ersatzteile, die bereits ein Konformitätsbewertungsverfahren nach dem CRA durchlaufen haben[1].

Die Kommissions-Guidance präzisiert das in Kapitel 4.2 (Rn. 96–101)[2]. Drei Punkte sind praxisrelevant. Erstens greift die Ausnahme nur, wenn das Ersatzteil gezielt zur Reparatur oder zur Verlängerung der Lebensdauer eines bereits in Verkehr gebrachten Produkts geliefert wird; der Reparaturzweck muss aus dem Lieferkontext erkennbar sein — etwa durch Bezeichnung des Produkts oder der Produktfamilie in Bestellung oder Angebot oder durch Vertrieb über After-Sales- und Servicekanäle —, und entsprechende Nachweise sind für die Marktüberwachung bereitzuhalten. Die blosse technische Austauschbarkeit genügt nicht. Zweitens beurteilt sich die „Identität“ nach der funktionalen Rolle im Produkt und nach den für die Cybersicherheit relevanten Eigenschaften: Unterschiede ohne Einfluss auf das Risikoprofil schaden nicht, Unterschiede bei Algorithmen, Protokollen, kryptografischen Mechanismen oder Zugangskontrollen dagegen schon. Drittens ist ein nicht identisches Ersatzteil ein eigenes Produkt mit digitalen Elementen und damit selbst CRA-pflichtig; die grundlegenden Anforderungen sind dann im Licht seines bestimmungsgemässen Zwecks zu beurteilen, und wo einzelne Anforderungen wegen der Kompatibilität mit dem Altprodukt nicht erfüllbar sind, muss der Hersteller dies in der Risikobewertung abbilden und Ausgleichsmassnahmen vorsehen.

Für reine Softwarehersteller ist die Ausnahme selten einschlägig — sie ist auf austauschbare Komponenten zugeschnitten. Wer jedoch Firmware oder Komponenten als Ersatz für Altgeräte liefert, sollte die Abgrenzung kennen: Sie entscheidet darüber, ob eine Nachlieferung ein blosses Ersatzteil oder ein neues Inverkehrbringen ist. Die technischen FAQs der Kommissionsdienststellen treffen zu Ersatzteilen keine Aussage; massgeblich sind hier Verordnungstext und Guidance.

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 zu qualifizieren ist, 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 korrekt, vollständig und aktuell zu halten (Art. 13 Abs. 7 und Art. 31 Abs. 2 CRA[1]; bestätigt in Rn. 113 der Guidance[2]). Dass Anhang I Teil II bei der Wesentlichkeitsprüfung ausser Betracht bleibt, bedeutet also gerade nicht, dass diese Anforderungen unverbindlich wären — sie stehen nur ausserhalb des Prüfrasters von Art. 3 Nr. 30. Die wesentliche Änderung entscheidet folglich 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 bezieht die Roadmap vorausschauend ein. Das ist zugleich der Punkt, an dem die strengere Kommentarlesart und die Guidance zusammenfinden: Nach beiden Massstäben steht besser da, wer seine Roadmap antizipiert und dokumentiert hat. Wie die Risikobewertung 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 KI-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. 23, 25 und 30 sowie die Erwägungsgründe 38–42. Die mit konkreten Beispielen und Prüffaktoren belegten Aussagen stammen aus Kapitel 4 „Substantial modifications and spare parts“ (insb. 4.3 „Software updates as substantial modifications“, Rn. 103–113) sowie aus Kapitel 8.2 (Rn. 208) des im Annex veröffentlichten Entwurfs der Commission guidance on the application of Regulation (EU) 2024/2847 (Communication C(2026) 5252 final, Annex), deren Inhalt die Kommission am 27.07.2026 gebilligt hat. Der gegenwärtig veröffentlichte Annex zeigt, welche Auslegung des CRA die Kommission förmlich annehmen will. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten. Ob der Wortlaut bis zur förmlichen Annahme unverändert bleibt, lässt C(2026) 5252 offen.

Für die Ersatzteil-Ausnahme wurden zusätzlich Art. 2 Abs. 6 und Erwägungsgrund 29 CRA sowie Kapitel 4.2 der Guidance (Rn. 96–101) ausgewertet; für die Versionsregel des Art. 13 Abs. 10 CRA wurde der Wortlaut der Vorschrift und des Erwägungsgrundes 40 unmittelbar am Verordnungstext geprüft. Ergänzend herangezogen wurden die technischen FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026), hier Nr. 4.3.2 und Nr. 7.2; sie sind nach eigener Angabe keine offizielle Position der Kommission, nicht verbindlich und als lebendes Dokument angelegt und werden in diesem Beitrag nur bestätigend zu Verordnungstext und Guidance angeführt. Ergänzend herangezogen wurden ferner zwei juristische Kommentare: Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos 2025), sowie der artikelweise Kommentar von Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA (1. Auflage 2026, Nomos), dessen Kommentierung zu Art. 3 Nr. 30 von Poncza stammt. Die Aussagen aus diesen Kommentaren sind durchgehend paraphrasiert und mit Randnummer belegt; wörtliche Übernahmen erfolgen nicht.

Wichtig für die Einordnung: Kommissions-Guidance und Kommentar gehen bei Funktionsaktualisierungen von unterschiedlichen Ausgangsvermutungen aus, obwohl sich beide auf Erwägungsgrund 39 CRA stützen. Der Kommentar behandelt Funktionsaktualisierungen regelmässig als wesentliche Änderungen, die Guidance stellt auf die vorherige Berücksichtigung in der Risikobewertung des Herstellers ab. Dieser Beitrag stellt beide Positionen dar und wertet keine von ihnen ab. Der veröffentlichte Annex dokumentiert die von der Kommission zur förmlichen Annahme vorgesehene Auslegung; er bindet weder Marktüberwachungsbehörden noch Gerichte. Der Kommentar wird als strengere Lesart für eine vorsichtige Compliance-Strategie ausgewiesen. Randnummern ausserhalb der zitierten Passagen (etwa zu Art. 3 Nr. 30 selbst oder zu den Erwägungsgründen) stammen unmittelbar aus der Verordnung und wurden unverändert übernommen.

Versionshinweis (v12, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 06.07.2026 gesetzt und das bereits durch die v11-Prüfung belegte Prüfdatum im Footer auf den 12.08.2026 berichtigt; zeitabhängige Formulierungen bleiben unverändert.

Versionshinweis (v11, 12.08.2026): Der Verfahrensstatus des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs wurde im Artikeltext, in der Methodik, in Quelle [2] und im Haftungsausschluss präzisiert. Die Bezeichnungen als finale Guidance, die unbelegte Erwartung ausbleibender Änderungen und die Aussage einer für Marktüberwachungsbehörden massgeblichen Auslegung wurden korrigiert. Die historischen Versionshinweise bleiben unverändert.

Versionshinweis (v10, 06.08.2026): Diese Version ergänzt drei Befunde aus dem Verordnungstext, der Kommissions-Guidance und den technischen FAQs der Kommissionsdienststellen (Version 1.3 vom 01.07.2026). Erstens: neuer Unterabschnitt „Keine Pflicht, alte Versionsstände parallel zu pflegen“ im Rolling-Release-Kapitel, der Erwägungsgrund 40 und Art. 13 Abs. 10 CRA im Wortlaut auswertet — Beschränkung auf die zuletzt in den Verkehr gebrachte Version, begrenzt auf Anhang I Teil II Nr. 2, unter den kumulativen Bedingungen des kostenlosen Zugangs und der fehlenden Zusatzkosten für die Anpassung der Hardware- und Softwareumgebung, mit den Sonderregeln für geringfügige Aktualisierungen und für nicht kompatible Hardwareprodukte sowie mit dem Hinweis auf FAQ Nr. 4.3.2; der bisherige Einzelsatz zu Erwägungsgrund 40 im Rolling-Release-Abschnitt ist darin aufgegangen. Zweitens: neuer Unterabschnitt „Die Ersatzteil-Ausnahme“ im Altprodukt-Kapitel zu Art. 2 Abs. 6 und Erwägungsgrund 29 CRA sowie zu Kapitel 4.2 der Guidance (Rn. 96–101). Drittens: Die Passage zur Einzelexemplar-Betrachtung ist um FAQ Nr. 7.2 (Router-Beispiel 10.000/5.000, Verweis auf Abschnitt 2.2 des „Blue Guide“) belegt und um einen Querverweis auf den Auftaktartikel der Serie zu Zweck und Anwendungsbereich ergänzt, damit beide Beiträge zur Frage des Inverkehrbringens von Softwareversionen dieselbe Linie fahren. Quellenverzeichnis um Eintrag [5] (FAQs der Kommissionsdienststellen) erweitert, Einträge [1] und [2] um die neu verwendeten Fundstellen ergänzt; Methodik entsprechend angepasst. Alle bestehenden Verweise, Querverweise und URLs blieben unverändert.

Versionshinweis (v9, 06.08.2026): Diese Version ergänzt den Beitrag um Befunde aus dem Kommentar von Schröder/Hartl (1. Aufl. 2026, Nomos; Art. 3 Nr. 30 kommentiert von Poncza). Neu aufgenommen wurden: die Eingrenzung des Prüfungsmassstabs auf Anhang I Teil I unter Ausklammerung von Anhang I Teil II (Rn. 212), die Klarstellung, dass ein blosses „Auswirken“ auf die Konformität genügt und auch Unklarheitsfälle erfasst sind (Rn. 213), die Ratio der Definition (Rn. 211), ein neuer Abschnitt zur Änderung des bestimmungsgemässen Zwecks nach Art. 3 Nr. 23 und Nr. 25 CRA (Rn. 214–217), die engere Formulierung der Grundregel für Sicherheitsaktualisierungen (Rn. 222) sowie ein Seitenblick auf Reparaturen und die Parallele zu Softwareänderungen (Rn. 218–221). Zentrale Ergänzung ist der neue Abschnitt „Zwei Ausgangsvermutungen: Kommentar und Guidance im Vergleich“, der die unterschiedliche Behandlung von Funktionsaktualisierungen durch Kommentar (Rn. 223 f.) und Guidance (Rn. 106 f.) darstellt und praktisch auflöst. Prüfschema, Altprodukt-Abschnitt, strategischer Blick, Methodik und Quellenverzeichnis wurden entsprechend angepasst; alle bestehenden Verweise auf die Guidance C(2026) 5252 final und auf die Verordnung blieben unverändert.

Versionshinweis (v8, 05.08.2026): Diese Version ersetzt sämtliche Bezüge auf die Draft Communication Ares(2026)2319816 durch die finale Guidance C(2026) 5252 final. Das Beispiel zur Umstellung von lokaler auf serverseitige Verschlüsselung wurde gegen den finalen Wortlaut geprüft und der Verweis auf Rn. 109 (Beispiel 49) korrigiert. Ein neuer Absatz zu Drittanbieter-Änderungen an Datenfernverarbeitungsdiensten (Rn. 208, Kapitel 8.2) wurde ergänzt. Die übrigen Rn.-Verweise zu Kapitel 4.3 (Rn. 103–113) wurden präzisiert und mit konkreten Randnummern versehen; die Zitate zur Verordnung (Art. 3 Nr. 30, Erwägungsgründe 39–41) blieben unverändert. Haftungsausschluss und Quellenverzeichnis wurden entsprechend aktualisiert.

Quellen

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

[2] Europäische Kommission, Communication C(2026) 5252 final, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026. Der Annex ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten (Stand 12.08.2026). Kapitel 4 „Substantial modifications and spare parts“, insb. 4.2 (Ersatzteile, Rn. 96–101) und 4.3 (Rn. 103–113), sowie Kapitel 8.2 (Rn. 208). Verfügbar unter: Commission publishes new guidance to support timely Cyber Resilience Act implementation (Annex-Download: ec.europa.eu).

[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.

[4] Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 30 kommentiert von Poncza. — in diesem Beitrag herangezogen: CRA Art. 3 Rn. 211 (Ratio der Definition), Rn. 212 (Massstab Anhang I Teil I), Rn. 213 („auswirken“), Rn. 214–217 (bestimmungsgemässer Zweck), Rn. 218–220 (Reparaturen), Rn. 221 (Parallele Softwareänderung/Reparatur), Rn. 222 (Sicherheitsaktualisierungen), Rn. 223 f. (Funktionsaktualisierungen).

[5] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.2026 — in diesem Beitrag herangezogen: Nr. 4.3.2 (keine Pflicht zur Behebung von Schwachstellen in allen Versionen eines Softwareprodukts) und Nr. 7.2 (Bestandsschutz bezogen auf das einzelne Exemplar, nicht auf den Produkttyp). Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; als lebendes Dokument angelegt. Verfügbar unter: Cyber Resilience Act implementation — frequently asked questions

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. Der gegenwärtig veröffentlichte Annex zu C(2026) 5252 final zeigt, welche Auslegung des CRA die Kommission förmlich annehmen will. Nach der förmlichen Annahme können Marktüberwachungsbehörden diese Auslegung als Orientierung berücksichtigen; gebunden sind Behörden und Gerichte daran nicht. Zur Behandlung von Funktionsaktualisierungen vertreten Guidance-Entwurf und Kommentarliteratur unterschiedliche Ausgangsvermutungen; dieser Beitrag stellt beide dar, ohne eine abschliessende rechtliche Bewertung vorzunehmen. Stand: 12. August 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: 06.07.2026 | Zuletzt geprüft am: 13.08.2026

Stand: 13.08.2026 (v13 — freigegebene Schlusskorrektur: Einstieg, Gedankenstriche, Rolling Release, EU-Guidance und Remote-Verschlüsselungsdienst korrigiert; SaaS/PaaS/IaaS sprachlich richtig vom CRA abgegrenzt; Anglizismen reduziert. Vorherige Fassung: v12; zeitabhängige Formulierungen unverändert.)