CRA bei Produktänderungen: Wann neu bewerten?

Artikel 23 CRA: Die Regel, die im Tagesgeschäft am meisten reibt

Artikel 23 des Cyber Resilience Act legt fest: Wer nach dem Inverkehrbringen eines Produkts eine „wesentliche Änderung” vornimmt, die sich auf die Konformität mit den CRA-Anforderungen auswirkt, muss eine neue Konformitätsbewertung durchführen.¹

Das klingt nach einer Randvorschrift für Hardware-Hersteller, die selten neue Versionen veröffentlichen. Für SaaS-Teams, die wöchentlich deployen, ist Artikel 23 eines der operativ schwierigsten Konzepte im gesamten CRA — weil die Verordnung nicht exakt definiert, wann eine Änderung „wesentlich” ist. Und weil in der Praxis aus vielen kleinen Änderungen über Zeit eine grundlegend andere Produktfunktionalität entsteht.

Was eine wesentliche Änderung ist — und was nicht

Die Verordnung liefert keine abschließende Liste. Erwägungsgrund 46 und Artikel 23 zusammen ergeben eine Auslegungsrichtung, die sich auf eine Kernfrage reduzieren lässt: Ändert die Modifikation die Sicherheitseigenschaften des Produkts, die Angriffsfläche oder das Risikoprofil so, dass die ursprüngliche Konformitätsbewertung ungültig wird?¹

Wesentlich — neue Konformitätsbewertung erforderlich:

Neue Netzwerkfunktion: Ein bisher lokal betriebenes Produkt erhält Cloud-Konnektivität. Die Angriffsfläche ändert sich fundamental — ein klassischer Fall bei embedded-Software für Heizungssteuerungen, die nachträglich ein OTA-Update-Modul bekommt.
Neue Authentifizierungsmethode: Ein Hersteller führt Single Sign-On mit einem externen Provider ein, wo vorher nur lokale Accounts existierten. Neue Abhängigkeit, neue Angriffsvektoren.
Erweiterung des Anwendungsbereichs: Ein B2B-Tool, das bisher nur für IT-Administratoren gedacht war, öffnet sich für Endverbraucher. Aus CRA-Perspektive ändert sich damit die Risikoklasse potenziell — Consumer-Produkte bewertet die Verordnung strenger.
Neue Zielgruppe: Auch wenn die Technik gleich bleibt — ein Hersteller setzt ein industrielles MQTT-Gateway, das ursprünglich nur für Automatisierungstechniker zugelassen war, im Bereich kritischer Infrastruktur ein. Das kann eine neue Bewertung erfordern.
Integration sicherheitsrelevanter Komponenten: Ein Hersteller nimmt eine neue Drittbibliothek in den Trust Perimeter des Produkts auf und überträgt damit kryptographische oder Authentifizierungsfunktionen.

Nicht wesentlich — keine neue Konformitätsbewertung:

Bugfixes und Security Patches: Das Schließen einer bekannten Schwachstelle macht die Konformitätsbewertung nicht ungültig — es verbessert sie. Das ist nicht nur erlaubt, sondern vom CRA aktiv gefordert.²
Reine UI-Updates: Eine neue Navigationsstruktur, geänderte Farbgebung, überarbeitete Onboarding-Flows ohne funktionale Änderung der Sicherheitsarchitektur.
Performance-Optimierungen: Optimierungen, die ausschließlich Ausführungsgeschwindigkeit oder Ressourcenverbrauch betreffen, ohne die Sicherheitslogik zu berühren.
Content-Änderungen: Aktualisierte Hilfetexte, neue Sprachen, überarbeitete Dokumentation.
Konfigurationsänderungen im Rahmen bestehender Architektur: Neue optionale Einstellungen, die keine neue Funktionalität in der Sicherheitsarchitektur einführen.

Das praktische Problem für SaaS-Hersteller

Traditionelle Hardware-Hersteller haben einen klaren Produktzyklus: Version 1.0 erscheint, der Hersteller lässt sie bewerten, das Zertifikat wird ausgestellt. Nächste Version in 18 Monaten.

SaaS-Teams leben anders. Wöchentliche Deployments, Feature-Flags, A/B-Tests, kontinuierliche Integration — das Produkt, das heute läuft, kann in sechs Monaten funktional kaum wiedererkennbar sein, auch wenn jeder einzelne Schritt für sich genommen trivial erscheint.

Was hier viele falsch verstehen: Das Konzept „wesentliche Änderung” ist eine der unklarsten Stellen im CRA — und genau dort, wo Hersteller die meisten Probleme mit Marktaufsichtsbehörden bekommen werden. Nicht weil ein einzelner Release die Grenze überschreitet, sondern weil über ein Jahr hinweg viele kleine Änderungen kumulativ ein anderes Produkt ergeben, ohne dass je ein formaler Bewertungsprozess ausgelöst wurde.

Die Drift-Falle

Stellen Sie sich vor: Ein IoT-Startup bringt im Januar 2026 ein SaaS-Tool für B2B-Ticketing auf den Markt — bewertet, konform, zertifiziert. Im Verlauf des Jahres nehmen die Entwickler folgende Änderungen vor:

März: Neues API-Modul für Drittanbieter-Integrationen (intern als “kleines Feature” eingestuft)
Mai: OAuth 2.0 SSO als Option hinzugefügt
Juli: Mobile App mit Push-Notifications eingeführt
September: Customer-Data-API für externe BI-Tools geöffnet

