Von Redaktion codAIx | 6. Juli 2026

Es war ein dunkler Winterabend 2025. Vier von uns arbeiteten angestrengt im Büro. Es war mucksmäuschenstill, als plötzlich die Frage durch den Raum hallte: „Muss ich im Rolling Release dann jetzt jeden Tag mehrfach eine Konformitätsbewertung machen oder wie?“ Oha, dachten wir. Die Frage ist seitdem nicht verschwunden. Unsere damaligen Erkenntnisse lassen sich inzwischen mit der EU-Guidance und den CRA-Kommentaren von Wiebe[3] und Schröder/Hartl[4] genauer einordnen. Die kurze Antwort lautet: Nein. Der CRA misst die Qualität einer Änderung, nicht ihre Häufigkeit. Erst wenn ein Update eine „wesentliche Änderung“ im Sinne von Art. 3 Nr. 30 CRA ist, gilt das Produkt als neu in Verkehr gebracht. Was das für Rolling Releases und Bestandsprodukte bedeutet, zeigt die folgende Auswertung.

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 juristische Scharnierbegriff dafür lautet wesentliche Änderung (englisch: substantial modification). Wird diese Schwelle überschritten, gilt das geänderte Produkt rechtlich als neu in Verkehr gebracht. Seine Konformität ist zu überprüfen; gegebenenfalls wird eine neue Konformitätsbewertung erforderlich. Bei einer unwesentlichen Änderung trägt die ursprüngliche Konformität dagegen weiter. Die Frage „wesentlich oder nicht?“ gehört für Softwarehersteller deshalb als Routineprüfung vor jedes Release.

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.

Dabei sind zwei Punkte wichtig. Bereits eine der beiden Bedingungen genügt; sie gelten alternativ, nicht kumulativ. Praktisch noch bedeutsamer ist der Vergleichsmassstab: die ursprüngliche Risikobewertung. Erwägungsgrund 39 CRA stellt klar, dass eine Änderung wesentlich ist, wenn sie das Cybersicherheitsrisiko verändert und der Hersteller dieses veränderte oder zusätzliche Risiko in seiner ursprünglichen Risikobewertung nicht berücksichtigt hat[1]. Art. 26 Abs. 2 lit. d unterstreicht das Gewicht des Begriffs, indem er die EU-Kommission ausdrücklich auffordert, in ihren Leitlinien auf den „Begriff der wesentlichen Änderung“ einzugehen. Kapitel 4 „Substantial modifications and spare parts“ der veröffentlichten Guidance erfüllt genau diese Aufgabe[2].

Drei Präzisierungen zum Prüfungsmassstab

Poncza präzisiert diesen Test in seiner Kommentierung im NK-CRA 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 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 Art. 3 Rn. 214–217)[4].

Besonders relevant wird das, wenn eine Fehlanwendung möglich ist. Hersteller müssen dabei auch die vernünftigerweise vorhersehbare Fehlanwendung im Sinne von Art. 3 Nr. 25 CRA berücksichtigen[1] (NK-CRA/Poncza Art. 3 Rn. 216 f.)[4]. Die strenge Betrachtung hat einen nachvollziehbaren Grund: Verschiebt sich der bestimmungsgemässe Zweck, kann das Produkt in Einsatzszenarien gelangen, die bei der Konformitätsbewertung nie betrachtet wurden — und für die es möglicherweise kein angemessenes Mass an Cybersicherheit bietet. Schon eine Erweiterung von Produktbeschreibung, Verkaufsmaterial oder Dokumentation um neue Einsatzszenarien kann daher den geprüften Zweck verändern.

Vier Konstellationen, in denen die Einstufung zählt

Die Guidance (Rn. 91) nennt vier Konstellationen, in denen die Einordnung gebraucht wird:

  • 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 nach der Guidance ebenfalls als Hersteller (Art. 69 Abs. 2 CRA in Verbindung mit Guidance Rn. 91 lit. c; dazu unten ausführlich)[1][2].
  • Iterative Weiterentwicklung durch den Originalhersteller: Für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, entscheidet die Einstufung darüber, ob spätere Änderungen eine neue Konformitätsbewertung auslösen.

