FortiOS 7.2 End of Support: Which FortiGates Can Follow, and Which Cannot

FortiOS 7.2 reaches End of Support on 30 September 2026. That leaves twenty-three days, and for most FortiGate estates it is a routine piece of maintenance: check the upgrade path, book a window, move to 7.4 or 7.6.

For part of the estate it is not routine at all. A handful of FortiGate models appear in the FortiOS 7.2 supported-models list and in no list published since. Those units have no firmware to upgrade to. On 30 September they stop receiving security patches and there is nothing to install instead.

Which group your appliances fall into is the question this article answers. It also covers the thing that surprises administrators halfway through the project: on several of the most widely deployed models, the upgrade removes the feature the appliance is actually used for.

The date that matters is not the one most people quote

FortiOS 7.2 passed End of Engineering Support on 31 March 2025. A lot of teams read that as the end of security patching and either panicked eighteen months early or, more commonly, assumed the worst had already happened and stopped paying attention.

Fortinet’s lifecycle policy separates the two milestones clearly. Engineering software support runs for thirty-six months from general availability. After that the branch enters a must-fix phase lasting a further eighteen months, during which Fortinet still produces maintenance builds, but only for industry-wide critical issues and PSIRT vulnerabilities. No new features, no routine bug fixes, but security fixes continue.

Thirty-six plus eighteen is fifty-four months. FortiOS 7.2 went GA on 31 March 2022. Fifty-four months later is 30 September 2026. The arithmetic is not a coincidence: it is the policy, applied.

End of Support is where the obligations stop. Fortinet’s own wording is that after this date it “will not sell, manufacture, or improve the product and is under no obligation to provide support services”. Practically, three things end at once: security patches, the ability to open a TAC case on the branch, and any expectation that a newly disclosed vulnerability will be fixed for you.

The FortiOS lifecycle, current as of publication

Last verified: September 2026. Source: Fortinet Product Life Cycle, support.fortinet.com. Note that this page requires a support-portal login and is not publicly readable, which is why most published FortiOS lifecycle tables cite community trackers rather than Fortinet itself.

Two of these rows moved recently. Under customer support bulletin CSB-260330-1, issued in March 2026, Fortinet extended both 7.4 and 7.6 by a full year. FortiOS 7.4 End of Support went from 11 November 2027 to 11 November 2028; FortiOS 7.6 went from 25 January 2029 to 25 January 2030.

That is worth holding on to. Fortinet lifecycle dates are not fixed points. If you are planning around one, check it on the day you plan, not the day you read about it.

Which FortiGates can actually follow, and which cannot

Firmware lifecycle and hardware lifecycle run on separate clocks, and the second one is not what determines your options here. A FortiGate can be years away from hardware End of Support and still be unable to run anything newer than the branch that is expiring, because Fortinet drops models from the supported-models list at each major release.

The table below is built by comparing the official “Introduction and supported models” sections of the FortiOS release notes for 7.2.0, 7.4.0, 7.6.0, 7.6.4 and 8.0.0. A model that appears in the 7.2 list and not in the 7.4 list is capped at 7.2. There is no published table that does this, which is why the question is so hard to answer from a search result.

Built from the supported-models lists in the FortiOS 7.2.0 (build 1157), 7.4.0 (build 2360), 7.6.0 (build 3401), 7.6.4 (build 3596) and 8.0.0 (build 0167) release notes on docs.fortinet.com. One caveat matters: a .0 release list is not the same as a later point release. The G-series does not appear in the 7.6.0 list but does appear in 7.6.4. Confirm your specific unit in Fortinet’s Upgrade Path Tool before you plan around this table.

The FG-100E row is the one that changes projects. It was a mainstream mid-range appliance, there are a lot of them still running, and its owners have been watching the hardware lifecycle rather than the firmware one. Hardware support says one thing; the supported-models list says the software stops here.

What the upgrade takes away

Assume for a moment that your appliance can follow. There is a second problem, and it is not documented anywhere near the lifecycle dates.

Fortinet has removed SSL VPN in three separate steps, each of them in its own release note:

• FortiOS 7.6.0 removes SSL VPN web mode and tunnel mode entirely on models with 2GB of RAM or less. Fortinet names the FGT-40F and FWF-40F and variants, the FGT-60F and FWF-60F, the FGT-61F and FWF-61F, and the FGR-60F in both its 2GB and 4GB versions.
• FortiOS 7.6.3 replaces SSL VPN tunnel mode with IPsec VPN across every FortiGate model. Fortinet’s wording is “This applies to all FortiGate models.”
• FortiOS 7.6.3 also drops agentless VPN, previously called SSL VPN web mode, on the 40F, 60F and 90G series.

In the first two cases Fortinet’s release note carries the same sentence: “Settings will not be upgraded from previous versions.” The configuration does not convert. It disappears.

You can check whether your unit falls under the 2GB rule in one command. Run diagnose hardware sysinfo conserve in the CLI and look at total RAM. Below 2000MB and the 7.6.0 removal applies to you.

