Firmware-Fehler überholen das Änderungsmanagement bei Ausfällen

Konfiguration und Änderungsmanagement bleiben die größte Einzelursache für schwere Netzwerkausfälle, mit 41 Prozent der Vorfälle in der Uptime Institute Annual Outage Analysis 2026. Dieser Anteil ist binnen eines Jahres um neun Prozentpunkte gefallen. Bei IT-Systemen und Software hat sich die Rangfolge bereits gedreht: Firmware- und Softwarefehler kommen auf 53 Prozent und liegen damit vor Konfiguration und Änderungsmanagement mit 51 Prozent. Die Änderungsdisziplin wirkt. Der Fehler ist dorthin gewandert, wo Ihr Änderungsprozess nicht hinreicht.

Das ist ein unbequemes Ergebnis für jeden, der seine Laufbahn damit verbracht hat, für bessere Änderungskontrolle zu argumentieren. Das Argument war richtig. Die Daten zeigen jetzt den Erfolg, und sie zeigen, was an dessen Stelle getreten ist. Für ein Firewall-Team lautet die praktische Frage nicht mehr, ob das Change Advisory Board diszipliniert genug ist. Sie lautet, ob die Änderungsdokumentation auch jene Änderungen erfasst, die niemand im Haus geschrieben hat.

Was die Ausfalldaten 2026 tatsächlich sagen

Die Uptime Institute Annual Outage Analysis 2026, erschienen im Mai, ist die achte Ausgabe der Reihe. Sie stützt sich auf den Global Data Center Survey 2025, den Data Center Resiliency Survey 2026, öffentlich gemeldete Vorfälle und eine anonymisierte, unter Vertraulichkeit geteilte Vorfalldatenbank. Netzwerkbezogene Probleme bleiben der größte Anteil an den IT-Service-Ausfällen im Resiliency Survey 2026.

Innerhalb dieser Netzwerkkategorie bewerteten Befragte, die in den vergangenen drei Jahren einen signifikanten, schweren oder gravierenden Netzwerkausfall erlebt hatten, die Ursachen wie folgt.

Ursache schwerer Netzwerkausfälle	Anteil (n=122)	Tendenz ggü. 2025
Fehler in Konfiguration oder Änderungsmanagement	41 %	Neun Punkte gefallen
Ausfall eines Drittanbieter-Netzbetreibers	34 %	Stabil
Hardwarefehler	34 %	Steigend
Firmware- oder Softwarefehler	29 %	Steigend
Leitungsbrüche	25 %	Acht Punkte gestiegen
Netzüberlast oder Congestion	14 %	Stabil
Böswilliger Cyberangriff	9 %	Stabil
Beschädigte Firewall-Regeln oder Routing-Tabellen	8 %	Stabil
Wetterbedingter Vorfall	5 %	Stabil

Zwei Zeilen dieser Tabelle verdienen mehr Aufmerksamkeit, als sie üblicherweise bekommen. Der Rückgang der Konfigurations- und Änderungsfehler um neun Punkte ist die größte Einzelbewegung in der Netzwerkkategorie, und Uptime führt die relative Verschiebung eher darauf zurück, dass andere Ursachen zunehmen, als darauf, dass Änderungsfehler verschwinden. Und beschädigte Firewall-Regeln oder Routing-Tabellen, also genau das Ergebnis, gegen das Firewall-Teams organisatorisch aufgestellt sind, machen 8 Prozent aus.

Die Überholung fand zuerst in der Softwareschicht statt

Das deutlichere Signal liegt eine Kategorie weiter. Für Ausfälle durch IT-Systeme und Software schreibt Uptime, dass diese in früheren Jahren überwiegend von Konfigurations- und Änderungsproblemen getrieben waren und dass der Survey 2026 nun Firmware- und Softwarefehler als größten Anteil ausweist.

Ursache schwerer IT-System- und Softwareausfälle	Anteil (n=74)
Firmware- oder Softwarefehler	53 %
Problem in Konfiguration oder Änderungsmanagement	51 %
Hardwarefehler	38 %
Kapazitäts- oder Congestion-Problem	19 %
Datensynchronisation oder Datenkorruption	15 %
Cyberangriff oder Sicherheitsvorfall	15 %

