17. Juli 2026 · Fortinet · Perimeter · Schwachstellenmanagement · IT-Sicherheit

Wenn die Firewall sich selbst patcht: FortiOS-Upgrades

FortiOS aktualisiert sich automatisch, in bestimmten Fällen sogar erzwungen. Was die Upgrades auslöst, welche Ausnahmen gelten und wie Sie gegensteuern.

Eine Firewall startet nachts neu, am Morgen läuft eine andere Firmware-Version, und niemand im Team hat ein Update eingespielt. Bei FortiGate-Systemen ist das dokumentiertes Verhalten. Im Tech-Blog von boll ist am 17. Juli 2026 unter dem Titel „Your FortiGate Updated Itself – But You Don’t Know Why?“ eine Zusammenfassung erschienen, wie es dazu kommt. Wir haben die Aussagen an der Herstellerdokumentation geprüft.

Kurz gefasst: Es gibt zwei Mechanismen. Den einen können Sie abschalten, den anderen nicht.

Mechanismus 1: das automatische Patch-Upgrade

Seit FortiOS 7.2.1 lässt sich einstellen, dass eine FortiGate neue Patch-Releases selbstständig installiert. Vor 7.4.5 war die Funktion nur bei Einstiegsmodellen ab Werk aktiv. Mit FortiOS 7.4.5 hat Fortinet das geändert: Laut Herstellerdokumentation sind automatische Firmware-Upgrades ab dieser Version „auf allen FortiGate-Modellen, einschließlich FortiGate-VMs“ standardmäßig eingeschaltet. Wer nach dem Update auf 7.4.5 zum ersten Mal die Weboberfläche öffnet, muss das mit „I acknowledge“ bestätigen – ein Klick, der im Alltag leicht untergeht.

Wichtig für die Einordnung: Die Funktion aktualisiert nur innerhalb des laufenden Versionszweigs. Aus 7.4.x wird ein neueres 7.4.x, nie ein 7.6.x. Es geht also um Patches, nicht um Versionssprünge.

Steuern lässt sich das Verhalten in der Oberfläche unter „System > Firmware & Registration“ oder per CLI unter config system fortiguard. Dort legen Sie fest, ob die Funktion aktiv ist, an welchen Wochentagen installiert werden darf oder wie viele Tage nach Erscheinen eines Patches gewartet wird (Standard laut Dokumentation: drei Tage), und in welchem Stundenfenster das geschieht. Standard ist 2 bis 4 Uhr Ortszeit; der genaue Zeitpunkt wird innerhalb des Fensters zufällig gewählt. Nach der Installation geht eine E-Mail an das FortiCloud-Konto, bei dem das Gerät registriert ist – nicht zwingend an die Person, die heute für die Firewall zuständig ist.

Mechanismus 2: das erzwungene Upgrade

Der zweite Mechanismus ist der eigentliche Grund für den Beitrag von boll. Fortinet nennt ihn „Required firmware upgrade“, boll spricht von „Forced Upgrade“. Er greift, wenn eine von zwei Bedingungen erfüllt ist:

  • Die Firmware-Lizenz ist ungültig. Fortinet spricht von einer ungültigen „Firmware & General Updates (FMWR)“-Lizenz, boll allgemeiner vom fehlenden gültigen FortiCare-Vertrag.
  • Der Versionszweig hat sein End of Engineering Support (EOES) erreicht. Die Geräte laufen also auf einer Nebenversion, für die der Hersteller keine Entwicklung mehr leistet.

In diesen Fällen prüft die FortiGate täglich, ob ein neuerer Patch im eigenen Versionszweig vorliegt, und plant die Installation selbst ein. Auch hier bleibt es beim Patch innerhalb der Nebenversion; führt der Upgrade-Pfad über Zwischenstände, werden sie der Reihe nach durchlaufen.

Bei der Frage, ab wann das gilt, sind die Quellen nicht ganz deckungsgleich. boll und Fortinets „New Features“-Seite zu FortiOS 8.0 nennen 7.4.8 und 7.6.4; das Administrationshandbuch 8.0 nennt 7.4.9 und 7.6.4. FortiOS 8.0.0 ist in jedem Fall betroffen. Wer auf 7.4.8 bzw. 7.6.4 oder neuer steht, sollte vom Mechanismus ausgehen.

Der entscheidende Unterschied zum automatischen Upgrade: Ein erzwungenes Upgrade lässt sich nach der Einplanung nicht abbrechen. Die Oberfläche graut die Abbruch-Schaltfläche aus, die Konsole meldet sinngemäß, das Upgrade sei erzwungen und könne nicht storniert werden. Möglich ist nur ein Aufschub mit execute auto-upgrade delay-installation. boll beziffert ihn auf sieben Tage. Das Administrationshandbuch zu FortiOS 8.0 bestätigt den festen Aufschub um sieben Tage und ergänzt zwei Details: Der Befehl lässt sich beliebig oft wiederholen, aber nicht an dem Tag, an dem die Installation geplant ist.