This is the point where the project changes character. A team that runs remote access on a 60F and moves to 7.6 is not performing an upgrade. It is rebuilding its remote access layer on IPsec, reissuing client configuration to every user, and retraining the service desk, with the firmware upgrade as a side effect. Fortinet’s own guidance is to migrate the SSL VPN configuration to IPsec before upgrading, not after, precisely because nothing carries across.

We have written separately about what Fortinet’s SSL VPN deprecation means in practice, and about how the rest of the industry is moving on the same question. Fortinet is early here, not unusual.

Three paths, honestly compared

There are three, not two, and the third one is missing from almost everything written about this deadline.

Upgrade in place

For an F-series or G-series appliance with no SSL VPN in production, this is straightforward and it is the right answer. Use Fortinet’s Upgrade Path Tool to get the tested point-to-point sequence, budget a maintenance window per step rather than one for the whole journey, take a configuration backup before each, and read diag debug config-error-log read on the console after every unit comes back up. That last command is the only way to see which configuration lines did not survive conversion, and skipping it is how teams discover a problem three weeks later.

If you run HA, check show full system global | grep cfg-save first. Save mode set to manual on a cluster is a documented cause of configuration loss during firmware upgrades, and it does not affect standalone units, which is why it catches people out.

Stay on 7.2 under Long Term Support

Fortinet’s LTS programme extends general availability for a branch to seventy-two months, and 7.2 is one of the branches it covers. The condition is a FortiCare Elite service contract. Fortinet states plainly that customers on Essential or Premium FortiCare are not eligible for LTS updates released after the standard end-of-support date.

Two things to establish before you count on this. Fortinet has not published the extended dates, the exact scope of what LTS covers, or which hardware models qualify; the detail sits in the FortiCare service description on the support portal. And the Last Service Extension Date, the last date on which a support contract extension can be ordered, falls twelve months before End of Support. For 7.2 that would place it around 30 September 2025. Ask your partner whether that window is still open before you build a plan on it.

Move the access layer somewhere else

This is only a serious option in one specific circumstance, and it is worth being precise about it rather than arguing it everywhere. If your appliance cannot follow the firmware, or if it can follow but the upgrade removes the remote access you depend on, then you are rebuilding the access layer either way. At that point the question is not firmware. It is where that layer should live for the next five years.

A cloud-delivered platform takes the inspection and remote access workload off the appliance entirely. The FortiGate keeps terminating the circuit and routing the branch; identity-based access, web inspection and isolation run in the platform. For an EU mid-market organisation the practical arguments are that the appliance stops being a lifecycle liability, that remote access no longer requires an internet-facing listener on your edge, and that policy lives in one place across every site rather than in twenty separate configurations that each need their own firmware tracking.

Jimber is built for exactly that shape of organisation: a single EU-sovereign SASE platform combining ZTNA and network isolation, secure web gateway, firewall-as-a-service and web application isolation, with data handled inside the EU. If you want the cost side of the comparison, our breakdown of what FortiGate customers actually pay for FortiSASE in 2026 sets out the published numbers.

What this means under NIS2, and what your insurer asked you

None of the ten results currently ranking for this question is European, so this section is missing from the conversation entirely.

NIS2 Article 21 requires essential and important entities to run risk analysis and information system security policies, and to handle vulnerabilities and their disclosure. An operating system that no longer receives security patches is a known, quantifiable risk. Not identifying and documenting it in the risk analysis is a visible gap, and where a system cannot be patched, the organisation has to be able to show the compensating controls it put in place instead.

In Belgium the CyberFundamentals framework is more direct than the directive. The CCB booklets state that any unsupported software without exception documentation is designated as unauthorised, and the same wording applies to unsupported hardware. From 1 October 2026, a FortiGate running FortiOS 7.2 inside a CyFun scope is unauthorised software unless there is a documented exception on file. That is the framework text, not an interpretation of it.

The insurance question is contractual rather than regulatory, and it is worth separating the two. What matters is not whether your policy excludes end-of-life software in the abstract. It is what you attested to at renewal about patch management. Where an incident traces back to an unsupported component that the application said was maintained, carriers have grounds to decline before the merits of the loss are reached. The useful action is to pull out your renewal questionnaire before 30 September rather than after.

The arguments against all of this, and what they are worth

Three objections come up every time, and two of them are largely right.

“End of Support is contractual, not a security event. Nothing changes on 1 October.” True as far as it goes. The appliance keeps working, there is no kill switch, and real risk is set by exposure rather than by a vendor’s calendar. A FortiGate with a management interface that is not reachable from the internet and remote access behind phishing-resistant MFA is in a very different position from one with a portal facing the public internet. The counterweight is that this is a pattern, not a one-off: Fortinet vulnerabilities were added to CISA’s Known Exploited Vulnerabilities catalogue in January 2025, March 2025, December 2025, January 2026 and April 2026. From 1 October the next one arrives without a 7.2 patch behind it, and the question becomes how quickly you can move under pressure rather than on a plan.

