Cyber Resilience Act: Warum Patch-Verfügbarkeit ohne Asset-Wissen zur Haftungsfalle wird

Der kommende Cyber Resilience Act (CRA) der Europäischen Union wird den IT-Markt radikal umkrempeln. Die Grundidee des Gesetzes ist aus Sicht der Cybersicherheit ein Segen: Hersteller von Hard- und Software mit digitalen Elementen werden künftig gezwungen, ihre Produkte von Grund auf sicher zu entwickeln (Security by Design) und, was noch wichtiger ist, Sicherheitslücken über einen definierten Zeitraum von mindestens fünf Jahren aktiv und kostenlos durch Updates (Patches) zu schließen.

Viele IT-Verantwortliche auf Betreiberseite (also die Anwender der Software) freuen sich auf diese neue Ära. Die Erwartung: Endlich müssen die Hersteller für sichere Software sorgen, unsere Netzwerke werden automatisch sicherer!

Diese Annahme ist ein gefährlicher Trugschluss. Der CRA löst das Problem von verwundbarer Software, aber er erschafft gleichzeitig eine massive, neue Haftungsfalle für das IT-Management der Betreiber. In diesem Beitrag erklären wir, warum die Verfügbarkeit von Patches völlig nutzlos ist, wenn Sie Ihre eigene Infrastruktur nicht kennen, und wie fehlendes Asset-Wissen im Jahr 2026 zu direkten rechtlichen Konsequenzen führt.

Der Shift in der Haftungskette

Um das neue Risiko zu verstehen, müssen wir uns ansehen, wie Sicherheitsvorfälle bisher oft gehandhabt wurden. Wenn Hacker eine bisher unbekannte Lücke (Zero-Day-Exploit) in einer Software nutzten, um in ein Unternehmen einzudringen, war der Schuldige für die IT-Abteilung (und oft auch für das Management) schnell gefunden: der Softwarehersteller. „Wir konnten uns ja nicht schützen, es gab noch keinen Patch!“ war die klassische, oft rechtlich haltbare Verteidigungslinie.

Mit dem Inkrafttreten des CRA ändert sich dieses Narrativ drastisch. Das Gesetz zwingt Hersteller dazu, Schwachstellen proaktiv zu suchen, sie an die Europäische Agentur für Cybersicherheit (ENISA) zu melden und innerhalb kürzester Zeit Updates bereitzustellen. Gleichzeitig erzeugen die Transparenzpflichten des CRA (Stichwort: SBOMs, Software Bill of Materials) eine Flut an öffentlich bekannten und katalogisierten Schwachstellen (CVEs).

Das neue Szenario sieht so aus: Der Hersteller identifiziert eine Schwachstelle, veröffentlicht den Patch und publiziert das Risiko. In exakt diesem Moment beginnt eine unsichtbare Stoppuhr zu ticken. Die Cyberkriminellen wissen nun ebenfalls von der Lücke und beginnen sofort (oft innerhalb von 24 Stunden), das Internet automatisiert nach ungepatchten Servern zu scannen.

Der Hersteller hat seine gesetzliche Pflicht (CRA) erfüllt. Die Haftung (und das Risiko) geht in diesem Moment vollständig auf Sie, den Betreiber, über.

Der Patch-Management-Albtraum ohne CMDB

Wenn Sie nun durch diese bekannte, patchbare Lücke gehackt werden und vor dem Vorstand, Ihren Kunden oder der Datenschutzbehörde (im Rahmen von NIS-2 oder DSGVO) Rechenschaft ablegen müssen, können Sie sich nicht mehr auf den Hersteller verlassen. Die bohrende Frage lautet dann: „Der Patch war seit vier Wochen verfügbar. Warum haben Sie ihn nicht installiert?“

In Unternehmen ohne automatisiertes, historisiertes Asset-Management lautet die bittere, aber ehrliche Antwort meist: „Wir wussten nicht, auf welchen unserer 1.200 Server diese betroffene Software installiert war.“

Dieser Mangel an Sichtbarkeit ist keine gültige rechtliche Verteidigung mehr – es ist der Beweis für grobe Fahrlässigkeit. Wenn Sie heute Updates (Patches) ausrollen wollen, stoßen Sie ohne eine verlässliche Datenbasis (CMDB) auf unüberwindbare Hürden:

1. Der blinde Fleck: Sie patchen die 90 Server, die in Ihrer manuellen Excel-Liste stehen. Die 10 Server der Schatten-IT, die in AWS laufen, vergessen Sie. Der Hacker findet exakt diese 10 Server.
2. Die Angst vor der Downtime: Sie wissen zwar, dass auf Server 04 die anfällige Software läuft, aber Sie wissen nicht, welche Geschäftsprozesse davon abhängen. Aus Angst, durch den Neustart des Servers die Produktion lahmzulegen, verschieben Sie das Patch-Fenster um drei Wochen. In Woche zwei schlägt der Hacker zu.

Automatisierung als juristischer und operativer Schutzschild

Um das Patch-Management im Zeitalter von CRA und NIS-2 beherrschbar (und rechtssicher) zu gestalten, müssen Sie die Lücke zwischen dem Vorhandensein eines Patches und seiner Installation schließen. Der Schlüssel dazu ist Kontext, geliefert von einer automatisierten Asset-Management-Plattform.

Mit Systemen wie Qbilon wird das Patch-Management von einer blinden Suchaktion zu einer präzisen, chirurgischen Maßnahme:

• Echtzeit-Korrelation: Sobald der Hersteller (oder die NVD-Datenbank) eine Schwachstelle meldet, gleicht Qbilon diese Information mit Ihrem stets aktuellen Asset-Inventar ab. Sie sehen auf dem Dashboard sofort: „Die verwundbare Bibliothek läuft exakt auf den Instanzen AWS-WEB-01 bis AWS-WEB-15.“
• Risikopriorisierung durch Abhängigkeiten: Die Plattform zeigt Ihnen, dass AWS-WEB-01 bis 05 an geschäftskritischen, extern erreichbaren Kundenportalen hängen. Diese müssen sofort (innerhalb von Stunden) gepatcht werden. AWS-WEB-15 ist ein interner Testserver ohne Internetzugang; hier reicht das reguläre Wartungsfenster am Wochenende.
• Historische Evidenz: Nachdem gepatcht wurde, zeichnet die Historisierungsfunktion (Time Machine) auf, dass das Update am 14. August um 11:30 Uhr erfolgreich auf allen 15 Systemen installiert wurde. Ein wasserdichter Beweis für jedes Audit.

Fazit: Nehmen Sie die Verantwortung an

Der Cyber Resilience Act nimmt Hersteller in die Pflicht, liefert Ihnen aber nicht automatisch ein sicheres Netzwerk. Er liefert Ihnen lediglich die dringend benötigten Bauklötze (Patches und SBOMs).

Es liegt an Ihnen, diese Bauklötze schnell und zielgenau in Ihre Infrastruktur einzupassen. Wer im Jahr 2026 noch versucht, Patch-Management auf Basis von Zuruf, manuellen Excel-Listen und fehlendem Architektur-Wissen zu betreiben, spielt russisches Roulette mit der Haftbarkeit des Unternehmens. Ein automatisiertes, kontextreiches Asset-Management ist die einzige Möglichkeit, das Tempo der Cyberkriminellen mitzugehen und Ihr Unternehmen vor Schaden – operativ wie juristisch – zu bewahren.