July 17, 2026 · Fortinet · Perimeter · Schwachstellenmanagement · IT-Sicherheit

When the Firewall Patches Itself: FortiOS Upgrades

FortiOS updates itself automatically, in certain cases even by force. What triggers the upgrades, which exceptions apply and how you can take control.

A firewall reboots at night, in the morning it is running a different firmware version, and nobody on the team installed an update. On FortiGate systems, this is documented behaviour. On 17 July 2026, boll’s tech blog published a summary of how it comes about, under the title “Your FortiGate Updated Itself – But You Don’t Know Why?”. We checked its statements against the vendor documentation.

In short: there are two mechanisms. You can switch one of them off, the other you cannot.

Mechanism 1: the automatic patch upgrade

Since FortiOS 7.2.1, a FortiGate can be set to install new patch releases on its own. Before 7.4.5, the feature was active out of the box only on entry-level models. With FortiOS 7.4.5, Fortinet changed that: according to the vendor documentation, automatic firmware upgrades are switched on by default from this version “on all FortiGate models, including FortiGate VMs”. Anyone who opens the web interface for the first time after the update to 7.4.5 has to confirm this with “I acknowledge” – a click that is easily lost in day-to-day work.

Important for context: the feature only updates within the running version branch. 7.4.x becomes a newer 7.4.x, never a 7.6.x. So this is about patches, not version jumps.

The behaviour can be controlled in the interface under “System > Firmware & Registration” or via the CLI under config system fortiguard. There you specify whether the feature is active, on which weekdays installation is allowed or how many days to wait after a patch is released (default according to the documentation: three days), and in which hourly window this happens. The default is 2 to 4 a.m. local time; the exact time is chosen at random within the window. After installation, an email goes to the FortiCloud account the device is registered with – not necessarily to the person who is responsible for the firewall today.

Mechanism 2: the forced upgrade

The second mechanism is the actual reason for boll’s article. Fortinet calls it “Required firmware upgrade”, boll speaks of a “Forced Upgrade”. It applies when one of two conditions is met:

  • The firmware licence is invalid. Fortinet speaks of an invalid “Firmware & General Updates (FMWR)” licence, boll more generally of the lack of a valid FortiCare contract.
  • The version branch has reached its End of Engineering Support (EOES). The devices are therefore running on a minor version for which the vendor no longer does any development.

In these cases the FortiGate checks daily whether a newer patch is available in its own version branch, and schedules the installation itself. Here too, it stays with a patch within the minor version; if the upgrade path runs through intermediate releases, they are gone through in order.

On the question of from when this applies, the sources do not quite match. boll and Fortinet’s “New Features” page for FortiOS 8.0 name 7.4.8 and 7.6.4; the 8.0 administration guide names 7.4.9 and 7.6.4. FortiOS 8.0.0 is affected in any case. Anyone on 7.4.8 or 7.6.4 or later should assume the mechanism applies.

The decisive difference from the automatic upgrade: once scheduled, a forced upgrade cannot be cancelled. The interface greys out the cancel button, and the console reports, in essence, that the upgrade is forced and cannot be cancelled. All that is possible is a postponement with execute auto-upgrade delay-installation. boll puts it at seven days. The FortiOS 8.0 administration guide confirms the fixed postponement of seven days and adds two details: the command can be repeated as often as you like, but not on the day the installation is scheduled.

execute auto-upgrade status shows the current state. Among other things, it lists the contract status, whether the running image has reached its end of life and – when the time comes – the note “Enabled (Forced)” together with the scheduled time window.

The exceptions – and why they do not all protect

boll names three constellations in which the forced upgrade does not apply. The vendor documentation confirms them, but describes them more precisely – and the details change the statement:

  • Management by FortiManager. A FortiGate connected to FortiManager does not update itself. If it is connected to FortiManager while a forced upgrade is already scheduled, the upgrade is cancelled.
  • Member of a Security Fabric. Here, too, no automatic upgrade takes place. Conversely: if a forced upgrade is already scheduled, the device cannot join a fabric.
  • Secondary member of an HA cluster. This is the exception most easily misunderstood. The secondary device does not start an upgrade of its own – but it receives the new firmware through a cluster upgrade initiated by the primary device. The cluster as a whole is therefore updated.

A fourth exception appears only in the vendor documentation: the forced upgrade does not apply to special builds.

Security gain versus change control

The vendor justifies the mechanism with protecting the devices, and the argument holds: a firewall without a firmware contract, or on a version branch with no further development, is a perimeter system that no longer receives fixes.

For operations, it is nonetheless an intervention in change control. A firmware change means a reboot, and for a standalone device therefore an interruption of connections. It can change behaviour that rulesets, VPN peers or connected systems rely on. And it happens at a time that was set not by your change process, but by the device itself.

The good news: both triggers are predictable. A licence expiry and an EOES date are known well in advance.

What you should do now

  • Establish the current state. Check on every device with execute auto-upgrade status whether the automatic upgrade is active and whether a forced one has already been scheduled.
  • Put contract terms and EOES dates in the inventory. The expiry date of the firmware licence and the end of support of the version branch belong as fields in the asset register, with an owner and lead time – not in the memory of individual employees.
  • Tie the time window to your maintenance window. Set the weekdays and hourly window so that an automatic upgrade falls within an announced maintenance window, and document the setting.
  • Test patches in the lab first. A test device or a virtual instance on the same version branch shows, before the production device does, whether a patch affects the ruleset, VPN or authentication.
  • Direct the notification to the right place. The emails go to the registered FortiCloud account. Check whether anyone still reads that mailbox today.
  • Know which exception applies to you. Anyone managing via FortiManager is exempt from the forced upgrade – and must therefore actively keep track of the patch level themselves. Anyone running an HA cluster is not exempt.
  • Understand the postponement as a tool, not a solution. Seven days buy time to complete a test or agree a window. They replace neither a contract nor a migration to a supported version branch.

How sector7 supports you

As part of our managed services, we operate firewalls and VPN with patch, configuration and change management and update systems in a planned and documented way rather than ad hoc; we announce maintenance windows and place them outside business hours. More under Managed Services & Support and cyber security.

Sources

Let's talk about your situation.

Arrange a call+49 212 240915 0