Firewall Firmware & Software Upgrade Services

Why firewall upgrades carry more risk than most

Firewalls concentrate risk in a way other network devices do not. They terminate VPN tunnels remote workers depend on, enforce the policy set that lets applications talk to each other, hold NAT translations that published services rely on, and frequently sit in the management path you would use to fix them. An upgrade that goes wrong does not degrade the network — it stops it.

Firewall software also changes behaviour between major versions more often than switch or router software does. Policy syntax evolves, default deny behaviours tighten, deprecated features stop being honoured, and SSL inspection or IPS engine changes can alter what traffic is permitted without any policy edit on your side. Reading the release notes for behaviour changes between your current and target version is not optional diligence — it is the part of the work that prevents a Monday morning of unexplained application failures.

This is why we treat firewall upgrades as a distinct discipline. The assessment is deeper, the validation list is longer, and the rollback decision point is agreed explicitly before anyone touches the device.

Firewall platforms we support

What we validate after a firewall upgrade

• Policy enforcement — that the rule base is intact, deployed and matching traffic as it did before the change, with particular attention to rules relying on features whose defaults changed between versions.
• VPN tunnels — site-to-site tunnels re-established with the expected phase 1 and phase 2 parameters, and remote-access VPN tested with a real client connection rather than assumed from the tunnel state table.
• NAT and published services — inbound published services reachable from outside, source NAT behaving as expected for outbound flows.
• HA state — cluster synchronised, both members on the intended version, failover tested where the window allows it.
• Licensing and subscriptions — threat, filtering and support subscriptions active and applied post-upgrade; some platforms require re-registration after a version change.
• Logging — logs still reaching the SIEM or log collector, with the expected format and field set, since log schema changes between versions are a common silent breakage.

Frequently asked questions

Can you upgrade a firewall HA pair without downtime?

In most cases yes, if the cluster is healthy and the upgrade path supports it. The standard approach is to upgrade the passive member, fail over, validate on the newly upgraded member, then upgrade the former active. Some major-version jumps do not support running mixed versions in a cluster even briefly, and those require a short outage. The assessment establishes which case applies to your platform and target version.

Do you upgrade FortiGate firewalls?

Yes. FortiOS upgrades are among our most frequent engagements, and we maintain deep Fortinet capability including EOL tracking, licence renewal and platform migration. Our FortiGate EOL checker and expiry tracker tools are publicly available if you want to establish your own position before contacting us.

What if my firewall is past end-of-support?

Devices past end-of-support stop receiving software fixes, which means any vulnerability disclosed after that date remains open on your perimeter permanently. Depending on the platform you may still be able to install the final released version, but that is a holding action rather than a fix. We would normally recommend planning a replacement, and can scope that migration as part of the same engagement.

How do you handle the risk of losing management access?

Before the change we confirm an alternative access path — out-of-band console, secondary management interface, or on-site presence with console cable. Firewall upgrades are the case where we most often recommend on-site or local-hands delivery rather than fully remote, because the device that fails is the device you would have used to reach it.

Will my firewall rules survive the upgrade?

Configuration is preserved across a supported upgrade path. The risk is not rule loss but rule behaviour change — a feature default that tightened, a deprecated option silently ignored, or an inspection engine that now handles traffic differently. Reviewing release notes for behaviour changes between your current and target version is a standard part of our planning.

Related services

• Network Device Firmware Upgrade
• Network Device Hardening
• Vulnerability Remediation
• FortiGate EOL Checker
• Request an Upgrade Assessment