Cyber Resilience Act im Softwarevertrag: Schwachstellenmeldungen und Sicherheitsupdates verbindlich regeln

Am 11. September 2026 greifen die ersten Meldepflichten des Cyber Resilience Act. Wenn dein Softwarelieferant eine aktiv ausgenutzte Schwachstelle oder einen schweren Sicherheitsvorfall feststellt, muss er gesetzlich handeln. Für dein Unternehmen genügt das jedoch nicht: Du brauchst Informationen früher, verständlich und in einer Form, mit der IT, Informationssicherheit, Datenschutz und Fachbereiche eigene Maßnahmen einleiten können. Standardverträge regeln diesen Ablauf häufig gar nicht oder beschränken sich auf unverbindliche Hinweise in einem Kundenportal.

Der Cyber Resilience Act, kurz CRA, betrifft Produkte mit digitalen Elementen. Darunter fallen grundsätzlich auch Software und Softwarekomponenten, die auf dem europäischen Markt bereitgestellt werden. Ob eine konkrete Cloud-Leistung, Individualsoftware, Open-Source-Komponente oder eingebettete Software vollständig in den Anwendungsbereich fällt, ist im Einzelfall zu prüfen. Für die Vertragsgestaltung ist das aber kein Grund zum Abwarten: Die Anforderungen des CRA bilden einen sinnvollen Mindestmaßstab für die Beschaffung sicherheitsrelevanter Software.

Infografik zu Cyber Resilience Act im Softwarevertrag: Schwachstellenmeldungen und Sicherheitsupdates verbindlich regeln (KI-generiert).

Was sich ab September 2026 konkret ändert

Die ersten CRA-Pflichten betreffen insbesondere die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle. Hersteller müssen dafür abgestufte Meldungen abgeben. Vorgesehen sind eine frühe Warnung binnen 24 Stunden nach Kenntniserlangung, eine Meldung binnen 72 Stunden sowie ein Abschlussbericht. Die gesetzliche Meldung erfolgt gegenüber den zuständigen Stellen, nicht automatisch gegenüber jedem Kunden.

Genau hier muss dein Vertrag ansetzen. Ein Lieferant kann seine gesetzlichen Pflichten erfüllen, während dein Unternehmen zu spät oder zu unvollständig informiert wird. Das ist besonders problematisch, wenn du betroffene Systeme abschotten, Zugangsdaten zurücksetzen, Datenverarbeitungen bewerten oder Kunden informieren musst.

Verlange deshalb eine eigenständige vertragliche Kundeninformation. Sie darf nicht davon abhängen, dass der Vorfall bereits öffentlich bekannt ist oder ein Patch verfügbar steht. Der Lieferant muss auch dann informieren, wenn die technische Analyse noch läuft.

Den Geltungsbereich im Vertrag eindeutig festlegen

Eine wirksame Sicherheitsklausel beginnt mit einer klaren Beschreibung dessen, was der Lieferant schuldet. Erfasst sein sollten nicht nur die Hauptsoftware, sondern alle gelieferten oder betriebenen Bestandteile:

• Anwendungen, Clients, mobile Apps und Plug-ins
• Schnittstellen, SDKs, Bibliotheken und Agenten
• Firmware sowie vorinstallierte Software
• Container, Images und Konfigurationsvorlagen
• Drittkomponenten und Open-Source-Bestandteile
• Administrationswerkzeuge, Update-Dienste und Supportportale

Formuliere außerdem, welche Versionen, Mandanten, Betriebsmodelle und Umgebungen betroffen sind. Bei SaaS-Angeboten gehören auch die vom Anbieter betriebenen Plattformkomponenten in den Regelungsbereich, soweit sie die Sicherheit des Dienstes beeinflussen.

Bei komplexen Lieferketten reicht eine Zusage des direkten Vertragspartners nicht aus, nur selbst verursachte Fehler zu behandeln. Der Lieferant sollte für die Koordination mit Unterlieferanten einstehen und Schwachstellen in eingebundenen Komponenten aktiv nachverfolgen. Wie du Open-Source-Risiken strukturiert bewertest, erläutern wir auch in unserem Beitrag zu Open-Source-Lizenzen im Unternehmen.

Schwachstellenmeldungen mit Fristen und Inhalten versehen

Die Vertragsklausel sollte zwischen einer Schwachstelle, einem Sicherheitsvorfall und einer bloßen Produktinformation unterscheiden. Entscheidend ist nicht allein die interne Schweregradeinstufung des Lieferanten. Maßgeblich muss sein, ob deine Nutzung, deine Daten oder deine Sicherheitsarchitektur betroffen sein können.

