I. Inhalt CRA
Der Inhalt bedeutet für die Software, die jetzt aus dem Markt S8ommer 2026) ist, formal erstmal wenig. Ich habe diese Pflichten in einem anderen Blog dargelegt. Zusammenfassung
Inhalt des CRA:
• Meldepflichten nach Art. 14 CRA (Art. 69 Abs. 3 CRA): Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen ab dem 11. September 2026 für alle Produkte gemeldet werden — auch für Bestandssoftware. Hier gibt es keinen Bestandsschutz.
• Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen muss innerhalb von 24 Stunden eine initiale Meldung (Frühwarnung) erfolgen. Innerhalb von 72 Stunden sind weitere Informationen zu ergänzen. Ein Abschlussbericht ist bei Schwachstellen spätestens 14 Tage nach einem Sicherheitsupdate oder einem Workaround zu erstellen, bei Sicherheitsvorfällen einen Monat nach der initialen Meldung.
• Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle müssen der ENISA und dem nationalen CSIRT gemeldet werden — über die einheitliche Meldeplattform.
Für Produkte, die ab dem 11.12.2027 auf den Markt kommen, gelten zusätzliche Pflichten, Security-by-Design, CE-Kennzeichnung, SBOM-Pflicht, Lifecycle-Management.
Der CRA besagt, dass die Hersteller zur Bereitstellung von Security Patches verpflichtet sind, damit die durch Cyberkriminalität verursachten Risiken reduziert werden. Das gilt eben nicht für Client Server Systeme, die vor diesem Datum auf den Markt gekommen sind. Der Cyber Resilience Act (CRA) gewährt also für Software, die vor dem 11.12.2027 in Verkehr gebracht wurde, formal einen Bestandsschutz (Art. 69 Abs. 2 CRA).
Mit dem CRA wird aber durch die ENISA eine Datenbank in Betrieb genommen, die tagesaktuell eine Übersicht über Schwachstellen von Bibliotheken, Software etc. gibt.
II. Rechtslage vor dem 11.12.2027
Wichtiger aber ist und das gilt auch für die Software, die bereits jetzt auf dem Markt ist:
Sofern zwischen dem Kunden und dem Hersteller ein Softwarepflege oder Mietvertrag abgeschlossen wurde, reichen die Wirkungen des CRA weiter.
Sofern eine Schwachstelle in der European Vulnerability Database (EUVD), in MITREs CVE-Program oder in der CISA Known Exploited Vulnerabilities (KEV)-Liste seit Wochen mit hoher Kritikalität dokumentiert ist, kann sich ein Hersteller nicht darauf berufen, dass für sein Produkt formal der CRA-Bestandsschutz greift. Die zivilrechtliche Patch-Lieferungspflicht entsteht aus der allgemeinen Sorgfaltsanforderung — und der Hersteller, der nicht rechtzeitig ein Patch zur Verfügung stellt, haftet im Schadensfall aus der Schlechterfüllung des Miet- oder Softwarepflege/Wartungsvertrags.
Mit der EUVD wird ein offizieller „Stand der Technik“ eingeführt. Aus dem Abschluss von Miet, Softwarepflege/Wartungsverträgen folgt die Pflicht, die Software dem Stand der Technik entsprechend zu aktualisieren.
Das wird noch mal durch die Inhalte der Cyberversicherungen unterstrichen.
Der Kunde muss nachweisen, dass er Sicherheitspatches unverzüglich installiert und bei bekannten Schwachstellen unverzüglich handelt. Praktisch jede marktübliche Cyberversicherung enthält heute technische Obliegenheiten nach § 28 VVG, die den Versicherungsnehmer verpflichten, Sicherheitsupdates unverzüglich einzuspielen, einen IT-Sicherheitsstandard nach Stand der Technik aufrechtzuerhalten und bei bekannt gewordenen Schwachstellen aktiv zu handeln. Wer das nicht tut, riskiert nach § 28 Abs. 2 VVG die Leistungskürzung — bei grober Fahrlässigkeit quotal, bei Vorsatz vollständig.
Aus Sicht eines Cyberversicherers ist die Argumentation klar: Wenn EUVD und CVE eine ausnutzbare Schwachstelle dokumentieren, gilt der Patch als Stand der Technik. Wer ihn nicht einspielt, verletzt seine Obliegenheit. Auf den CRA-Bestandsschutz wird der Versicherer sich nicht einlassen, weil dieser nur die verwaltungsrechtliche Hersteller-Konformitäts-Pflicht regelt, nicht aber die Frage, ob der Versicherungsnehmer beim Betrieb seiner Infrastruktur den Stand der Technik einhält.
III. Was folgt daraus für die Lieferanten-Kunden-Beziehung?
Das ist für Sie eine Chance.
Der Kunde wird aus seinem Cyberversicherungsvertrag (ggf, aus seinen NIS2-Pflichten gezwungen), gepatchte Software zu betreiben. Sein eigener Versicherungsschutz hängt davon ab. Also fordert er vom Lieferanten Patches — auch für Bestandssoftware, auch für Konfigurationen vor dem 11.12.2027. Der formale CRA-Bestandsschutz ist ihm gleichgültig; er wird als formal-juristische Argumentation abgewiesen, weil sie ihm beim Versicherer nicht hilft.
Der Lieferant steht damit vor einer einfachen Wahl:
• Entweder er liefert Patches — auch für Bestandsprodukte — und macht das vertraglich und kostentechnisch transparent.
• Oder er liefert nicht, riskiert eigene Haftung über § 276 BGB / § 823 BGB, verliert Kunden in Ausschreibungen und steht in Lieferketten-Audits seiner NIS2-pflichtigen Kunden als Risikolieferant da.
Der Lieferant wird damit verpflichtet, Leistungen wie laufende Schwachstellen-Beobachtung, das Backporting in alte Releases, das Testen und das Rollout-Management etc. zu erbringen.
Der Kunde muss ebenfalls agieren:
Er muss schnell genug patchen und er muss seine Systemumgebung aktualisieren, weil die Sicherheitspatches für die passende Umgebung entwickelt werden.
Und das muss und kann entsprechend vergütet werden. Der CRA bietet nach meiner Ansicht also auch die Gelegenheit, dem Kunden eine Änderung der Bestandsverträge anzubieten. Der CRA will Pflichten zur Etablierung von mehr Sicherheit etablieren. Sicherheit kostet Geld und bietet deshalb den IT Unternehmen argumentative Chancen, die Kunden mit Patches zu beliefern aber eben auch das Releasemanagement zu verbessern.
IT-Unternehmen sind gut beraten, ihre Wartungs- und Patch-Verpflichtungen frühzeitig vertraglich neu zu strukturieren: nach Schweregrad gestaffelt, vergütet und mit klaren Mitwirkungspflichten des Kunden flankiert. Wer das nicht tut, wird vom Markt entweder zur kostenlosen Leistung gezwungen oder verliert das Geschäft.