Uptime zieht die Grenze klar: Ein Konfigurationsproblem betrifft eine falsche Einstellung oder Änderung, während ein Software- oder Firmwarefehler aus einem Bug oder Defekt im System selbst stammt. Der Schluss des Berichts lautet, dass das Ausfallrisiko tiefer in den Technologie-Stack wandert, weg von bedienerverursachten Fehlern und hin zu Fehlern, die mit Softwareverhalten, Updates und dem Zusammenspiel von Komponenten zusammenhängen.

Zwei Prozentpunkte sind ein knapper Abstand bei einer Stichprobe von 74, und es wäre falsch, die Überholung als entschieden zu betrachten. Entscheidend ist die Richtung. Die eine Kurve fällt seit Jahren, weil Organisationen in Änderungskontrolle investiert haben. Die andere steigt, weil mehr Herstellercode im Pfad liegt als früher, und weil nichts davon durch Ihren Genehmigungsprozess läuft.

Ein Firmware-Update ist eine Änderung ohne Änderungsdatensatz

Jeder ausgereifte Firewall-Änderungsprozess hat dieselbe Form. Ein Antrag wird gestellt, auf Policy-Auswirkung geprüft, in ein Fenster eingeplant, umgesetzt, verifiziert und dokumentiert. Der Datensatz macht die Änderung im Nachhinein prüffähig, und er ist das, was ein NIS2- oder ISO-27001-Prüfer sehen will. Unser Leitfaden zum Firewall-Änderungsmanagement beschreibt diesen Lebenszyklus vollständig.

Ein Firmware-Release des Herstellers erreicht dieselbe Produktivumgebung und überspringt jeden dieser Schritte. Niemand im Haus hat den Code geschrieben. Niemand hat die Policy-Auswirkung geprüft, weil sich die Auswirkung nicht als Policy ausdrückt. Es kommt im Takt des Herstellers, oft gebündelt mit einem Sicherheitsfix, bei dem Sie praktisch kaum eine Wahl haben, und es kann Paketverarbeitung, Session-Tabellen-Verhalten, NAT-Reihenfolge oder Default-Deny-Semantik verändern, ohne dass sich eine einzige Zeile im Regelwerk ändert.

Genau auf diese Lücke zeigen die Daten von 2026. Das Regelwerk ist unter Kontrolle. Die Plattform darunter nicht, und sie ändert sich häufiger als das Regelwerk.

Warum die Zahlen zum menschlichen Fehler dem nicht widersprechen

Uptime behandelt menschliches Versagen als Beitragsfaktor und nicht als Grundursache. 92 Prozent der Befragten gaben an, dass menschliches Versagen mindestens geringfügig zu ihrem jüngsten schwerwiegenden Ausfall beigetragen hat. Unter den Ursachen menschlichen Versagens bleibt das Nichteinhalten etablierter Verfahren mit 59 Prozent führend, vor fehlerhaften Prozessen oder Verfahren mit 36 Prozent sowie Installations- und Betriebsfehlern mit jeweils 25 Prozent.

Zusammen mit dem Firmware-Befund gelesen, ist das kein Widerspruch, sondern der Mechanismus. Uptime benennt das Zuordnungsproblem selbst: Ein Ausfall nach einem fehlerhaft eingespielten System-Update kann aus einem Softwaredefekt, einer falschen Änderung oder aus fehlgeschlagenen Tests stammen, und die Entflechtung ist ehrlich schwierig. Ein Firmware-Fehler, den ein ordentlicher Staged Rollout in der Vorproduktion gefangen hätte, wird als Firmware-Fehler erfasst. Er ist zugleich ein übersprungenes Verfahren.

Die nützlichste Zahl des Berichts stammt aus dem Survey 2025: 87 Prozent der Befragten, die in den drei Jahren zuvor einen schwerwiegenden Ausfall hatten, sagten, er wäre mit besserem Management, besseren Prozessen oder besserer Konfiguration vermeidbar gewesen, sieben Punkte mehr als 2024. Knapp neun von zehn Ausfällen waren durch die betroffene Organisation selbst vermeidbar, unabhängig davon, wer den fehlerhaften Code geschrieben hat.

Was sich dadurch im Firewall-Änderungsprozess ändert

Die praktische Antwort besteht darin, Hersteller-Firmware als Änderung zu behandeln, die man nicht selbst verfasst hat, und nicht als Wartung. Aus den Daten folgen fünf Anpassungen.

