Artikel 69(2) des Cyber Resilience Act, Verordnung (EU) 2024/2847, sagt, dass Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, „den Anforderungen dieser Verordnung nur unterliegen, wenn sie ab diesem Datum wesentlichen Änderungen unterzogen werden“. Die Meldepflicht des Artikels 14 gilt für sie unabhängig davon, seit dem 11. September 2026. Alles andere, die grundlegenden Anforderungen des Anhangs I, die Konformitätsbewertung, die technische Dokumentation, die CE-Kennzeichnung, wartet auf die erste wesentliche Änderung. Für ein Softwareunternehmen mit einem Produkt, das bereits auf dem Markt ist, ist „was ist eine wesentliche Änderung“ daher die Frage, die entscheidet, ob und wann die Verordnung dieses Produkt überhaupt erreicht. Und für ein Produkt, das nach diesem Datum in Verkehr gebracht wird, entscheidet sie, ob ein Release eine neue Konformitätsbewertung braucht.

Die Verordnung definiert den Begriff in Artikel 3(30) und erläutert ihn in Erwägungsgrund 39, und die Leitlinien der Kommission vom 27. Juli 2026, C(2026) 5252, Abschnitt 4.3, Randnummern 103 bis 113, wenden ihn auf Software-Updates an, mit elf durchgerechneten Beispielen. Die Abschnitte 4.4.2 und 5 sagen, was folgt. Dieser Artikel ist diese Randnummern, gelesen für ein Team, das jede Woche ausliefert.

Der Maßstab ist die Risikobewertung, nicht die Größe der Änderung

Randnummer 104 wiederholt Erwägungsgrund 39: Ein Produkt ist wesentlich geändert, „wenn eine Änderung das Niveau des Cybersicherheitsrisikos verändert und dieses veränderte oder zusätzliche Risiko vom Hersteller in seiner Risikobewertung und folglich in seiner Umsetzung der grundlegenden Anforderungen nicht berücksichtigt wurde“. Der Hersteller „sollte daher im Einzelfall bewerten, ob ein Software-Update neue oder erhöhte Cybersicherheitsrisiken einführt und ob diese Risiken in seiner Risikobewertung bereits behandelt wurden“.

Zwei Folgen ergeben sich, und die Leitlinien ziehen beide. Erstens ist eine Änderung der Zweckbestimmung des Produkts wahrscheinlich eine: Randnummer 105 sagt, dass dort, wo neue Funktionen „zu einer Änderung der Zweckbestimmung des Produkts als Ganzes führen, der Hersteller solche Änderungen in seiner Risikobewertung wahrscheinlich nicht berücksichtigt hat“, und Beispiel 40 ist ein Überwachungs-Dashboard, das die Fähigkeit erhält, die Maschinen zu steuern, die es beobachtet. Zweitens ist die Größe nicht der Maßstab. Randnummer 107: „Die Bewertung einer wesentlichen Änderung sollte daher nicht auf dem Umfang oder der Komplexität der Änderung beruhen, sondern auf ihren möglichen nachteiligen Auswirkungen auf das Cybersicherheitsrisikoprofil.“ Beispiel 44 ist das, das jedes Produktteam lesen sollte: Eine „Angemeldet bleiben“-Funktion, die Authentifizierungstoken lokal speichert, „führt neue Risiken in Bezug auf Token-Diebstahl, unbefugten Zugriff und Session-Hijacking ein, die in der Risikobewertung nicht berücksichtigt wurden“, und die Anwendung „wurde wesentlich geändert“. Beispiel 45 ist eine Diagnosefunktion, die detaillierte Protokolle exportiert, dem Anschein nach geringfügig, die sensible Betriebsdaten unverschlüsselt speichert: wesentlich geändert.