Für die Erstinformation empfiehlt sich eine risikobasierte Fristenlogik. Bei aktiv ausgenutzten oder wahrscheinlich ausnutzbaren kritischen Schwachstellen darf der Anbieter nicht bis zur gesetzlichen 24-Stunden-Frist warten. Vereinbare eine unverzügliche Benachrichtigung nach bestätigter Kenntnis, etwa über einen ständig erreichbaren Sicherheitskontakt. Für andere erhebliche Schwachstellen kannst du klare Höchstfristen definieren.

Die Erstmeldung sollte mindestens enthalten:

• eine eindeutige Referenznummer und den Zeitpunkt der Kenntniserlangung
• betroffene Produkte, Versionen, Komponenten und Konfigurationen
• eine verständliche Risikobewertung einschließlich möglicher Auswirkungen
• bekannte Angriffsvoraussetzungen und Hinweise auf aktive Ausnutzung
• sofort mögliche Schutzmaßnahmen oder Workarounds
• den Status eines Patches sowie den erwarteten Bereitstellungstermin
• einen festen Ansprechpartner mit Eskalationsmöglichkeit
• den nächsten Termin für ein Status-Update

Verlange zusätzlich regelmäßige Fortschrittsmeldungen, solange keine endgültige Abhilfe verfügbar ist. Eine pauschale Formulierung wie „Information nach angemessenem Ermessen“ bietet im Ernstfall keine belastbare Grundlage.

Sicherheitsupdates als geschuldete Leistung definieren

Viele Verträge versprechen „Updates“ oder „Wartung“, ohne zwischen Funktionsverbesserungen und sicherheitsrelevanten Korrekturen zu unterscheiden. Das führt zu vermeidbaren Diskussionen über Zusatzvergütungen, Freigaben und Rollout-Zeitpunkte. Sicherheitsupdates müssen deshalb als eigenständige, im Preis enthaltene Leistung beschrieben werden.

Regle insbesondere, dass der Lieferant:

• Sicherheitslücken analysiert, bewertet und priorisiert
• geeignete Patches, Hotfixes oder sichere Workarounds bereitstellt
• die Integrität und Herkunft von Updates absichert
• verständliche Installations-, Rollback- und Kompatibilitätshinweise liefert
• kritische Updates nicht allein in reguläre Release-Zyklen verschiebt
• nach einem Update offenlegt, welche Schwachstelle behoben wurde und welche Restrisiken verbleiben

Nicht jede Schwachstelle lässt sich sofort durch einen Patch beseitigen. Dann braucht es verbindliche Kompensationsmaßnahmen, etwa Konfigurationsänderungen, Deaktivierung einzelner Funktionen, zusätzliche Protokollierung oder eine kontrollierte Zugriffsbeschränkung. Der Lieferant sollte deren Wirksamkeit nachvollziehbar begründen und bei der Umsetzung unterstützen.

Für die konkrete Abgrenzung von Pflege, Patch und Upgrade ist unser Beitrag Updates, Patches und Pflege vertraglich regeln eine gute Ergänzung.

Supportlaufzeit und Sicherheitslaufzeit trennen

Ein häufiger Vertragsfehler: Die wirtschaftliche Vertragslaufzeit wird geregelt, die Dauer der Sicherheitsunterstützung aber nicht. Der Lieferant kann dann den allgemeinen Support für eine Version beenden, obwohl sie bei dir noch produktiv eingesetzt wird.

Fordere deshalb eine ausdrückliche Mindest-Supportlaufzeit je Produktversion. Sie sollte mindestens festlegen:

Regelungspunkt	Was im Vertrag stehen sollte
Unterstützte Versionen	Welche Haupt-, Neben- und Long-Term-Support-Versionen Sicherheitsupdates erhalten
Sicherheitslaufzeit	Konkreter Zeitraum ab Bereitstellung oder allgemeiner Verfügbarkeit
Ende des Supports	Vorlaufzeit für die Ankündigung und verpflichtende Migrationsinformationen
Kritische Schwachstellen	Umgang mit kritischen Lücken nach dem regulären Supportende
Migration	Technische Unterstützung, Kompatibilitätsinformationen und Datenübernahme
Kosten	Welche Leistungen von der Vergütung umfasst sind und wann Zusatzkosten entstehen können

Eine lange Vertragsbindung ersetzt keine Sicherheitszusage. Umgekehrt muss der Lieferant nicht unbegrenzt jede veraltete Umgebung unterstützen. Wichtig ist eine realistische Planung: Wenn ein Produkt das Ende seines Sicherheitslebenszyklus erreicht, brauchst du ausreichend Zeit und verwertbare Unterstützung für Migration oder Ersatz.