Den aktuellen Zustand zeigt execute auto-upgrade status. Dort stehen unter anderem der Vertragsstatus, ob das laufende Image das Lebensende erreicht hat und – wenn es so weit ist – der Vermerk „Enabled (Forced)“ samt geplantem Zeitfenster.

Die Ausnahmen – und warum sie nicht alle schützen

boll nennt drei Konstellationen, in denen das erzwungene Upgrade nicht greift. Die Herstellerdokumentation bestätigt sie, beschreibt sie aber genauer – und die Details verändern die Aussage:

  • Verwaltung durch FortiManager. Eine FortiGate, die mit FortiManager verbunden ist, aktualisiert sich nicht selbst. Wird sie mit FortiManager verbunden, während ein erzwungenes Upgrade bereits geplant ist, wird dieses abgebrochen.
  • Mitglied einer Security Fabric. Auch hier findet kein automatisches Upgrade statt. Umgekehrt gilt: Ist ein erzwungenes Upgrade bereits geplant, kann das Gerät keiner Fabric beitreten.
  • Sekundäres Mitglied eines HA-Clusters. Das ist die Ausnahme, die am leichtesten missverstanden wird. Das sekundäre Gerät startet kein eigenes Upgrade – es erhält die neue Firmware aber über ein Cluster-Upgrade, das das primäre Gerät anstößt. Der Cluster als Ganzes wird also aktualisiert.

Eine vierte Ausnahme steht nur in der Herstellerdokumentation: Auf Sonder-Builds („special builds“) greift das erzwungene Upgrade nicht.

Sicherheitsgewinn gegen Change Control

Der Hersteller begründet den Mechanismus mit dem Schutz der Geräte, und das Argument trägt: Eine Firewall ohne Firmware-Vertrag oder auf einem Versionszweig ohne Weiterentwicklung ist ein Perimetersystem, das keine Korrekturen mehr bekommt.

Für den Betrieb ist es trotzdem ein Eingriff in die Änderungssteuerung. Ein Firmware-Wechsel bedeutet einen Neustart, bei einem Einzelgerät also einen Ausfall der Verbindungen. Er kann Verhalten ändern, auf das Regelwerke, VPN-Gegenstellen oder angebundene Systeme angewiesen sind. Und er geschieht zu einem Zeitpunkt, den nicht Ihr Change-Prozess festgelegt hat, sondern das Gerät selbst.

Die gute Nachricht: Beide Auslöser sind vorhersehbar. Ein Lizenzablauf und ein EOES-Datum stehen lange vorher fest.

Was Sie jetzt tun sollten

  • Den Ist-Zustand erheben. Prüfen Sie auf jedem Gerät mit execute auto-upgrade status, ob das automatische Upgrade aktiv ist und ob bereits ein erzwungenes geplant wurde.
  • Vertragslaufzeiten und EOES-Termine ins Inventar. Ablaufdatum der Firmware-Lizenz und Supportende des Versionszweigs gehören als Felder ins Asset-Register, mit Verantwortlichem und Vorlauf – nicht in das Gedächtnis einzelner Mitarbeitender.
  • Das Zeitfenster an Ihr Wartungsfenster koppeln. Legen Sie Wochentage und Stundenfenster so fest, dass ein automatisches Upgrade in ein angekündigtes Wartungsfenster fällt, und dokumentieren Sie die Einstellung.
  • Patches zuerst im Labor testen. Ein Testgerät oder eine virtuelle Instanz auf demselben Versionszweig zeigt vor dem Produktivgerät, ob ein Patch Regelwerk, VPN oder Authentisierung beeinflusst.
  • Die Benachrichtigung an die richtige Stelle lenken. Die Mails gehen an das registrierte FortiCloud-Konto. Prüfen Sie, ob dieses Postfach heute noch jemand liest.
  • Wissen, welche Ausnahme für Sie gilt. Wer per FortiManager verwaltet, ist vom erzwungenen Upgrade ausgenommen – und muss den Patchstand deshalb aktiv selbst führen. Wer einen HA-Cluster betreibt, ist nicht ausgenommen.
  • Den Aufschub als Werkzeug verstehen, nicht als Lösung. Sieben Tage verschaffen Zeit, um einen Test abzuschließen oder ein Fenster zu vereinbaren. Sie ersetzen weder Vertrag noch Migration auf einen unterstützten Versionszweig.

Wie sector7 unterstützt

Im Rahmen unserer Managed Services betreiben wir Firewalls und VPN mit Patch-, Konfigurations- und Change-Management und aktualisieren Systeme geplant und dokumentiert statt ad hoc; Wartungsfenster kündigen wir an und legen sie außerhalb der Geschäftszeiten. Mehr dazu unter Managed Services & Support und Cyber Security.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0