Die andere Seite ist Randnummer 106. Wo der Hersteller „die Entwicklung dieser Funktionen vorhergesehen, die damit verbundenen Risiken bereits beschrieben und bewertet und geeignete Minderungsmaßnahmen umgesetzt hat“, „sollte das Update daher nicht“ als wesentliche Änderung betrachtet werden. Beispiel 42 ist eine Messaging-App, deren ursprüngliche Risikobewertung die spätere Einführung von Gruppenchats abdeckte, „einschließlich beispielsweise der erhöhten Komplexität des Nachrichten-Routings“; wenn der Gruppenchat mit den vorgesehenen Admin- und Moderationskontrollen ausgeliefert wird, wurde nichts wesentlich geändert. Beispiel 43 ist ein Überwachungssystem, das mit vorhandenen, aber deaktivierten und bewerteten Regelkreisen ausgeliefert wird; sie zu aktivieren ist keine wesentliche Änderung.

Das ist der ganze Mechanismus. Eine Risikobewertung, die die Roadmap benennt, absorbiert die Roadmap. Eine Risikobewertung, die einmal für das Produkt geschrieben wurde, wie es war, macht aus jeder nennenswerten Funktion eine wesentliche Änderung.

Sicherheitsupdates: in der Regel nicht, mit zwei Ausnahmen

Randnummer 108, wieder aus Erwägungsgrund 39: „Sicherheitsupdates sind in der Regel nicht als wesentliche Änderungen zu betrachten, da ihr Hauptzweck darin besteht, das Niveau des Cybersicherheitsrisikos zu senken.“ Das gilt, „selbst wenn dieses Update erhebliche technische Änderungen mit sich bringen kann“, und es umfasst Funktionen, die „ausschließlich zur Minderung erkannter Schwachstellen geändert oder eingeschränkt werden“. Beispiel 46 ist die Korrektur eines Eingabevalidierungsfehlers oder einer Sitzungstoken-Prüfung. Beispiel 47 ist Härtung: strengere Firewall-Regeln, das Abschalten von Ports, geänderte Standardpasswortrichtlinien, verpflichtende Multi-Faktor-Authentifizierung, wo sie bereits vorhanden war. Beispiel 48 ist der Tausch eines veralteten Algorithmus gegen einen stärkeren, den das Design bereits unterstützte.

Randnummer 109 nennt die Ausnahmen: ein Sicherheitsupdate, das die Zweckbestimmung über das Vorhergesehene hinaus ändert oder „die Grenzen oder die Abhängigkeitsstruktur des Produkts in einer in der Risikobewertung nicht vorhergesehenen Weise wesentlich verändert, z. B. durch wesentliche Änderung der Datenflüsse oder das Hinzufügen neuer von außen erreichbarer Schnittstellen“. Beispiel 49 ersetzt lokale Dateiverschlüsselung durch einen vom Hersteller betriebenen Fernverschlüsselungsdienst: Das Produkt tut jetzt etwas anderes, also ist es trotz des Sicherheitsmotivs wesentlich geändert. Beispiel 50 ersetzt einen intern verwalteten Schlüssellebenszyklus durch einen Schlüsselverwaltungsdienst eines Dritten und fügt „neue externe Schnittstellen und eine in der Risikobewertung nicht berücksichtigte Abhängigkeit von Diensten Dritter“ hinzu: wesentlich geändert.

Die vier Fragen an jedes Release

Randnummer 110 zählt auf, was ein Hersteller „berücksichtigen kann“, und es ist kurz genug für eine Pull-Request-Vorlage. Führt das Update:

a. neue Bedrohungsvektoren ein, etwa zusätzliche Schnittstellen, Kommunikationskanäle, Ausführungsumgebungen oder externe Abhängigkeiten, über die sich Bedrohungen verwirklichen könnten; b. ermöglicht es neue Angriffsszenarien, einschließlich beispielsweise neuer Wege, auf denen unbefugter Zugriff, Manipulation, Störung oder Missbrauch des Produkts mit digitalen Elementen oder der von ihm verarbeiteten Daten plausibel eintreten könnten; c. verändert es die Wahrscheinlichkeit zuvor ermittelter Angriffsszenarien, etwa indem es den für ihre Ausnutzung nötigen Aufwand oder das nötige Fachwissen senkt, die Exposition gegenüber nicht vertrauenswürdigen Akteuren erhöht oder bestehende Schutzmaßnahmen schwächt; d. verändert es die möglichen Auswirkungen zuvor ermittelter Angriffsszenarien, einschließlich beispielsweise des Umfangs betroffener Daten oder Funktionen, der Schwere betrieblicher, sicherheitsbezogener oder wirtschaftlicher Folgen oder der Fähigkeit, einen Vorfall zu erkennen, einzudämmen oder sich davon zu erholen.

Randnummer 111: viermal nein, „sofern die Annahmen und Minderungsmaßnahmen, auf die sich die Risikobewertung stützt, gültig und wirksam bleiben“, bedeutet, „es ist daher wahrscheinlich, dass das Update nicht“ als wesentliche Änderung gilt. Randnummer 112: Jedes Ja bedeutet, „der Hersteller sollte die Cybersicherheitsrisiken neu bewerten“ und „feststellen, ob die grundlegenden Anforderungen weiterhin erfüllt sind“. Randnummer 113 ergänzt die Pflicht, die nicht von der Antwort abhängt: „Unabhängig davon, ob Software-Updates als wesentliche Änderungen gelten oder nicht, müssen die Hersteller die Risikobewertung und die technische Dokumentation gemäß den Artikeln 13(7) und 31(2) korrekt, vollständig und fortlaufend auf dem neuesten Stand halten.“

Was die erste wesentliche Änderung auslöst

Abschnitt 4.4.2 betrifft den ursprünglichen Hersteller, was der übliche Softwarefall ist. Randnummer 122: Der Hersteller „bleibt der Hersteller“, aber „das wesentlich geänderte Produkt mit digitalen Elementen ist als neu in Verkehr gebracht zu betrachten“. Randnummer 123 begrenzt die Arbeit: Nach Abschnitt 2.1 des Blue Guide „kann der Hersteller vorhandene Dokumentation und Tests für Aspekte des Produkts mit digitalen Elementen wiederverwenden, die von der wesentlichen Änderung nicht betroffen sind“, die Konformitätsbewertung „sollte sich auf die wesentlich geänderten Teile konzentrieren“, und eine notifizierte Stelle, wo eine beteiligt ist, „sollte ihre Bewertung auf die wesentlich geänderten Teile konzentrieren“.

Für Software, die vor dem 11. Dezember 2027 auf dem Markt war, ist Randnummer 124 der Satz, den man behalten sollte. Eine wesentliche Änderung durch den ursprünglichen Hersteller „verpflichtet den Hersteller nicht an sich, das gesamte vor diesem Datum in Verkehr gebrachte Produkt mit digitalen Elementen in volle Übereinstimmung mit dem CRA zu bringen, es sei denn, die Änderung beeinträchtigt die Cybersicherheit des Produkts mit digitalen Elementen als Ganzes. Beeinträchtigt die Änderung die Cybersicherheit des Produkts mit digitalen Elementen als Ganzes nicht, sollten sich die Pflichten des ursprünglichen Herstellers in Bezug auf die Änderung auf die wesentlich geänderten Teile beschränken.“ Die erste „Angemeldet bleiben“-Funktion nach Dezember 2027 stellt also den Anmeldepfad unter Anhang I, nicht das ganze Altprodukt; eine Neuentwicklung, die die Grenzen des Produkts verändert, stellt es ganz darunter.