Bei cloudbasierten Diensten gehören hierzu außerdem Regelungen zur Datenrückgabe und zu einem geordneten Anbieterwechsel. Mehr dazu findest du in unserem Beitrag zur Exit-Strategie und Datenrückgabe beim Cloud-Anbieter.

Zusammenarbeit im Meldefall praktisch organisieren

Eine Meldepflicht hilft nicht, wenn der Lieferant nur eine allgemeine E-Mail-Adresse nennt und dein Unternehmen intern keine Empfänger festgelegt hat. Lege im Vertrag einen Sicherheitskommunikationsprozess fest. Benenne auf beiden Seiten Rollen, Kontaktwege und Vertretungen für Notfälle außerhalb üblicher Geschäftszeiten.

Der Prozess sollte auch festhalten, wer welche Entscheidung trifft. Dazu gehören etwa die Freigabe eines Notfallpatches, das Abschalten einer Schnittstelle, die Kommunikation gegenüber gemeinsamen Kunden oder die Einbindung eines forensischen Dienstleisters. Bei SaaS kann der Anbieter bestimmte Maßnahmen allein durchführen müssen. Bei On-Premises-Software benötigt er häufig deine Mitwirkung für Installation, Log-Auswertung und Tests.

Sinnvoll ist ein gemeinsamer Vorfallbericht nach Abschluss der Behandlung. Er dokumentiert Ursache, betroffene Systeme, getroffene Maßnahmen, verbleibende Risiken und Präventionsmaßnahmen. Diese Auswertung ist keine bloße Formalie. Sie liefert wichtige Nachweise für Risikomanagement, Audits und die Weiterentwicklung deiner Sicherheitsvorgaben.

Supportzeiten und Reaktionspflichten sollten dabei zu den Störungsklassen passen. Wie diese sauber voneinander abgegrenzt werden, erklären wir in Support-Level und Störungsklassen abgrenzen.

Haftung, Servicegutschriften und Nachweise nicht vergessen

Sicherheitszusagen bleiben schwach, wenn Verstöße keine Folgen haben. Prüfe daher, ob die Haftungsregelung Schäden aus Verletzungen von Sicherheits-, Melde- und Updatepflichten tatsächlich erfasst. Allgemeine Haftungsobergrenzen können bei schweren Pflichtverletzungen wirtschaftlich unangemessen sein, besonders wenn der Lieferant zugesagte Sicherheitsmaßnahmen unterlässt.

Servicegutschriften können bei wiederholten Fristverstößen einen Anreiz schaffen, ersetzen aber keinen Schadensersatz und keine Nachbesserung. Ergänze ein Recht zur außerordentlichen Kündigung für schwerwiegende oder wiederholte Verstöße, insbesondere bei ausbleibender Reaktion auf kritische Schwachstellen. Die passende Gestaltung von Verfügbarkeit, Reaktion und Folgen behandeln wir in Service Level Agreements richtig vereinbaren.

Verlange zudem geeignete Nachweise. Dazu können Sicherheitskonzepte, Patch- und End-of-Support-Richtlinien, dokumentierte Prozesse zur Schwachstellenbehandlung und Ergebnisse relevanter Prüfungen gehören. Ein uneingeschränktes Auditrecht ist nicht immer erforderlich. Ein abgestuftes Informations- und Prüfkonzept ist oft praktikabler.

Checkliste für deine Vertragsprüfung

• Ist eindeutig beschrieben, welche Software, Komponenten und Versionen erfasst sind?
• Gibt es eine direkte Kundeninformation unabhängig von gesetzlichen Behördenmeldungen?
• Sind Fristen, Meldeinhalte und Eskalationskontakte verbindlich vereinbart?
• Schuldet der Lieferant Patches oder wirksame Schutzmaßnahmen ohne gesonderte Vergütung?
• Ist die Sicherheitsunterstützung je Version zeitlich konkret festgelegt?
• Sind End-of-Support, Migration und Umgang mit kritischen Altversionen geregelt?
• Besteht ein umsetzbarer Ablauf für Analyse, Kommunikation und Maßnahmen im Vorfall?
• Deckt die Haftungs- und Kündigungsregelung Verletzungen von Sicherheitszusagen ab?
• Können Sicherheitsprozesse und die Einhaltung der Pflichten nachvollzogen werden?

Der CRA macht deutlich: Sicherheit ist keine unverbindliche Produkteigenschaft, sondern eine über den gesamten Lebenszyklus zu organisierende Leistung. Wenn du diese Punkte jetzt in neue Softwareverträge, Wartungsverträge und Verlängerungen aufnimmst, reduzierst du operative Risiken und vermeidest Zeitverlust im Ernstfall. Passende Seminare und Termine findest du bei uns auf cmt.de.