“You are hanging an architecture decision on a firmware date.” Fair, and the article should not pretend otherwise. If your 60F can run 8.0 and you have no SSL VPN in production, upgrade it and get on with your week. The argument only holds where the upgrade path removes the function the appliance exists to provide, because then you are running a migration project regardless and the only real question is what you are migrating to.

“The 100E case is a small slice of the estate, and you are amplifying it.” Partly. Most of what is deployed today is F-series and G-series, and for those units this is routine. But “small slice” is doing a lot of work in that sentence: the 100E was a volume product, the units are still in service, and their owners have been reassured by a hardware lifecycle that says nothing about which firmware they can run. Being in a small group does not help if you are in it.

What to do this week

Three things, in this order.

First, inventory by model rather than by site. Pull the model and current firmware from every FortiGate you manage and check each against the Upgrade Path Tool. You are sorting units into three buckets: can reach a supported branch, capped at 7.2, or already past everything.

Second, for every unit that can move, check RAM and check whether SSL VPN is in production. Those two facts determine whether you have an upgrade or a remote access migration, and the difference is weeks of work.

Third, write down the risk acceptance for anything that will still be on 7.2 on 1 October, with the compensating controls next to it. Under CyFun that document is the difference between a documented exception and an audit finding, and it takes an afternoon now against a much worse conversation later.

If the second step tells you that you are rebuilding remote access anyway, that is the moment the architecture question is genuinely open rather than rhetorical. We are happy to look at your estate with you and be straight about which units should simply be upgraded. Book a demo or get in touch, and if you want the technical background first, our comparison of WireGuard and ZTNA for FortiGate administrators covers the ground.

Frequently asked questions

When exactly does FortiOS 7.2 reach end of support?

FortiOS 7.2 reaches End of Support on 30 September 2026. It passed End of Engineering Support on 31 March 2025. Between those two dates it received only must-fix builds for critical issues and PSIRT vulnerabilities. After 30 September 2026, Fortinet issues no further security patches and has no obligation to provide support.

What is the difference between End of Engineering Support and End of Support?

End of Engineering Support stops new features and routine bug fixes, thirty-six months after general availability. Security patches for critical and PSIRT issues continue for a further eighteen months in the must-fix phase. End of Support ends everything: no security patches, no TAC cases, no obligation from Fortinet to support the release.

How long will FortiOS 7.4 be supported?

FortiOS 7.4 reaches End of Engineering Support on 11 May 2027 and End of Support on 11 November 2028. Both dates were extended by one year in March 2026 under Fortinet bulletin CSB-260330-1. The previous dates were 11 May 2026 and 11 November 2027.

Which FortiGate models cannot upgrade past FortiOS 7.2?

The FortiGate 100E, 100EF and 101E appear in the FortiOS 7.2 supported-models list and in no later release. For those units there is no upgrade path beyond 7.2, so 30 September 2026 means hardware replacement or a Long Term Support arrangement rather than a firmware upgrade. Confirm each unit in Fortinet’s Upgrade Path Tool.

Does upgrading from FortiOS 7.2 break SSL VPN?

Yes, on two counts. FortiOS 7.6.0 removes SSL VPN web and tunnel mode on models with 2GB RAM or less, including the 40F, 60F and 61F. FortiOS 7.6.3 replaces SSL VPN tunnel mode with IPsec across all models. Fortinet states that settings are not carried over from previous versions.

Can I stay on FortiOS 7.2 after end of support?

Only through Fortinet’s Long Term Support programme, and only with a FortiCare Elite service contract. Fortinet states that Essential and Premium FortiCare customers are not eligible for LTS updates released after the standard end-of-support date. Confirm availability and the ordering deadline with Fortinet or your partner before relying on it.

Is FortiOS 7.0 still supported?

No. FortiOS 7.0 reached End of Engineering Support on 30 March 2024 and End of Support on 30 September 2025. It receives no security patches and no technical assistance. Any FortiGate still running 7.0 has been without vendor security fixes for close to a year.

What firmware should a FortiGate run in 2026?

It depends on the hardware. F-series and G-series models can run FortiOS 8.0. The 60E to 91E family and the 140E are capped at 7.4, supported until 11 November 2028. The 100E, 100EF and 101E are capped at 7.2 and have no supported target after 30 September 2026.

How do I check my FortiGate upgrade path?

Use Fortinet’s Upgrade Path Tool at docs.fortinet.com/upgrade-tool. Select FortiGate/FortiOS as the product, then your model, your current version and your target version. The tool returns the tested point-to-point sequence. Skipping documented intermediate builds is not supported and is a common cause of failed upgrades.

What does running an out-of-support firewall OS mean under NIS2?

An unpatched network operating system is a known risk that must appear in your risk analysis under NIS2 Article 21, with documented compensating controls where it cannot be patched. In Belgium, the CCB CyberFundamentals framework designates unsupported software without a documented exception as unauthorised.