Keine einzelne dieser Änderungen hätte wahrscheinlich allein eine neue Konformitätsbewertung ausgelöst. Zusammen haben sie die Authentifizierungsarchitektur, die Datenzugriffslogik und die Netzwerktopologie des Produkts grundlegend verändert. Prüft die Marktaufsichtsbehörde das Produkt jetzt, bildet die ursprüngliche Konformitätsbewertung das tatsächliche Produkt nicht mehr ab.

Ein zweites Szenario aus dem Maschinenbau: Ein Industrie-4.0-Anbieter liefert embedded-Software für Produktionssteuerungen. Ursprünglich rein lokal betrieben. Im Lauf von 18 Monaten bekommt das System ein Remote-Monitoring-Modul, dann eine REST-API für das Leitsystem, dann eine Anbindung an einen Cloud-Datensammler. Kein Schritt war intern als „wesentlich” eingestuft. Die Angriffsfläche hat sich trotzdem verdreifacht.

In der Praxis erleben wir: Genau diese kumulativen Verschiebungen sind schwieriger zu erkennen und zu dokumentieren als einzelne große Änderungen — und sie entstehen meistens nicht aus Nachlässigkeit, sondern weil kein strukturierter Prozess existiert, der sie sichtbar macht.

Empfehlung: Das Änderungs-Log als Compliance-Instrument

Der einfachste und wirkungsvollste Mechanismus gegen die Drift-Falle ist ein strukturiertes Änderungs-Log mit Compliance-Prüfung.

Wie es aussieht:

Für jeden größeren Release — intern kann das bedeuten: jedes Sprint-Ende oder jede Version mit Minor-Version-Bump — dokumentiert ein Verantwortlicher (Product Owner, Tech Lead, oder Compliance-Beauftragter):

Was wurde geändert: Kurze technische Beschreibung der Änderung
Berührt die Änderung die Sicherheitsarchitektur? (Ja/Nein/Unklar)
Wenn ja: Wie verändert sich die Angriffsfläche, die Authentifizierungslogik oder die Datenzugriffsstruktur?
Kumulative Bewertung: Deckt die ursprüngliche Konformitätsbewertung noch die Summe aller Änderungen seit ihrer Erstellung ab?

Das Dokument muss nicht lang sein — eine strukturierte Tabelle reicht. Aber es muss existieren, gepflegt sein, und es muss eine klare Eskalationsregel geben: Beantwortet jemand Frage 4 mit „Nein” oder „Unklar”, löst das eine formale interne Überprüfung aus, bevor der nächste Release ausgeliefert wird.

Das klingt nach bürokratischem Aufwand. Ist es auch. Aber der Aufwand ist deutlich kleiner als eine ungeplante Neubewertung — oder eine Marktaufsichtsprüfung ohne passende Dokumentation.

Wann formal neu bewerten:

Neben der kumulativen Prüfung gibt es Trigger, die immer eine formale interne Neubewertung auslösen sollten:

Neue externe Netzwerkschnittstelle (REST-API, WebSocket, MQTT etc.)
Änderung der Authentifizierungsmethode oder des Autorisierungsmodells
Einführung einer neuen Datenkategorie im Produkt
Neue Abhängigkeit zu einer externen Bibliothek mit kryptographischen Funktionen
Produkt wird in einem neuen Markt oder für eine neue Zielgruppe eingesetzt

Bei wichtigen und kritischen Produkten (Important Class I–II und Critical) gilt: Sobald die interne Prüfung ergibt, dass eine Änderung wesentlich ist, muss ein Notified Body eine formale Neubewertung durchführen. Für Default-Produkte reicht Selbstbewertung — aber der Hersteller muss die Dokumentation dieser Selbstbewertung vorhalten.

Sonderfall: Free-Tier und kostenpflichtige Version

Eine Frage, die in der Praxis häufig entsteht: Wenn ein SaaS-Produkt in einer kostenlosen und einer kostenpflichtigen Version mit unterschiedlichem Funktionsumfang angeboten wird — ein Produkt oder zwei?

Die CRA-Antwort sucht man auf Produktebene: Entstehen beide Varianten aus demselben Code-Artefakt und unterscheidet nur eine Konfiguration (Feature-Flag, Lizenz-Token) zwischen ihnen, ist es ein Produkt mit einem Konformitätsrahmen. Hat die Enterprise-Variante eigene Module, eigene Netzwerkfunktionen oder eine eigene Architektur, kann sie als separates Produkt zu bewerten sein. Was viele CRA-Berater nicht sagen: Diese Abgrenzung sollte der Hersteller frühzeitig mit rechtlicher Begleitung klären — nicht erst wenn die Marktaufsicht fragt.

Die Anforderungen an die technische Dokumentation, die bei jeder Konformitätsbewertung vorliegen muss, sind in CRA technische Dokumentation beschrieben. Die Konformitätserklärung selbst — das Dokument, das nach abgeschlossener Bewertung ausgestellt wird — ist in EU-Konformitätserklärung CRA erklärt.

Quellen

EU-Verordnung 2024/2847 (Cyber Resilience Act), Artikel 23 (Wesentliche Änderungen), Erwägungsgrund 46: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
EU-Verordnung 2024/2847, Anhang I Nr. 2 lit. a–c (Pflichten zum Schwachstellenmanagement und Security Updates): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
ENISA — Guidance on Substantial Modifications under CRA: https://www.enisa.europa.eu/topics/cyber-resilience-act
BSI — CRA Umsetzungshilfen für Softwarehersteller: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/