Im Alltag reiner Softwarehersteller, die ihr eigenes Produkt fortlaufend weiterentwickeln, steht meist die vierte Konstellation im Vordergrund. Die ersten drei betreffen vor allem einen Rollenwechsel: Wer ein fremdes Produkt wesentlich verändert, wird selbst zum Hersteller und übernimmt die entsprechenden CRA-Pflichten (Wiebe, § 4 Rn. 29)[3].

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

„Wenn jedes Inverkehrbringen Pflichten auslöst und wir zwanzigmal pro Woche deployen, ersticken wir in Konformitätsbewertungen.“ Diese Sorge ist in agilen Teams verständlich, beruht aber auf einem falschen Ausgangspunkt. Der CRA misst weder die Häufigkeit eines Releases noch die Menge des geänderten Codes. Massgeblich ist die Qualität der Änderung im Verhältnis zur 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 schafft zugleich gute Voraussetzungen dafür, dass diese Releases in aller Regel nicht als wesentliche Änderung einzustufen sind; Ausnahmen bleiben möglich. 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 (NK-CRA/Poncza Art. 3 Rn. 223[4]; ähnlich Wiebe, § 4 Rn. 29[3]) — 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.

Für Standalone-Software beantwortet die Guidance aus Sicht der Kommission, wann eine Version in Verkehr gebracht ist: sobald ihre Herstellungsphase abgeschlossen ist und sie erstmals bereitgestellt wird; alle Kopien gelten als gleichzeitig in Verkehr gebracht (Rn. 13 f., Beispiel 1). Nicht wesentliche Iterationen ändern diesen Zeitpunkt nicht (Rn. 15, Beispiel 2). Bei Kombination mit Hardware gilt das nicht (Rn. 16)[2]. Die Kommentarliteratur sieht es teils anders (siehe unten). Für Continuous Deployment empfiehlt sich gleichwohl 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]. Pflichtnorm ist Art. 13 Abs. 8 UAbs. 6 in Verbindung mit Anhang I Teil II Nr. 5 und 6 CRA. Die Guidance bestätigt, dass die übrigen Anforderungen des Anhangs I Teil II und die Meldepflichten nach Art. 14 CRA bestehen bleiben (Rn. 131)[2].
  2. Die beiden Bedingungen sind kumulativ. Kostenpflichtige Upgrades oder ein Versionssprung, der neue Hardware oder grundlegende Änderungen der Betriebsumgebung erfordert, lassen die Erleichterung entfallen. Üblicher Aufwand wie Tests, Konfigurationsanpassungen oder Updates von Software-Abhängigkeiten gilt nach der Guidance dagegen nicht als „zusätzliche Kosten“ (Rn. 130)[2]. 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 fasst die FAQ 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].

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 zusätzliche Kosten für die 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 den Wechsel auf die aktuelle Version kostenpflichtig macht, etwa durch kostenpflichtige Major-Upgrades, kann sich für die Altversionen nicht auf Art. 13 Abs. 10 CRA berufen und bleibt dort in der vollen Pflicht aus Anhang I Teil II Nr. 2. Ein zusätzlich angebotener, kostenpflichtiger Long-Term-Support-Zweig schadet für sich genommen nicht, solange der Umstieg auf die aktuelle Version kostenlos und ohne zusätzliche Anpassungskosten möglich bleibt.

Die Kehrseite: Jede wesentlich geänderte Version gilt als neu in Verkehr gebracht und braucht einen eigenen, nach Art. 13 Abs. 8 CRA festgelegten Unterstützungszeitraum, grundsätzlich also mindestens fünf Jahre, wobei fünf Jahre kein Regelwert sind (Guidance Rn. 126, 128, 131)[1][2]. Stellt der Hersteller die Behebung von Schwachstellen für ältere Versionen nach Art. 13 Abs. 10 ein, sollten deren Nutzer, soweit technisch möglich, darüber informiert werden (Art. 13 Abs. 19 CRA; Guidance Fn. 18)[1][2].