Abschnitt 5 ergänzt den Unterstützungszeitraum. Randnummer 128: „Jede wesentlich geänderte Version eines Softwareprodukts mit digitalen Elementen, die in Verkehr gebracht wird, muss einen erklärten Unterstützungszeitraum haben, der Artikel 13(8) entspricht“, mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht nachweislich kürzer ist, und wo die Änderung die Faktoren hinter der ursprünglichen erwarteten Nutzungsdauer nicht verändert, „bleibt der ursprüngliche Unterstützungszeitraum unberührt“. Randnummer 131, für Produkte, die in kurzen Abständen ausgeliefert werden: Der Hersteller muss für jede wesentlich geänderte Version einen Unterstützungszeitraum erklären und kann sich auf Artikel 13(10) stützen, um die Behebung von Schwachstellen in früheren Versionen einzustellen, „sobald die Nutzer kostenlos und ohne zusätzliche Kosten auf eine spätere Version umsteigen können“, was Randnummer 130 so liest, dass „verpflichtende Käufe neuer Hardware, der Austausch von Infrastruktur oder grundlegende Änderungen der Betriebsumgebung“ ausgeschlossen sind, normaler Upgrade-Aufwand aber nicht. Der Artikel zum Unterstützungszeitraum behandelt den Rest von Artikel 13(8).

Was das für ein Team bedeutet, das wöchentlich ausliefert

Drei Praktiken ergeben sich aus den Randnummern, keine davon neue Technik.

Schreiben Sie die Roadmap in die Risikobewertung. Randnummer 106 und die Beispiele 42 und 43 belohnen eine Risikobewertung, die die Funktionen benennt, die Sie ausliefern wollen, und sie bewertet, bevor sie existieren. Das ist billiger als eine neue Konformitätsbewertung je Funktion, und es ist der Unterschied zwischen Beispiel 42 und Beispiel 44. Die Risikobewertung nach Artikel 13 ist der Ort dafür.

Beantworten Sie Randnummer 110 in jedem Release. Vier Fragen, vier Antworten, je ein Satz, im Release-Protokoll. Wo alle vier nein sind, sagt das Protokoll, warum die bestehende Bewertung weiterhin trägt. Wo eine ja ist, wartet das Release auf die Neubewertung, die Randnummer 112 verlangt, und Risikobewertung und technische Dokumentation werden nach Randnummer 113 aktualisiert, was ohnehin geschuldet ist.

Entscheiden Sie die Altproduktfrage einmal. Halten Sie für jedes Produkt, das vor dem 11. Dezember 2027 auf dem Markt ist, den Versionsstand zu diesem Datum fest, damit die erste wesentliche Änderung danach erkennbar ist, und halten Sie bei jedem späteren Release fest, ob es eine war und, nach Randnummer 124, ob es die Sicherheit des Produkts als Ganzes oder nur einen Teil berührt hat.

StandardOS führt die technische CRA-Dokumentation und die Risikobewertung als lebende Aufzeichnungen statt als Dokumente, sodass ein Release an die vier Antworten und die Bewertung gebunden werden kann, auf die es sich stützt. Ob das Produkt überhaupt im Anwendungsbereich liegt, kommt zuerst.

Quellen

  • Verordnung (EU) 2024/2847, Artikel 3(30), Artikel 13(7), (8) und (10), Artikel 31(2), Artikel 21 und 22, Artikel 69(2), Erwägungsgründe 39 bis 42 und 60.
  • Europäische Kommission, Leitlinien der Kommission zur Anwendung der Verordnung (EU) 2024/2847, C(2026) 5252 final vom 27. Juli 2026, Anhang, Abschnitt 4.3 (Randnummern 103 bis 113, Beispiele 40 bis 50), Abschnitt 4.4 (Randnummern 114 bis 124), Abschnitt 5 (Randnummern 125 bis 131).
  • Europäische Kommission, der Blue Guide zur Umsetzung der EU-Produktvorschriften, Abschnitt 2.1, wie die Leitlinien ihn zitieren.

Dies ist keine Rechtsberatung. Die elf Beispiele sind zwei Seiten lang und näher an der Wirklichkeit eines Produktteams als alles andere in den Leitlinien; lesen Sie sie mit Ihren letzten zehn Releases daneben.