• Firmware-Stände gehören in den Änderungsdatensatz. Wenn Ihre CMDB Regeländerungen erfasst, aber nicht den Plattformstand, auf dem diese Regeln liefen, lässt sich ein Ausfall nicht mit dem auslösenden Update korrelieren. Versionsstand gehört in denselben Datensatz wie Policy-Stand.
• Herstellercode genauso stufenweise ausrollen wie Regeländerungen. Ein Laborpaar, dann ein Standort geringer Kritikalität, dann die Fläche. Die 59 Prozent Verfahrensverstöße sind überwiegend genau diese Kontrolle, übersprungen unter Zeitdruck.
• Den Rollback testen, den Sie tatsächlich haben. Ein Firmware-Rollback auf einem Hochverfügbarkeitspaar ist nicht dieselbe Operation wie das Zurücknehmen eines Regel-Commits, und auf mehreren Plattformen ist es gar nicht mehr umkehrbar, sobald eine Schema-Migration der Konfiguration gelaufen ist. Unsere Notiz zum Notfall-Rollback bei Firewall-Änderungen behandelt die Fehlerbilder, der Beitrag zum Failover-Test bei Hochverfügbarkeit das Verhalten des Paares.
• Die Policy nach dem Upgrade vergleichen, nicht nur davor. Ein Firmware-Release kann die wirksame Policy verändern, ohne das Regelwerk zu verändern. Der Abgleich von Soll- und Ist-Zustand danach ist die einzige Möglichkeit, das zu sehen, und dieselbe Disziplin wie bei der Erkennung von Policy Drift.
• Dem Herstellerkalender einen Verantwortlichen geben. Jemand muss den Release-Kalender, die End-of-Support-Termine und die Known-Issue-Listen je Plattform halten. In einer Multi-Vendor-Umgebung ist das eine echte Aufgabe, und sie ist meist niemandes.

Der Zielkonflikt mit schnellerem Patchen

Nichts davon spricht für langsamere Updates. Die Regulierung geht in die andere Richtung, und die Verkürzung der Behebungsfristen, die wir im Drei-Tage-Patch-Fenster behandelt haben, wird sich nicht umkehren. Der Punkt ist, dass Geschwindigkeit und Staging gegeneinander abgewogen werden, ohne dass jemand die Abwägung aufschreibt.

Eine Organisation, die binnen drei Tagen patcht und nichts staged, hat sich für Firmware-Risiko und gegen Exploitation-Risiko entschieden. Das kann sehr wohl die richtige Wahl sein. Sie sollte eine Entscheidung mit einem Namen und einer kompensierenden Kontrolle sein, kein Nebenprodukt einer Frist. Dieselbe Logik gilt für die Regelhygiene: Ein Rezertifizierungszyklus, der jährlich läuft, während die Firmware quartalsweise wechselt, misst die stabile Hälfte des Systems.

Warum das wichtig ist

Die bequeme Lesart dieser Daten lautet, Änderungsmanagement sei gelöst und die Aufmerksamkeit gehöre woandershin. Die zutreffende Lesart ist enger. Änderungsmanagement wirkt auf die Änderungen, die es sieht, und der Anteil der Produktivänderungen, den es sieht, sinkt. Uptimes eigene Formulierung, das Risiko wandere tiefer in den Stack hin zu Fehlern in Softwareverhalten und Updates, beschreibt ein Abgrenzungsproblem und kein Disziplinproblem.

Jede hier beschriebene Kontrolle existiert in den meisten Firewall-Änderungsprozessen bereits. Sie wird auf Regeländerungen angewandt und nicht auf Plattformänderungen, aus dem historischen Grund, dass Plattformänderungen früher selten waren. Selten sind sie nicht mehr. Denselben Datensatz, dasselbe Staging und dieselbe Verifikation auf Herstellercode auszudehnen, ist eine Erweiterung des Geltungsbereichs und keine neue Methodik, und 87 Prozent der Organisationen in der Befragung glauben, ein besserer Prozess hätte den Ausfall verhindert, den sie tatsächlich hatten.

Sie wollen wissen, ob Ihre Änderungsdokumentation einem Prüfer standhält, der nach dem Firmware-Stand hinter einer Regel fragt? Der kostenlose NIS2-Check geht die Nachweise durch, die ein Firewall-Änderungsprozess liefern muss.