Zwei Grenzen bleiben: Jede bereitgestellte Sicherheitsaktualisierung muss nach Art. 13 Abs. 9 CRA mindestens zehn Jahre nach ihrer Bereitstellung oder für die restliche Dauer des Unterstützungszeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist. Wer historische Versionen in einem öffentlichen Softwarearchiv anbietet, muss die Nutzer nach Art. 13 Abs. 11 CRA klar und leicht zugänglich über die Risiken nicht unterstützter Software informieren[1].

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. Poncza grenzt im NK-CRA 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 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. Die Kommentierung im NK-CRA 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.

Die NK-CRA-Kommentierung 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. Das NK-CRA 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 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 Änderungen an Drittanbieter-Ferndiensten: An anderer Stelle stellt die Guidance klar, dass eine grössere Änderung an einem Drittanbieter-Ferndienst 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.

Für die Beurteilung spielt es keine Rolle, ob Funktions- und Sicherheitsanteil getrennt oder gebündelt ausgeliefert werden (Erwägungsgrund 39)[1]. Massgeblich ist ihre Wirkung, nicht die Verpackung. Eine wesentliche Funktionsänderung verliert ihre Bedeutung also nicht dadurch, dass sie an einen Sicherheitspatch gekoppelt wird. Das NK-CRA bestätigt dies ausdrücklich für Funktionsaktualisierungen (NK-CRA/Poncza 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 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)? Reine Browser-SaaS ohne bereitgestelltes Software- oder Hardwareprodukt fällt nicht unter den CRA (Erwägungsgrund 12 CRA)[1]; ob NIS-2 einschlägig ist, ist gesondert zu prüfen.
  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 keiner dieser Faktoren zu und bleiben die Annahmen und Schutzmassnahmen der ursprünglichen Risikobewertung gültig, ist das Update wahrscheinlich keine wesentliche Änderung (Rn. 111 der Guidance). Trifft einer zu, muss der Hersteller die Risiken neu bewerten und prüfen, ob die grundlegenden Anforderungen weiterhin erfüllt sind und ob das Update neue oder erhöhte, nicht vorhergesehene Risiken einführt. Ist das der Fall und wurden diese Risiken in der ursprünglichen Risikobewertung nicht berücksichtigt, liegt in der Regel eine wesentliche Änderung vor (Rn. 104, 112 der Guidance; Erwägungsgrund 39)[1][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. Bei Modul B+C ist die notifizierte Stelle über alle Änderungen am zugelassenen Baumuster und am Verfahren zur Schwachstellenbehandlung zu unterrichten, die die Konformität oder die Gültigkeit der Bescheinigung beeinträchtigen könnten; solche Änderungen erfordern eine Ergänzung der EU-Baumusterprüfbescheinigung (Anhang VIII Teil II Nr. 7 CRA). Bei Modul H sind geplante Änderungen des Qualitätssicherungssystems mitzuteilen (Anhang VIII Teil IV Nr. 3.5 CRA); für neue oder wesentlich geänderte Produkte vereinfacht ein zugelassenes System das Verfahren (FAQ Nr. 6.3)[1][5].

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] (Wiebe, § 4 Rn. 43)[3]. Ein Altprodukt bleibt also zunächst aussen vor — bis ein Update die Schwelle überschreitet. Ab diesem Moment gilt es als neu in Verkehr gebracht. Nach der unverbindlichen Guidance muss der Originalhersteller deshalb aber nicht ohne Weiteres das gesamte Altprodukt auf CRA-Niveau bringen: Seine Pflichten beschränken sich auf die wesentlich geänderten Teile, es sei denn, die Änderung beeinträchtigt die Cybersicherheit des Produkts insgesamt (Guidance Rn. 124; für Änderungen durch Dritte Art. 22 Abs. 2 CRA sowie Guidance Rn. 118–121)[1][2].

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 seit dem 11. September 2026 für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle und erfassen auch vor dem 11. Dezember 2027 in Verkehr gebrachte Produkte (Art. 69 Abs. 3, Art. 71 Abs. 2 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 FAQ der Kommissionsdienststellen bestätigt 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 FAQ: 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 in Verkehr gebracht werden, müssen den CRA erfüllen; ihre CE-Kennzeichnung drückt dann auch die CRA-Konformität aus.

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 (NK-CRA/Mehnert Art. 3 Rn. 122; NK-CRA/Poncza Art. 3 Rn. 135)[4] —, 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 FAQ der Kommissionsdienststellen trifft zu Ersatzteilen keine Aussage; massgeblich sind hier Verordnungstext und Guidance.

Was unabhängig von der Einstufung gilt

Auch ein unwesentliches Update beendet die laufenden Pflichten nicht. Während des festgelegten Unterstützungszeitraums sind Schwachstellen wirksam nach Anhang I Teil II zu behandeln; Risikobewertung und technische Dokumentation sind während dieses Zeitraums soweit angezeigt zu aktualisieren (Art. 13 Abs. 3, 7 und 8 sowie Art. 31 Abs. 2 CRA[1]; bestätigt in Rn. 113 der Guidance[2]). Der Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre; ist die voraussichtliche Nutzungsdauer kürzer, muss er dieser kürzeren Dauer entsprechen. Ein Regelwert für alle Produkte sind fünf Jahre nach der Guidance nicht (Rn. 126)[2]. Dass Anhang I Teil II bei der Wesentlichkeitsprüfung ausser Betracht bleibt, macht diese Anforderungen nicht unverbindlich; sie liegen lediglich ausserhalb des Prüfrasters von Art. 3 Nr. 30. Die Einordnung bestimmt, ob eine erneute Konformitätsbewertung und ein neues Inverkehrbringen ausgelöst werden.

Der strategische Blick

Für Softwarehersteller ergibt sich daraus vor allem 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.

Daneben braucht jeder Release-Prozess einen festen, dokumentierten Prüfschritt zur Frage „wesentlich oder nicht?“; die vier Faktoren oben bieten dafür ein Raster. Häufige Updates stehen dem nicht entgegen. Sicherheitsupdates bleiben im Grundsatz unwesentlich, und die Trennung von Security- und Funktionsspuren erzeugt nicht laufend neue Bewertungen, sondern erfüllt die Lebenszyklus-Pflichten. Konformitätskritisch wird es dort, wo neue Funktionen den Zweck verschieben oder unbewertete Risiken einführen.

Das Wichtigste für Hersteller

  • Nicht jedes Release löst eine neue Konformitätsbewertung aus: Massgeblich ist allein, ob eine Änderung die Konformität mit Anhang I Teil I berührt oder den bestimmungsgemässen Zweck ändert (Art. 3 Nr. 30 CRA).
  • Sicherheitsupdates sind im Grundsatz keine wesentliche Änderung; das gilt nicht, wenn sie den Zweck verschieben oder neue Risiken einführen. Bei Funktionsupdates entscheidet, ob die Funktion in der ursprünglichen Risikobewertung bereits berücksichtigt war.
  • Nach Art. 13 Abs. 10 CRA müssen alte Versionsstände nicht parallel gepflegt werden, solange der Wechsel auf die aktuelle Version kostenlos und ohne zusätzliche Anpassungskosten möglich ist.
  • Altprodukte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen erst mit einer späteren wesentlichen Änderung unter den CRA; die Meldepflichten nach Art. 14 CRA gelten für sie bereits seit dem 11. September 2026.
  • Jede Einstufung als wesentlich oder unwesentlich sollte dokumentiert werden.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • Onboarding-Wizard und CRA-Wegweiser: erfassen Produkte und Rolle, unterstützen die Einordnung in die Produktklassen und führen je Produkt Schritt für Schritt durch die Pflichten – mit Kennzeichnung, welche bereits gelten und welche erst ab dem 11. Dezember 2027 verbindlich werden.
  • Schwachstellen & CVD: gleicht die SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet sie für die Triage auf. Ob eine Meldepflicht nach Art. 14 besteht, wird gesondert geprüft.
  • Dokumentation & Konformität: erstellt Entwürfe der technischen Dokumentation nach Anhang VII und der EU-Konformitätserklärung zur fachlichen Prüfung und Freigabe.

Für eine erste Einordnung steht der kostenlose CRA-Quick-Check bereit: Er bietet eine unverbindliche Ersteinschätzung dazu, ob und wie der CRA ein Produkt betreffen könnte. Ob ein konkretes Update eine wesentliche Änderung darstellt, beurteilt und dokumentiert das verantwortliche Unternehmen im Einzelfall.

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) der am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichten Commission guidance on the application of Regulation (EU) 2024/2847. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte.

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 wurde die FAQ der Kommissionsdienststellen (Version 1.4 vom 04.09.2026), hier Nr. 4.3.2, 6.3 und 7.2; sie ist nach eigener Angabe keine offizielle Position der Kommission, nicht verbindlich und als lebendes Dokument angelegt und wird 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, Stand Juni 2025), sowie der artikelweise Kommentar von Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar (1. Aufl. 2026, Stand Dezember 2025), 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 NK-CRA gehen bei Funktionsaktualisierungen von unterschiedlichen Ausgangsvermutungen aus, obwohl sich beide auf Erwägungsgrund 39 CRA stützen. Das NK-CRA behandelt Funktionsaktualisierungen regelmässig als wesentliche Änderungen (NK-CRA/Poncza Art. 3 Rn. 223), die Guidance stellt auf die vorherige Berücksichtigung in der Risikobewertung des Herstellers ab. Artikel- und Erwägungsgrundangaben beziehen sich unmittelbar auf den Verordnungstext.

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, 3, 7, 8 (insbesondere UAbs. 6), 9, 10, 11 und 19, 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, 5 und 6), Anhang VIII Teil II Nr. 7 und Teil IV Nr. 3.5, Erwägungsgründe 12, 29, 38, 39, 40, 41, 42.

