The Twenty-Minute Window: A FortiGate Upgrade Nobody Notices
A firmware upgrade done right is boring. Here’s the runbook that keeps it that way.
TL;DR: A FortiGate firmware upgrade either happens as a routine twenty-minute maintenance window, or it becomes an unplanned outage with your name on the incident report, and the difference comes down to sequencing, not luck. This post works through the operator’s runbook: reading Fortinet’s required upgrade path correctly, the pre-flight checks worth doing before you touch anything, and how to move an HA pair through the process without downtime. Handled this way, firmware currency stops being a source of dread and just becomes routine maintenance.
There’s a specific kind of dread that comes with clicking “upgrade” on a device that everything else in your network depends on. It’s the same feeling as replacing a load-bearing wall: theoretically routine, and also the exact moment where “theoretically” stops being reassuring.
Here’s the thing that makes FortiGate firmware upgrades feel scarier than they need to be: you generally can’t just jump from your current version straight to the newest one. FortiOS upgrades often follow a specific, sometimes multi-hop path, where skipping a required intermediate version doesn’t just fail cleanly, it can leave a configuration in a state that’s genuinely painful to untangle. It’s less like updating an app on your phone and more like navigating a somewhat particular staircase where skipping a step doesn’t just trip you, it can leave the whole staircase in a slightly different shape than you left it.
We’re covering this because firmware currency isn’t optional busywork. It’s how a FortiGate keeps receiving security fixes, and running an old, unsupported version carries a risk that builds without much visible warning. A firewall running current firmware, current licenses, and a correctly matched firewall class for its traffic is doing its whole job; any one of those three lagging undermines the other two.
This post is the runbook for doing that well: not just clicking upgrade, but planning around it properly.
Reading the Upgrade Path Correctly
Fortinet publishes an upgrade path tool that tells you, given your current firmware version and target version, exactly which intermediate versions you need to pass through before you reach where you’re headed. Use it. It’s authoritative on the sequence, and there’s no reason to work that part out by hand or from memory of what worked last time, since the required path can change between hardware models and firmware branches. What the tool doesn’t give you is the plan around the sequence: the pre-flight checks, the timing, the rollback plan, and the verification steps, which is what the rest of this post covers.
The reason the path is often multi-hop rather than a single jump comes down to how Fortinet handles configuration changes between major versions. Each version step in the required sequence carries its own migration logic, code that specifically translates your existing configuration forward into the new version’s schema. Skip a required intermediate version, and you skip that version’s migration step entirely, which is how people end up with a device that boots successfully on the new firmware but with a configuration that’s subtly wrong: security policies that didn’t translate cleanly, features that reverted to defaults without warning, or in worse cases, configuration elements the device can’t fully parse and simply drops. None of this shows up as an error during the upgrade itself, which is exactly what makes it dangerous. The device comes back up, traffic starts flowing again, and the gap only surfaces later when something that should be blocked isn’t.
The practical rule that follows: treat the upgrade path tool’s output as non-negotiable, not as a suggestion you can shortcut if you’re confident in your configuration. That confidence, more often than any technical limitation, is exactly where this goes wrong. A team that’s upgraded the same model a dozen times can develop a kind of muscle memory that skips the tool entirely, right up until a firmware branch changes the required path, and that muscle memory becomes the thing that bites them.
Pre-Flight: What to Check Before You Touch Anything
Before touching anything, run through these checks. None of them take long individually, but skipping any one of them is how a routine window turns into an incident.
Configuration backup. A full configuration export, stored somewhere other than the device itself, taken immediately before you start. This is the “undo” button for the entire process, and it only works if it’s current: a backup from three weeks ago restores you to a network that no longer matches what you’re running today.
FortiCare validity. Firmware upgrades typically require an active support entitlement to complete, and this is precisely the dependency we flagged in our licensing post: a lapsed FortiCare subscription can block the upgrade you’re trying to perform, sometimes mid-process. Confirm license status before you schedule the window, not during it, when your options for fixing a licensing gap are considerably more limited.
HA state, if applicable. If you’re running a high-availability pair, confirm both units are currently synchronized and healthy before you start. Upgrading an HA pair with an existing sync issue doesn’t just fail to fix that issue, it compounds it, since the upgrade process itself depends on both units agreeing on a known-good starting state.
Disk and log space. Firmware images need room to land, and some upgrade paths require adequate free space to complete cleanly. An upgrade that stalls partway through because a disk filled up is one of the more avoidable ways to turn a routine window into an unplanned outage.
Release notes. It’s tempting to skim for the headline features and skip the rest. Don’t. The sections that really matter for planning a safe upgrade are usually the less exciting ones: known issues, upgrade-specific warnings, and any deprecated features that might affect your current configuration. A feature you rely on getting deprecated in the target version is exactly the kind of thing you want to know before the window, not during it, when your options for reacting are considerably narrower.
The Change Window: Sequencing an HA Upgrade Without an Outage
This is the stretch of the process where a well-run upgrade and a production incident pull furthest apart. In a properly configured HA pair, the standard approach is to upgrade the secondary unit first while the primary keeps handling traffic. Once the secondary comes up cleanly on the new firmware, you fail over to it so the already-upgraded unit carries the load, and then upgrade the former primary. Done in that order, traffic never fully stops; it simply shifts to whichever unit is already stable.
The failure modes are worth naming because each one is tempting under time pressure. Upgrading both units at once removes your fallback entirely. Failing over before confirming the upgraded unit is healthy hands production traffic to a device you haven’t validated. Either way, you end up with a moment where neither unit is fully reliable at the same time, and that moment is the outage. Patience at this step is the whole difference between a clean cutover and an outage.
The window around the sequence matters just as much. Schedule it for genuinely low-traffic hours rather than hours that merely seem fine, and treat that as a hard constraint. If the path involves several hops, verify stability at each stop instead of racing through the full chain in one sitting. Have a documented rollback plan before you begin, including exactly how you’d restore the pre-upgrade configuration backup if something goes wrong partway through, and know how long that rollback would realistically take, since that number determines how much runway the window needs.
Finally, tell whoever watches your environment that the window is happening. A SOC or monitoring team that knows a planned reboot is coming can treat it as expected activity instead of chasing an unexplained device restart in the middle of the night, which makes the whole event calmer for everyone involved.
After the Upgrade: Verification and Firmware’s Ceiling
Once the upgrade completes, resist the urge to call it done just because the device came back online. Verify before you close the window: confirm all security policies are present and correctly ordered, confirm VPN tunnels re-establish and pass traffic as expected, confirm SD-WAN health and routing came back correctly if applicable, and confirm FortiGuard connectivity is active and services are updating, not just present in the configuration. That last check matters specifically because a firmware upgrade can, in some cases, interact with licensing state in ways worth double-checking rather than assuming, which ties directly back to the FortiCare validity you confirmed before you started.
There’s also a ceiling on how far discipline alone can take you, and it’s worth planning around rather than discovering the hard way. Every hardware model eventually reaches end-of-support, after which Fortinet stops issuing firmware updates for it entirely, security fixes included. A device past that point can’t be kept current no matter how careful your upgrade process is; the runbook in this post simply stops applying, and a hardware refresh becomes the only path forward. That refresh is also worth treating as a real decision rather than a like-for-like replacement order: it’s the same NGFW-versus-UTM classification question we walked through in our previous post, revisited with a few years of hindsight about how your actual traffic has grown. Checking your hardware’s support timeline is a periodic exercise for exactly this reason, not just a one-time purchase-day question.
The Window That Nobody Noticed
A firmware upgrade that goes well follows a specific order: read the required path instead of guessing at it, run the pre-flight checks before you touch anything, sequence an HA pair through the change window without dropping traffic, and verify everything holds before you call the window closed. None of those steps by itself is complicated; skipping any one of them is how a routine maintenance window turns into an incident report.
The alternative to this discipline isn’t a different process…it’s no process: an upgrade attempted without checking the path, without a fresh backup, without a rollback plan, discovered as a failure rather than closed out as a success. That failure doesn’t stay contained to the firewall either, since a device stuck on old firmware, or hung mid-upgrade with a half-migrated configuration, affects everything behind it: VPN access, SD-WAN routing, and the security posture the rest of this series has been building toward.
Secureway IT runs planned change windows, including firmware upgrades, as part of the business continuity and security management services we provide clients, with our SOC actively monitoring the environment throughout. Running the upgrade is the easy part; confirming the configuration survived it, policies intact and nothing silently reverted to default, is the part that separates a clean upgrade from one that just looks clean. That’s the operational discipline behind everything we’ve covered in this series: keeping the box correctly classified, correctly licensed, and correctly configured, all at once, on purpose.
Not sure when your firewall’s firmware was last checked? Get in touch with Secureway IT, and a security specialist can walk through your current state with you.
Key Takeaways
- Fortinet’s upgrade path tool tells you the required sequence of intermediate versions; treat it as non-negotiable, since skipping a step skips that version’s configuration migration logic.
- Pre-flight before any upgrade: a fresh configuration backup, confirmed FortiCare validity, healthy HA sync state, adequate disk space, and a real read of the release notes for known issues and deprecated features.
- Upgrade HA pairs sequentially, secondary first, verifying stability before failing over, never both units at once, and schedule the window with a documented rollback plan and realistic timing.
- Verify policies, VPNs, SD-WAN health, and active FortiGuard connectivity after the upgrade completes, before considering the window closed.
- Firmware currency has a ceiling: hardware past end-of-support can’t receive further updates regardless of process discipline, and a hardware refresh is also a chance to revisit firewall classification.
Frequently Asked Questions
You’re likely trying to jump directly to a version that requires one or more intermediate firmware versions first. Check Fortinet’s upgrade path tool for your current and target versions to see the required sequence.
Generally, no, if the upgrade path tool indicates an intermediate version is required. Skipping it skips that version’s configuration migration logic, which can leave your configuration in an inconsistent state.
Typically, yes; firmware upgrades are usually gated behind active support entitlement. Confirm your FortiCare status before scheduling an upgrade window, since discovering a lapse mid-window limits your options considerably.