[2] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026. Die Guidance ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sie ist nicht verbindlich und schafft keine zusätzlichen Pflichten. Rn. 13–16 mit Beispielen 1 und 2 (Inverkehrbringen von Standalone-Software), Kapitel 4 „Substantial modifications and spare parts“, insb. 4.2 (Ersatzteile, Rn. 96–101) und 4.3 (Rn. 103–113), Rn. 126 (fünf Jahre kein Regelwert) und Rn. 128–131 mit Fn. 18 (Unterstützungszeitraum, Art. 13 Abs. 10), 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 — Wiebe, § 4 Rn. 29 (wesentliche Änderung, Rollenwechsel nach Art. 21/22, neue Funktionen als typisches Beispiel), § 4 Rn. 43 (Art. 69 Abs. 2).

[4] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Mehnert, Art. 3 Rn. 122 (Inverkehrbringen je Download); Poncza, Art. 3 Rn. 135 (Inverkehrbringen je Download); Poncza (Art. 3 Nr. 30), 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.4 vom 04.09.2026 — in diesem Beitrag herangezogen: Nr. 4.3.2 (keine Pflicht zur Behebung von Schwachstellen in allen Versionen eines Softwareprodukts), Nr. 6.3 (Modul H) 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. Keine Rechtsberatung im Sinne des RDG. Die veröffentlichte Guidance kann Marktüberwachungsbehörden als Orientierung dienen; gebunden sind Behörden und Gerichte daran nicht. Zur Behandlung von Funktionsaktualisierungen vertreten Guidance und Kommentarliteratur unterschiedliche Ausgangsvermutungen; dieser Beitrag stellt beide dar, ohne eine abschliessende rechtliche Bewertung vorzunehmen. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 06.07.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: CRA-Pflicht bei Software-Bundles, Komponenten und Open Source — 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.